FortiGate:FAQ
FortiGate-6.0, FortiGate-6.2 und FortiGate-6.4:FAQ
Vorwort
Dieses FAQ ist für Fortinet Systeme basierend auf FortiOS 6.0, FortiOS 6.2 und FortiOS 6.4. Sofern nicht anderes vermerkt, stand zu Test-Zwecken eine Fortigate 60E zur Verfügung!
Datenschutz
*********************************************************************
* *
* THIS FILE MAY CONTAIN CONFIDENTIAL, PRIVILEGED OR OTHER LEGALLY *
* PROTECTED INFORMATION. YOU ARE PROHIBITED FROM COPYING, *
* DISTRIBUTING OR OTHERWISE USING IT WITHOUT PERMISSION FROM *
* ALSO SCHWEIZ SWITZERLAND. *
* *
*********************************************************************
"Die in diesen Artikeln enthaltenen Informationen sind vertraulich und dürfen ohne
schriftliche Zustimmung der ALSO Schweiz AG gegenüber Dritt-Unternehmen nicht
bekannt gemacht werden"
FAQ
Dokumentation
Wo findet ich die Dokumente wie Datasheets, Quick Start Guide, User Guide etc. ?
Ueber folgenden internen Link findet man Datasheets und Quick Start Guide betreffend FortiGate Devices:
Fortinet:ProduktInfo
Ebenfalls lohnt es sich folgenden Link anzuschauen der "Cookbook" ähnliche Dokumente und Video's beinhaltet:
http://community.fortinet.com/
Auf folgender Seite findet man alle orginal Dokumente betreffend FortiGate:
http://docs.fortinet.com/fortigate/admin-guides
Welches sind die wichtigsten Ports und Protokolle für einen reibungslosen Betrieb?
Wenn eine FortiGate sich im Factory-Reset Werkszustand befindet, so werden verschiedenen TCP/UDP Ports durch das FortiOS zur Verfügung gestellt um die Funktionen der FortiGate bereitzustellen. Nachfolgende Übersicht zeigt die benötigten Ports (TCP/UDP) auf. Folgendes ist dabei zu berücksichtigen: Diese abgebildeten TCP/UDP Ports werden nicht per Standard zur Verfügung gestellt / ersichtlich. Viele Ports sind nur dann ersichtlich wenn die entsprechende Funktion genutzt wird:
Request of Proposal
Ihre Mitarbeit ist Willkommen!
Sie möchten eine Korrektur zu einem Artikel anbringen oder einen Beitrag leisten?
Schreiben Sie uns eine Nachricht auf: fortinet-ch@also.com
Hardware
Wo finde ich die Hardware Revision und Hardware Generation Informationen eines FortiGate Devices?
Ein FortiGate Device verfügt über eine entsprechende "Hardware Revision" und "Hardware Generation". Über diese Information wird das entsprechende FortiGate Device identifiziert. Möchte man die "Hardware Revision" einer FortiGate herausfinden kann dies folgendermassen bewerkstelligt werden:
| Variante Device Label | Variante FortiOS |
|---|---|
|
Die "Hardware Revision" wird als "Label" auf der Rückseite eines FortiGate Devices aufgeführt in nachfolgender Form und als Strich-Code: PN: P15968-01 |
Wenn man über die CLI folgenden Befehl absetzt erhält man die "Hardware Revision" Informationen:
# get system status | grep Part-Number System Part-Number: P15968-01 |
Wie schon zu Beginn erklärt wird ein Device über die "Hardware Revision" und "Hardware Generation" identifiziert. Die "Hardware Generation" kann jedoch nicht eruiert werden, sei es über ein "Label" noch via CLI. Wenn diese Information benötigt wird, muss über ein Customer Care Ticket die entsprechende Information der "Hardware Generation" nachgefragt werden. Wie ein Ticket für Fortinet eröffnet wird siehe nachfolgender Artikel:
Fortinet:Support-Case
Bei dieser "Hardware Revision", wie in unserem Beispiel gezeigt (P15968-01, handelt es sich zBsp um eine FG-70D. Das bedeutet, wenn eine neue "Hardware Revision" für dieses Device released wird, so kann diese über eine PN Nr. "P15968-01" verfügen, jedoch als "Hardware Generation" die "2". Es kann jedoch auch sein, dass ein neue "Hardware Revision" über eine PN-Nummer verfügt, zBsp "P15978-02". Somit können anhand der PN-Nummer keine Rückschlüsse über folgende, notwenidge Informationen gezogen werden:
PN-Nummer (Hardware Revision) + Hardware Generation
Diese Informationen der "Hardware Revision" sowie "Hardware Generation" sind dann wichtig, wenn es sich um ein Cluster handelt. Bei einem RMA Austausch achtet Fortinet darauf und übermittelt der zuständigen Stelle für den Austausch diese Informationen damit diese exakt die gleiche "Hardware Revision" und "Hardware Generation" dem Kunden zustellt!
Wo finde ich eine Übersicht welches FortiGate Device zBsp über wieviel "Memory" verfügt, ein "SOC" und / oder ob ein "NP" verbaut ist?
Nachfolgend eine Aufstellung die zeigt über welche Komponenten wie "SOC, NP, Memory, Storage ein FortiGate Device verfügt:
|
Diese Informationen stammen aus einem Post im "Fortinet Forum" da Fortinet diese Informationen nicht kommuniziert: https://forum.fortinet.com/tm.aspx?m=100451#100451 Zusätzlich steht ein Dokument von Fortinet zur Verfügung die über die Hardware Schematic eines Fortinet Produktes wie zBsp CPU, RAM, Flash usw. Auskunft gibt: |
LEGENDE
FA = FA526id(wb) rev 1 (v4l) FortiSOC (Fortinet)
I2 = Intel Core 2 Duo
I3 = Intel Pentium III
I4 = Intel Pentium 4
IA = Intel Atom
IC = Intel Celeron (Covington)
II3 = Intel Core i3
II5 = Intel Core i5
IM = Intel Mobile
IX = Intel Xeon
CP: Content Processor
NP: Network Processor
SoC: System on a Chip
Was für FortiGate Geräte stehen zur Verfügung und wie finde ich das Richtige für mich?
Wenn für einen Kunden ein FortiGate Device evaluiert werden soll stellt sich jeweils die Frage welches Gerät das Richtige für diesen Kunden ist. Um dies zu eruieren sind folgende Punkte massgebend:
- Über was für eine Internet Anbindung verfügt der Kunde, an der die FortiGate installiert werden soll?
- Ist ein Ausbau/Wechsel der Internet Anbindung geplant? Falls ja, wie wird diese vergrössert? (Downstream/Upstream)?
- Wie viele User werden durch das FortiGate Device geschützt?
- Welche UTM Features sollen auf der FortiGate aktiviert werden? (Antivirus, WebFilter, IPS usw.)
- Wird "deep inspection" eingesetzt (aufbrechen von verschlüsseltem Traffic)?
- Werden spezielle Interfaces benötigt um Beispiel SFP+
- Wird ein spezieller Durchsatz in einem Bereich benötigt?
- Wie wird das "logging" durchgeführt? Soll auf Disk, FortiAnalyzer oder Syslogserver geloggt werden?
Zusätzlich stellt Fortinet die sogenannte "Produkte Matrix" zur Verfügung. In dieser werden die verschiedenen Devices gegenübergestellt. Dabei werden die verschiedenen "Durchsätze" in verschiedenen Kategorien wie SSL-VPN, IPSec, UTM Antivirus usw. aufgelistet. Dabei ist zu beachten, dass diese "Durchsätze" als "Feature Only" Durchsatz zu verstehen sind. Dies bedeutet: Wird Antivirus mit 35 Mbps Durchsatz aufgeführt, versteht sich dieser Wert in dem Sinne, dass wenn dieses Device "nur" Antivirus Traffic erhalten würde, der Durchsatz 35 Mbps ist. Aus diesem Grund ist es unerlässlich die Produkte Matrix zu konsultieren um das richtige Device für den Kunden auszuwählen:
Datei:ProductMatrix.pdf
Zu den verschiedenen FortiGate Devices stehen jeweils die "Datasheets" zur Verfügung welche nochmals detailliert über das jeweilige FortiGate Device Auskunft gibt. Des Weiteren stehen nebst den "Datasheets" ebenso die "Quickstart Guide" zur Verfügung welche zeigen "was" zum jeweiligen Device mitgeliefert wird sowie das Aussehen/ Abbild:
Fortinet:ProduktInfo#FortiGate
Des Weiteren steht für die Produkte Information der Produkt Guide zur Verfügung welches jeden FortiGate Device in einer Kurzübersicht darstellt:
Datei:Fortinet-ProductGuide.pdf
Nachfolgend als Anhaltspunkt eine Übersicht der FortiGate Devices in den verschiedenen Kategorien wie "Entry Level, Midsize usw.":
| FortiGate Entry Level Series: Comparison |
|---|
|
| FortiGate Mid Range Devices: Comparison |
|---|
|
| FortiGate 1000 und 2000 Series: Comparison |
|---|
|
| FortiGate 3000 Series: Comparison |
|---|
|
| FortiGate 5000: Comparison |
|---|
|
Einen detaillierten Überblick bekommt man auf der folgenden Seite:
http://help.fortinet.com/fgt/60/6-0-0/max-values.html
Wie kann ich auf einem FortiGate Device einen Hardwaretest ausführen (Troubleshooting / HQIP Testing)?
Damit man den "Advanced Hardware Test" resp. HQIP Test durchführen kann, muss ein spezielles "image" welches für jedes Device zur Verfügung gestellt wird, temporär geladen. Unter der regulären Support-Seite findet man die Images über das Icon "HQIP Images" am Ende der Seite. Nachfolgend der direkte Link für "HQIP Images":
https://support.fortinet.com/Download/HQIPImages.aspx
|
|
Damit man zu diesem Link gelangt muss sich anhand eines Support Accounts eingeloggen und um das damit entsprechende Image herunterladen zu können, muss die entsprechende Serien-Nummer des Devices eingegeben werden. Dies muss durchgeführt werden da jedes Device sich anhand der Revision und Generation identifiziert um das entsprechende HQIP Image zur Verfügung stellen zu können. Dies bedeutet auch: Es ist nicht zu empfehlen ein bestehendes Image aus einem früheren HQIP Test zu nutzen um auf einem baugleichen Device den Test durchzuführen, da die Devices -obwohl Baugleich- sich unterscheiden können in Revision und Generation. |
Auf der FortiGate wird dieses HQIP Image wie beim "stagging" Prozess selber über TFTP hochgeladen. Nachdem man das HQIP Image über TFTP geladen hat kann mit dem User "admin" eingeloggt werden (kein Passwort). Anhand des Befehls "diagnose hqip start" kann ein Script ausgeführt werden. Dieses Script führt die verschiedenen Hardware Tests aus. Der Unterschied zum regulären "stagging" Prozess selber ist einzig und alleine, dass dieses Image nicht anhand "D" (Default), "B" (Backup) sondern anhand "R" (Run) installiert wird. Dies bedeutet: dieses Image wird durch "R" (Run) temporär in den Memory Bereich installiert. Der Output der Serial Konsole muss "geloggt" werden um es später dem Fortinet Support übermitteln zu können. Im "Putty" wird dies für eine Session unter folgender Position konfiguriert:
Category > Session > Logging > All Session output
Nachfolgend eine Schritt für Schritt Anleitung wie so ein HQIP Image geladen, und das Skript ausgeführt werden kann:
-> Lade das entsprechende Image herunter (siehe Link oben; Serien-Nummer des Devices muss angegeben werden)
-> Benenne das File um nach "image.out" und verschiebe diese in das root Verzeichnis eines TFTP Servers.
Wenn kein TFTP Server vorhanden ist empfehlen wird den SolarwindsTFTP Server. Nachfolgend ein Link
um diesen runterzuladen:
SolarWinTFTP Server http://www.solarwinds.com/products/freetools/free_tftp_server.aspx
-> Sofern das Web Mgmt. Interface zugänglich ist empfehlen wir vor dem Test ein ordentliches Backup der
Konfiguration der FortiGate durchzuführen!
-> Führe über die Serielle Konsole nachfolgenden Befehl aus um einen Neustart des Devices durchzuführen:
# execute shutdown
-> Um das HQIP Image über den TFTP Server zu laden muss eine Workstation folgendermassen mit einer FortiGate
verbunden werden (Beispiel: FortiGate-60D)
_____________________________
| RS232 Verbindung |
Konsolen Port | |
___________|___ | RS232 Anschluss
| | ____|_______________
| FortiGate 60D | 192.168.1.100/24 | |
|_______________| _____| LapTop/Workstation | --> SolarWindsTFTP Server starten
| | NIC |____________________| --> FortiOS als image.out im C:\TFTP-Root
WAN1 | |
|_____________________|
NOTE Auf dem Laptop müssen sämtliche Firewalls, Endpoint Security und Netzwerkkarten deaktiviert sein und auf der LAN Netzwerkarte
muss die IP 192.168.1.100 mit dem Subnet 255.255.255.0 konfiguriert sein (kein DNS, kein Default Gateway nötig)!
-> Öffne über Putty eine Serielle Verbindung (Konsole) und achte darauf das "Putty" für Log aktiviert wurde.
Schalte die FortiGate ein und breche den Startprozess ab wenn folgendes erscheint:
FortiGate-60D (10:49-11.12.2014)
Ver:04000024
Serial number: FGT60D4615013788
CPU(00): 800MHz
Total RAM: 2GB
Initializing boot device...
Initializing MAC... nplite#0
Please wait for OS to boot, or press any key to display configuration menu
Unterbreche den Boot-Prozess durch "Press any key"
[C]: Configure TFTP parameters.
[R]: Review TFTP parameters.
[T]: Initiate TFTP firmware transfer.
[F]: Format boot device.
[I]: System information.
[B]: Boot with backup firmware and set as default.
[Q]: Quit menu and continue to boot.
[H]: Display this list of options.
Enter C,R,T,F,I,B,Q,or H: T
Please connect TFTP server to Ethernet port 'WAN1'.
MAC: 08:5b:0e:d9:18:f0
Connect to tftp server 192.168.1.100 ...
############################################################
Image Received.
Checking image... OK
ACHTUNG Beim nächsten Menüpunkt wähle "R" dh. NICHT "D" oder "B" speichern, sondern NUR ausführen!
Save as Default firmware/Backup firmware/Run image without saving:[D/B/R]?R
Reading boot image... 1829759 bytes.
Initializing firewall...
System is starting..
Test program loading(HQIP, Build1003,Dec 15 2010 19:42:45) ...
You are running HQIP test program. To start testing, login as "admin" without password, and type:
diagnose hqip start
Logge dich nun ein anhand der obigen Informationen!
HQIP login: admin
Password:
Welcome !
HQIP # diagnose hqip start
Nun wird der HQIP Test ausgeführt und zwar für folgende Informationen:
1.BIOS Integrity Check
2.System Configuration Check
3.Memory test
4.CPU test
5.CPU/Memory Performance Test
6.FortiASIC Test
7.USB Test
8.Boot Device Test
9.Hard Disk Test
10.Network Interface Controller Test
11.NPU DDR Memory Test
12.LED Test
13.Reset Button Test
Dh. normalerweise müssten alle Netzwerkkarten Ports angeschlossen werden. Geschieht dies nicht erscheint eine Fehlermeldung die jedoch keinen weiteren Einfluss hat auf die auszuführenden Tests, ausser der Test soll auf den Interfaces ausgeführt werden. Wenn die Netzwerkkarten Tests korrekt ausgeführt werden soll, müssen die Ports folgendermassen verbunden werden (Beispiel FortiGate-60D):
Nachfolgend ein Output eines solchen Tests für eine FG-60D (Netzwerk Port gemäss Grafik oberhalb "überlistet"):
Datei:Hqip-output-v54.txt
Um die Fortigate wieder in den originalen Zustand zu versetzen führe ein Login über die Serielle Konsole mit dem User "admin" (kein Passwort)durch. Danach führe folgendes aus:
HQIP login: admin
Password:
Welcome !
HQIP # execute reboot
This operation will reboot the system !
Do you want to continue? (y/n)y
Da das HQIP Image "nur" temporärer (Memory) installiert wurde sind alle Informationen nach einem Neustart betreffend diesem Image gelöscht. Wenn es nach dem Neustart zu Hinweisen/Errors betreffend der Konfiguration kommt zB:
System is started.
The config file may contain errors,
Please see details by the command 'diagnose debug config-error-log read'
Führe ein Login durch und führe folgendes aus:
# diagnose debug config-error-log read
>>> "unset" "post-lang" @ root.firewall.profile-protocol-options.default.ftp:command parse error (error -61)
Oftmals ist ein einfacher Neustart der Fortigate nötig um das Problem zu beheben:
# execute reboot
Für FortiGate Devices der "E" Serie, sowie FG-300D/500D existiert kein HQIP Image - wie kann ich dennoch einen Hardwaretest ausführen?
Bei der "E" Serie zBsp FG-51E, sowie FG-300D und FG-500D, kann von der "Support" Seite kein separates HQIP Image heruntergeladen werden. Auf diesen Umstand wird auf der "Support" Seite auch darauf hingewiesen. Dazu steht jedoch auf den erwähnten FortiGate Devices ein neues "diagnose" Kommando zur Verfügung, welche diese "Hardware Tests" im Stil von "HQIP" durchführt:
# diagnose hardware test [Parameter]
Als "Parameter" kommen folgende Attribute in Frage:
bios führt eine BIOS spezifische Überprüfung durch
system führt ein System spezifische Überprüfung durch
usb führt eine USB spezifische Überprüfung durch
button führt eine button spezifische Überprüfung durch
cpu führt eine CPU spezifische Überprüfung durch
memory führt ein Memory spezifische Überprüfung durch
network führt eine Netzwerkinterface spezifische Überprüfung durch
disk führt eine disk spezifische Überprüfung durch
led führt eine LED spezifische Überprüfung durch
wifi führt eine Wireless spezifische Überprüfung durch
suite runthe HQIP test suite
setting die Testeinstellungen können auf diesen Weg geändert werden
info zeigt die aktuellen Test Parameter an
Um alle "test suite" durchzuführen kann folgendes ausgeführt werden:
# diagnose hardware test suite all
Nachfolgend ein "output" dieses Befehls basierend auf einer FG-50E:
Datei:Diagnose-hardware-test-suite-all.txt
Wie erhalte ich eine Übersicht wie die Luftzirkulation (Airflow) in einer FortiGate funktioniert?
Im nachfolgenden Dokument wird gezeigt wie die Luftzirkulation/Kühlung in den entsprechenden FortiGate Devices aufgebaut ist und wie diese funktionieren:
Datei:Fortinet-Hardware-Airflow.pdf
Wie kann ich die verschiedenen Hardware Informationen auf einem FortiGate Devices anzeigen lassen?
Um die detaillierten Hardware Informationen auf einem FortiGate Device aufzulisten steht der folgende Befehl zur Verfügung:
 Konfiguration über die CLI:
|
# get hardware [cpu | memory | nic | npu | status] |
Somit kann anhand der Optionen folgendes ausgeführt werden:
| Konfiguration über die CLI: get hardware cpu
|
# get hardware cpu
Processor : ARMid(wb) rev 1 (v4l)
model name : FortiSOC2
BogoMIPS : 799.53
Features : swp half thumb
Hardware : FSoC2_ASIC
Revision : 0000
Serial : 0000000000000000
Imp: 0x66 Arch: 0x5 Part: 0x726 Ver: 0x1
Ctype: 14 DSize: 6 DASS: 8 DLEN: 32 ISize: 6 IASS: 8 ILEN: 32
Seperated TLB: Associativity 0
0x0005317f HUM: En Vec Base:0xffff0000 IC:En BP:Dis RomP:Dis
SysP:En WB:En DC: En Align:En
0x00000000 SB: Dis DB:Dis RS:Dis
|
| Konfiguration über die CLI: get hardware memory
|
# get hardware memory total: used: free: shared: buffers: cached: shm: Mem: 1928364032 437944320 1490419712 0 2940928 154861568 140664832 Swap: 0 0 0 MemTotal: 1883168 kB MemFree: 1455488 kB MemShared: 0 kB Buffers: 2872 kB Cached: 151232 kB SwapCached: 0 kB Active: 74368 kB Inactive: 79864 kB HighTotal: 0 kB HighFree: 0 kB LowTotal: 1883168 kB LowFree: 1455488 kB SwapTotal: 0 kB SwapFree: 0 kB |
| Konfiguration über die CLI: get hardware cpu
|
# get hardware cpu
Processor : ARMid(wb) rev 1 (v4l)
model name : FortiSOC2
BogoMIPS : 799.53
Features : swp half thumb
Hardware : FSoC2_ASIC
Revision : 0000
Serial : 0000000000000000
Imp: 0x66 Arch: 0x5 Part: 0x726 Ver: 0x1
Ctype: 14 DSize: 6 DASS: 8 DLEN: 32 ISize: 6 IASS: 8 ILEN: 32
Seperated TLB: Associativity 0
0x0005317f HUM: En Vec Base:0xffff0000 IC:En BP:Dis RomP:Dis
SysP:En WB:En DC: En Align:En
0x00000000 SB: Dis DB:Dis RS:Dis
|
| Konfiguration über die CLI: get hardware memory
|
# get hardware memory total: used: free: shared: buffers: cached: shm: Mem: 1928364032 437944320 1490419712 0 2940928 154861568 140664832 Swap: 0 0 0 MemTotal: 1883168 kB MemFree: 1455488 kB MemShared: 0 kB Buffers: 2872 kB Cached: 151232 kB SwapCached: 0 kB Active: 74368 kB Inactive: 79864 kB HighTotal: 0 kB HighFree: 0 kB LowTotal: 1883168 kB LowFree: 1455488 kB SwapTotal: 0 kB SwapFree: 0 kB NOTE Weitere Befehle um detaillierte Informationen über die Memory Nutzung zu erhalten können dem nachfolgenden Artikel entnommen werden: Artikel Benutzung Memory anzeigen lassen |
| Konfiguration über die CLI: get hardware nic
|
# get hardware nic
The following NICs are available:
dmz
internal1
internal2
internal3
internal4
internal5
internal6
internal7
wan1
wan2
NOTE Um detaillierte Informationen über ein spezifisches Interface zu erhalten benütze folgenden Befehl: # get hardware nic [Name des Interfaces zB "dmz "] Driver Name :Fortinet NP4Lite Driver Version :1.0.0 Admin :up Current_HWaddr 08:5b:0e:47:db:57 Permanent_HWaddr 08:5b:0e:47:db:57 Status :up Speed :100 Duplex :Half Host Rx Pkts :480560 Host Rx Bytes :104351252 Host Tx Pkts :468353 Host Tx Bytes :83937534 Rx Pkts :480558 Rx Bytes :111078750 Tx Pkts :468351 Tx Bytes :80501362 rx_buffer_len :2048 Hidden :No cmd_in_list : 0 promiscuous : 1 enabled 802.1x : 0 authorized : 0 mac bypass : 0 |
| Konfiguration über die CLI: get hardware npu
|
# get hardware npu legacy legacy np1 np1 np2 np2 np4 np4 Dieser Output wird nur angezeigt wenn das entsprechende Device, auf welchem dieser Befehl ausgeführt wird auch einen "NPU" (Networking Processing Unit) enthält. Wenn es sich um ein Device mit integriertem NPU handelt dh. SoC, wird kein Output geliefert. |
Was bedeuten die verschiedenen LED-Stati auf einer FortiGate?
Ein FortiGate Device verfügt am FrontPanel über verschiedene LED's dh. zBsp High Availability, Power, Status usw. Diese können verschiedenen Stati anzeigen. Die Bedeutung der verschiedenen LED's können in den folgenden Tabellen entnommen werden:
| LED Status Code | ||
|---|---|---|
|
Label |
Status |
Bedeutung |
| PWR | Grün | Power is ON |
| Off | Power is off | |
| STA | Grün | Status ist Normal |
| blinkend Grün |
| |
| Rot | Es liegt auf der FortiGate ein kritischer Alarm vor | |
| ALARM | Off | Kein Alarm oder die FortiGate hat einen minor Alarm |
| Orange(Amber) | Die FortiGate hat einen Major Alarm | |
| Rot |
| |
| HA | Grün | Die FortiGate wird in einem FGCP HA-Cluster betrieben. |
| Rot |
Ein Failover ist eingetreten. Dies bedeutet in der Regel, dass eine der FotiGates in einem HA-Cluster ausgefallen ist oder dass die HA-Heartbeat Kommunikation zwischen den FortiGates im HA-Cluster ausgefallen ist oder diese unterbrochen wurde. | |
| Off |
| |
| WIFI | Grün | Der Wireless Port ist aktiv |
| blinkend Grün |
Das Wireless Interface sendet und empfängt Daten. | |
| Off |
Das Wireless Interface ist down | |
| LED Status Codes bei den Interfaces | ||
|---|---|---|
|
Port Typ |
Status |
Bedeutung |
|
Ethernet Port |
Grün | verbunden |
| blinkend Grün | senden und empfangen von Daten | |
| Off |
Keine Verbindung aktiv | |
|
Ethernet Port |
Grün | verbunden mit 1 Gbps |
| Orange(Amber) | verbunden mit 100 Mbps | |
| Off |
Nicht verbunden oder mit 10 Mbps verbunden.
| |
| SFP Ports | Grün | verbunden |
| blinkend Grün | senden und empfangen von Daten | |
| Off | Keine Verbindung aktiv | |
Anordnung Link Status und Link Speed LED bei FortiGate Modellen mit nach vorne gerichteten Interfaces:
Anordnung Link Status und Link Speed LED bei FortiGate Modellen mit nach hinten gerichteten Interfaces:
Dokument:
Wie wird ein virtueller Switch komplett gelöscht?
Um einen virtuellen Switch komplett zu löschen, müssen sämtliche Einstellungen und Objekte, welche darauf referenzieren, zurückgebaut werden. Deshalb ist es am einfachsten, wenn man sich gerade am Anfang, bei der Initialkonfiguration Gedanken macht, ob man diesen virtuellen Switch verwenden möchte oder nicht. Um von einer Fortigate mit Werkseinstellung den virtuellen Switch zu löschen, muss sich via RS232 auf die Firewall verbunden werden, um dann wie folgt vorzugehen:
| 1. Sämtliche Firewall Policies mit Referenzen auf den Switch werden gelöscht: |
fg-lab # config firewall policy
fg-lab (policy) # show
config firewall policy
edit 1
set uuid eeaeeb02-1afc-51e8-4dbb-ab7cd6f3a2fe
set srcintf "internal"
set dstintf "wan1"
set srcaddr "all"
set dstaddr "all"
set action accept
set schedule "always"
set service "ALL"
set nat enable
next
end
fg-lab (policy) # delete 1
fg-lab (policy) # end
Alternativ kann mit dem Befehl purge das ganze Regelwerk auf einmal gelöscht werden: fg-lab # config firewall policy fg-lab (policy) # purge This operation will clear all table! Do you want to continue? (y/n)y fg-lab (policy) # end |
| 2. Alle DHCP Server mit Referenzen werden entfernt: |
fg-lab # config system dhcp server
fg-lab (server) # show
config system dhcp server
edit 1
set dns-service default
set default-gateway 192.168.1.99
set netmask 255.255.255.0
set interface "internal"
config ip-range
edit 1
set start-ip 192.168.1.110
set end-ip 192.168.1.210
next
end
next
edit 2
set dns-service default
set default-gateway 10.253.255.254
set netmask 255.255.255.192
set interface "wqtn-sw.0"
config ip-range
edit 1
set start-ip 10.253.255.193
set end-ip 10.253.255.253
next
end
set timezone-option default
next
end
fg-lab (server) # delete 1
fg-lab (server) # end
Alternativ kann auch mit dem Befehl purge jeder DHCP Server aufeinmal gelöscht werden: fg-lab # config system dhcp server fg-lab (server) # purge This operation will clear all table! Do you want to continue? (y/n)y fg-lab (server) # end |
| 3. Das Interface wird zurückgebaut: |
fg-lab # config system interface
fg-lab (interface) # edit internal
fg-lab (internal) # show
config system interface
edit "internal"
set vdom "root"
set ip 192.168.1.99 255.255.255.0
set allowaccess ping https ssh http fgfm capwap
set type switch
set device-identification enable
set role lan
set snmp-index 7
next
end
fg-lab (internal) # set ip 0.0.0.0 0.0.0.0
fg-lab (internal) # next
|
| 4. Nun kann der Switch zurückgebaut werden: |
fg-lab # config system virtual-switch
fg-lab (virtual-switch) # show
config system virtual-switch
edit "lan"
set physical-switch "sw0"
config port
edit "lan1"
next
edit "lan2"
next
edit "lan3"
next
edit "lan4"
next
edit "lan5"
next
end
next
end
fg-lab (port) # delete lan1
fg-lab (port) # delete lan2
fg-lab (port) # delete lan3
fg-lab (port) # delete lan4
fg-lab (port) # delete lan5
WARNING: Virtual switch requires at least 1 port. This virtual switch currently has 0 port.But, this message can be ignored if this virtual switch will be set to 802.1x slave mode later.
Do you want to continue? (y/n)y
fg-lab (port) # end
Bei einem FortiWIFI Modell muss auch die Bridge mit dem WLAN-Port entfernt werden: fg-lab # config system switch-interface
fg-lab (switch-interface) # show
config system switch-interface
edit "internal"
set vdom "root"
set member "wifi" "lan"
next
end
fg-lab (switch-interface) # delete internal
|
| 5. Jetzt kann der virtuelle Switch komplett gelöscht werden: |
fg-lab # config system virtual-switch
fg-lab (virtual-switch) # show
config system virtual-switch
edit "lan"
set physical-switch "sw0"
next
end
fg-lab (virtual-switch) # delete lan
|
Nun können sämtliche Ports auf der Firewall individuell verwendet werden.
Wie kann ich die Tempratur der CPU ermitteln?
Um die Tempratur der CPU zu erfahren, kann im Dashboard ein Sensor Widget angezeigt werden. Es kann folgendermassen vorgegangen werden:
 Konfiguration über das WebGui:
|
|
|
|
|
|
Über die CLI stehen zwei Befehle zur Verfügung, mit welchen die Temperaturen und Alarme auf der FortiGate überprüft werden können. Mit diesen Befehlen können mehr Informationen ermittelt werden:
| Konfiguration über die CLI:
|
# execute sensor list Wenn die FortiGate im VDOM Modus betrieben wird muss in die globale Konfiguration gewechselt werden: # config global # execute sensor list Es werden die Sensoren und Messwerte von jedem Komponenten aufgeführt. Dabei wird der aktuelle Wert, der Schwellwert und der Alarumstatus angezeigt.
|
| Beispiel auf einer FortiGate 300D: |
# execute sensor list 1 +3.3V alarm=0 value=3.3018 threshold_status=0 2 +5V alarm=0 value=5.048 threshold_status=0 3 +12V alarm=0 value=12.136 threshold_status=0 4 CPU VCCP alarm=0 value=1.0295 threshold_status=0 5 CPU VTT alarm=0 value=1.0491 threshold_status=0 6 CPU PVSA alarm=0 value=0.9413 threshold_status=0 7 P1V8 alarm=0 value=1.7743 threshold_status=0 8 P1V5 alarm=0 value=1.4901 threshold_status=0 9 PCH +1.05V alarm=0 value=1.024 threshold_status=0 10 VCC 2V5 alarm=0 value=2.464 threshold_status=0 11 MAIN 12V alarm=0 value=11.904 threshold_status=0 12 VCC 1V15 alarm=0 value=1.136 threshold_status=0 13 DDR3 VTT alarm=0 value=0.72 threshold_status=0 14 RPS 12V alarm=1 value=0 threshold_status=0x7 15 NCT +3.3V alarm=0 value=3.264 threshold_status=0 16 NCT VBAT alarm=0 value=3.264 threshold_status=0 17 NCT +3.3VSB alarm=0 value=3.216 threshold_status=0 18 NCT VTT alarm=0 value=1.04 threshold_status=0 19 DTS CPU alarm=0 value=63 threshold_status=0 20 CPU Core 0 alarm=0 value=63 threshold_status=0 21 CPU Core 1 alarm=0 value=63 threshold_status=0 22 TD1 alarm=0 value=51 threshold_status=0 23 TD2 alarm=0 value=39 threshold_status=0 24 FAN_TMP_3 alarm=0 value=51 threshold_status=0 25 LM75 U72 alarm=0 value=46 threshold_status=0 26 LM75 U65 alarm=0 value=46 threshold_status=0 27 LM75 U62 alarm=0 value=49 threshold_status=0 28 FAN1 alarm=0 value=6500 threshold_status=0 29 FAN2 alarm=0 value=6400 threshold_status=0 30 FAN3 alarm=0 value=6300 threshold_status=0 # execute sensor details Wenn die FortiGate im VDOM Modus betrieben wird muss in die globale Konfiguration gewechselt werden: # config global # execute sensor details Mit diesem Befehl werden noch weitere Informationen, wie der niedrigste und höchste Schwellenwert der Sensoren angezeigt:
|
| Beispiel auf einer FortiGate 300D: |
# execute sensor detail
1 +3.3V alarm=0 value=3.3018 threshold_status=0
type=2/1
upper_non_recoverable=3.6906
upper_critical=3.6258
upper_non_critical=3.5124
lower_non_critical=3.0912
lower_critical=2.994
lower_non_recoverable=2.9292
2 +5V alarm=0 value=5.048 threshold_status=0
type=2/1
upper_non_recoverable=5.587
upper_critical=5.489
upper_non_critical=5.342
lower_non_critical=4.6805
lower_critical=4.5335
lower_non_recoverable=4.4355
3 +12V alarm=0 value=12.136 threshold_status=0
type=2/1
upper_non_recoverable=14.083
upper_critical=13.729
upper_non_critical=13.434
lower_non_critical=10.602
lower_critical=10.366
lower_non_recoverable=10.012
4 CPU VCCP alarm=0 value=1.0295 threshold_status=0
type=2/1
upper_non_recoverable=1.6959
upper_critical=1.6665
upper_non_critical=1.6175
lower_non_critical=0.2259
lower_critical=0.2161
lower_non_recoverable=0.2063
5 CPU VTT alarm=0 value=1.0491 threshold_status=0
type=2/1
upper_non_recoverable=1.1765
upper_critical=1.1569
upper_non_critical=1.1275
lower_non_critical=0.9315
lower_critical=0.9021
lower_non_recoverable=0.8825
6 CPU PVSA alarm=0 value=0.9413 threshold_status=0
type=2/1
upper_non_recoverable=1.0883
upper_critical=1.0687
upper_non_critical=1.0981
lower_non_critical=0.8237
lower_critical=0.7943
lower_non_recoverable=0.7747
7 P1V8 alarm=0 value=1.7743 threshold_status=0
type=2/1
upper_non_recoverable=2.0095
upper_critical=1.9703
upper_non_critical=1.9115
lower_non_critical=1.6959
lower_critical=1.6371
lower_non_recoverable=1.6077
8 P1V5 alarm=0 value=1.4901 threshold_status=0
type=2/1
upper_non_recoverable=1.6763
upper_critical=1.6469
upper_non_critical=1.5979
lower_non_critical=1.4117
lower_critical=1.3627
lower_non_recoverable=1.3333
9 PCH +1.05V alarm=0 value=1.024 threshold_status=0
type=2/1
upper_non_recoverable=1.168
upper_critical=1.152
upper_non_critical=1.12
lower_non_critical=0.944
lower_critical=0.912
lower_non_recoverable=0.896
10 VCC 2V5 alarm=0 value=2.464 threshold_status=0
type=2/1
upper_non_recoverable=2.88
upper_critical=2.816
upper_non_critical=2.784
lower_non_critical=2.24
lower_critical=2.208
lower_non_recoverable=2.144
11 MAIN 12V alarm=0 value=11.904 threshold_status=0
type=2/1
upper_non_recoverable=13.824
upper_critical=13.632
upper_non_critical=13.248
lower_non_critical=10.944
lower_critical=10.56
lower_non_recoverable=10.368
12 VCC 1V15 alarm=0 value=1.136 threshold_status=0
type=2/1
upper_non_recoverable=1.232
upper_critical=1.2
upper_non_critical=1.168
lower_non_critical=1.04
lower_critical=1.008
lower_non_recoverable=0.992
13 DDR3 VTT alarm=0 value=0.72 threshold_status=0
type=2/1
upper_non_recoverable=0.848
upper_critical=0.832
upper_non_critical=0.8
lower_non_critical=0.704
lower_critical=0.688
lower_non_recoverable=0.672
14 RPS 12V alarm=1 value=0 threshold_status=0x7
type=2/1
upper_non_recoverable=13.824
upper_critical=13.632
upper_non_critical=13.248
lower_non_critical=10.944
lower_critical=10.56
lower_non_recoverable=10.368
15 NCT +3.3V alarm=0 value=3.264 threshold_status=0
type=2/1
upper_non_recoverable=3.696
upper_critical=3.648
upper_non_critical=3.552
lower_non_critical=3.12
lower_critical=2.976
lower_non_recoverable=2.928
16 NCT VBAT alarm=0 value=3.264 threshold_status=0
type=2/1
upper_non_recoverable=3.696
upper_critical=3.648
upper_non_critical=3.552
lower_non_critical=3.12
lower_critical=2.976
lower_non_recoverable=2.928
17 NCT +3.3VSB alarm=0 value=3.216 threshold_status=0
type=2/1
upper_non_recoverable=3.696
upper_critical=3.648
upper_non_critical=3.552
lower_non_critical=3.12
lower_critical=2.976
lower_non_recoverable=2.928
18 NCT VTT alarm=0 value=1.04 threshold_status=0
type=2/1
upper_non_recoverable=1.168
upper_critical=1.152
upper_non_critical=1.12
lower_non_critical=0.944
lower_critical=0.912
lower_non_recoverable=0.896
19 DTS CPU alarm=0 value=64 threshold_status=0
type=1/1
upper_non_recoverable=110
upper_critical=105
upper_non_critical=100
20 CPU Core 0 alarm=0 value=65 threshold_status=0
type=1/1
upper_non_recoverable=92
upper_critical=91
upper_non_critical=86
21 CPU Core 1 alarm=0 value=64 threshold_status=0
type=1/1
upper_non_recoverable=92
upper_critical=91
upper_non_critical=86
22 TD1 alarm=0 value=52 threshold_status=0
type=1/1
upper_non_recoverable=110
upper_critical=105
upper_non_critical=100
23 TD2 alarm=0 value=39 threshold_status=0
type=1/1
upper_non_recoverable=110
upper_critical=105
upper_non_critical=100
24 FAN_TMP_3 alarm=0 value=51 threshold_status=0
type=1/1
upper_non_recoverable=110
upper_critical=105
upper_non_critical=100
25 LM75 U72 alarm=0 value=46 threshold_status=0
type=1/1
upper_non_recoverable=110
upper_critical=105
upper_non_critical=100
26 LM75 U65 alarm=0 value=46 threshold_status=0
type=1/1
upper_non_recoverable=110
upper_critical=105
upper_non_critical=100
27 LM75 U62 alarm=0 value=50 threshold_status=0
type=1/1
upper_non_recoverable=110
upper_critical=105
upper_non_critical=100
28 FAN1 alarm=0 value=5700 threshold_status=0
type=4/1
upper_non_recoverable=23000
upper_critical=22000
upper_non_critical=21000
lower_non_critical=300
lower_critical=200
lower_non_recoverable=100
29 FAN2 alarm=0 value=5800 threshold_status=0
type=4/1
upper_non_recoverable=23000
upper_critical=22000
upper_non_critical=21000
lower_non_critical=300
lower_critical=200
lower_non_recoverable=100
30 FAN3 alarm=0 value=5600 threshold_status=0
type=4/1
upper_non_recoverable=23000
upper_critical=22000
upper_non_critical=21000
lower_non_critical=300
lower_critical=200
lower_non_recoverable=100
|
|
|
Falls die FortiGate über keinen Temperatursensor verfügt, wird in der CLI beim eingeben des Befehls eine Fehlermeldung erscheinen: # execute sensor list command parse error before 'sensor' Command fail. Return code -61 |
Disk
Wie kann ich auf einer FortiGate, die auf der Disk enthaltenen Daten (inkl. Boot Device) vollumfänglich (low level) löschen?
Es gibt die Möglichkeit die internal Disk und/oder den "System Boot Device" über "low level" zu formatieren. Dies kommt dann zum Zuge, wenn ein Device entsorgt wird oder dem Hersteller wegen eines RMA Falls retourniert wird. So wird gewährleistet, dass sämtliche Daten auf der Disk gelöscht werden. Bei der "low level" Formatierung werden die Spuren und Sektoren der "Disk", respektive des "System Boot Device's" mit zufälligen Daten 3mal überschrieben. Mit dieser Methode wird gesorgt, dass die vorhandenen Daten komplett gelöscht werden. Den Vorgang startet man über folgenden CLI Befehl:
| Konfiguration über die CLI:
|
# execute erase-disk [SYSTEM | Internal] |
Wenn ein Device aus Gründen der "Security" bei einem RMA Austausch nicht dem Hersteller zurückgesendet werden kann, obwohl die Möglichkeit einer "low level" Formatierung zur Verfügung steht, bietet Fortinet innerhalb des "FortiCare" einen speziellen Vertrag an, welcher es ermöglicht bei einem RMA Austausch das Device selber zu entsorgen, anstelle dies dem Hersteller zurück zu senden. Dieser Service wird "FortiCare RMA Secure Service" genannt. Weitere Informationen sind folgendem Artikel zu entnehmen:
Fortinet:Support-RMA#Gibt_es_von_Fortinet_einen_.22FortiCare_Secure_RMA_Service.22.3F
Wie kann ich die Disk (Flash, SSD) eines FortiGate Device testen um zu überprüfen, ob diese fehlerhaft ist?
Anhand des Befehls "diagnose disktest" kann auf einer FortiGate die Disk getestet werden. Dazu sollte berücksichtigt werden, dass dieser Test in einem Maintenance-Fenster durchgeführt wird und nicht bei hoher Last. Um diesen Test zu benutzen muss die entsprechende Disk ausgewählt werden. Die Disk's können mit folgendem Behfel aufgelistet werden:
|
|
Der Test kann seine Zeit dauern dh. bei einer 60D ohne zusätzlichen Optionen dh. no Limit, läuft der Test für 7728M ca 45 Minuten! Dies gilt für "Round 1" denn sobald diese beendet ist beginnt der Test erneut dh. "Round 2". Der Test kann anhand "Ctrl + C" abgebrochen werden. Wenn dies durchgeführt wird erscheint folgendes: "User interrupt! Restoring data back to disk....". |
Wie schon erwähnt muss für einen Test die entsprechende Disk zuerst ausgewählt werden. Daraus ergibt sich folgendes Vorgehen:
| Liste die vorhandenen Device's auf: |
# diagnose disktest device ? 1 /dev/sda, size 3864MB, boot device 2 /dev/sdb, size 7728MB |
| Selektieren die gewünschte Disk zB /dev/sdb dh. "2": |
# diagnose disktest device 2 Current Test Device: /dev/sdb |
| Setze für den Test verschiedene Optionen: |
# diagnose disktest [block | time | size]
Die Optionen haben folgende Bedeutung:
block Die Blocksize für jede Lese- sowie Schreiboperation.
timeDie Limite der Testzeit für jeden Zyklus. Standard: "keine Limite".
sizeDie Limite der Testgrösse für jeden Zyklus. Standard: "keine Limite".
|
| Wenn das gewünschte Device gesetzt/gewählt wurde/ist, sowie falls notwendig die Optionen konfiguriert wurden, führe den Test aus: |
# diagnose disktest run Round 1 started. Current Test Device: /dev/sdb Total size: 7728M Current Test Block: 4M. Current Time Limit: No limit Current Size Limit: No limit Time(Sec) Size(MB) Read(MB/s) Write(MB/s) 0.00(0.00%): .................................................. 15.0 8.6 76.0 200(2.59%): .................................................. 15.1 8.9 150.2 400(5.18%): .................................................. 15.0 9.0 224.3 600(7.76%): .................................................. 15.0 8.9 298.8 800(10.35%): .................................................. 15.1 8.9 372.9 1000(12.94%): .................................................. 15.1 9.0 446.9 1200(15.53%): .................................................. 15.1 9.0 520.7 1400(18.12%): .................................................. 15.2 9.0 594.4 1600(20.70%): .................................................. 15.1 9.0 668.4 1800(23.29%): .................................................. 15.2 9.0 742.1 2000(25.88%): .................................................. 15.3 9.0 815.8 2200(28.47%): .................................................. 15.3 9.0 889.5 2400(31.06%): .................................................. 15.3 8.9 963.1 2600(33.64%): .................................................. 15.4 9.0 1036.7 2800(36.23%): .................................................. 15.3 9.0 1110.3 3000(38.82%): .................................................. 15.3 9.0 1183.9 3200(41.41%): .................................................. 15.3 9.0 1257.6 3400(44.00%): .................................................. 15.3 9.0 1331.2 3600(46.58%): .................................................. 15.3 9.0 1404.7 3800(49.17%): .................................................. 15.3 9.0 1478.3 4000(51.76%): .................................................. 15.3 9.0 1551.9 4200(54.35%): .................................................. 15.2 8.9 1625.8 4400(56.94%): .................................................. 14.5 8.6 1702.5 4600(59.52%): .................................................. 15.0 8.8 1777.3 4800(62.11%): .................................................. 15.2 8.9 1851.6 5000(64.70%): .................................................. 15.1 8.9 1925.9 5200(67.29%): .................................................. 15.1 8.9 2000.3 5400(69.88%): .................................................. 15.1 8.9 2074.7 5600(72.46%): .................................................. 15.1 8.9 2148.9 5800(75.05%): .................................................. 15.2 8.9 2223.2 6000(77.64%): .................................................. 15.2 8.8 2297.5 6200(80.23%): .................................................. 15.1 8.9 2371.9 6400(82.82%): .................................................. 15.2 8.9 2446.2 6600(85.40%): .................................................. 15.1 8.9 2520.5 6800(87.99%): .................................................. 15.3 8.9 2594.6 7000(90.58%): .................................................. 14.6 8.6 2671.4 7200(93.17%): .................................................. 15.1 8.4 2748.0 7400(95.76%): .................................................. 15.3 5.4 2851.2 7600(98.34%): ................................ Test Result: Passed Tested size: 7728MB (100.00% Coverage of whole disk) Time used: 2901.5 sec Read Speed: 15.2MB/s Write Speed: 8.7MB/s Round 1 Finished! Round 2 started. Current Test Device: /dev/sdb Total size: 7728M Current Test Block: 4M. Current Time Limit: No limit Current Size Limit: No limit Time(Sec) Size(MB) Read(MB/s) Write(MB/s) 0.00(0.00%): .................................................. 14.7 8.4 77.9 200(2.59%): .............User interrupt! Restoring data back to disk... Test Result: Interrupted Tested size: 256MB (3.31% Coverage of whole disk) Time used: 99.3 sec Read Speed: 14.7MB/s Write Speed: 8.4MB/s Round 2 Finished! |
Wird bei einem "unclean shutdown" auf einem FortiGate Device beim Systemstart ein "filesystem check" durchgeführt?
Ab der Version 5.2.x wurde diese Funktion integriert sowie zusätzlich die Möglichkeit die Disk explizit manuell zu testen. Weitere Informationen wie man einen "expliziten" Disk Test manuell zeigt folgender Artikel:
FortiGate-5.4-5.6:FAQ#Wie_kann_ich_die_Disk_.28Flash.2C_SSD.29_eines_FortiGate_Device_testen_um_zu_.C3.BCberpr.C3.BCfen_ob_diese_Fehler_enth.C3.A4lt.3F
Wie erwähnt wurde für ein "unclean shutdown" (zBsp bei Stromunterbruch) im FortiOS 5.2.x die Funktion eingebaut, dass nach einem "unclean shutdwown" während dem Start-Prozess dies erkannt, und automatisch ein "filesystem check" ausgeführt wird. Diese wird "nicht" anhand eines "expliziten" Disk Tst aufgeführt sondern ähnelt einem "fsck" welcher auf einem Linux System ausgeführt wird. In diesem Vorgang wird durch das System bemerkt dass ein "unclean shutdown" stattgefunden hat. Dies wird ebenfalls indiziert in dem beim Start auf der Console folgendes erscheint:
System is starting...
Starting system maintenance...
scanning /dev/sda2... (100%)
In vorhergehenden Versionen des FortiOS dh. zBsp 5.0 wurde dieser "filesystem check" beim Start des Devices durchgeführt. Solch ein "filesystem check" kann einige Zeit in Anspruch nehmen und deshalb wurde die Vorgehensweise ab der FortiOS Version 5.2.3 geändert. Dies bedeutet: Wenn ein "unclean shutdown" stattfindet (ab FortiOS Version 5.2.3), wird kein "filesystem check" mehr direkt beim Neustart des Device ausgeführt sondern nur ein "system maintenace" indiziert. Sobald sich der Administrator auf dem Web Mgmt. Interface einloggt wird ein entsprechender Dialog angezeigt der durch den "unclean shutdown" ausgelöst wurde:
Durch diesen Dialog hat der Administrator die Möglichkeit den "filesystem check" auszuführen oder diesen auf einen späteren Zeitpunkt zu verschieben. Wird der "filesystem check" nach dem einloggen des Administrators ausgeführt, so erfolgt ein Neustart des Devices und dieser "filesystem check" wird beim Neustart ausgeführt. Wie schon erwähnt kann dieser "filesystem check" durchaus mehrere Minuten in Anspruch nehmen und der Vorgang sollte auf keinen Fall unterbrochen werden! Wird diese "filesystem check" Meldung beim einloggen auf das Web Mgmt. Interface anhand "Remind me later" auf einen späteren Zeitpunkt verschoben, wird die Meldung nach jedem einloggen angezeigt bis dieser "filesystem check" ausgeführt wird!
PowerSupply
Kann man für FortiGate's seperate spare und / oder redundante PowerSupply (RPS) beziehen?
Für die verschiedenen FortiGate Devices stellt Fortinet seperate "PowerSupplies" zur Verfügung. Für grössere Devices stehen zusätzlich für die Redundanz "RPS Devices" (Redundand PowerSupply) zur Verfügung. Welche Geräte kompatibel sind zu den seperaten "RPS Devices" können nachfolgendem Artikel entnommen werden:
Fortinet:ProduktInfo#FortiRPS
Nachfolgende Tabelle zeigt für welches FortiGate Device welches sperat zu beziehende "PowerSupply" bestellt werden kann:
Regulatory Doc Datei:Regulatory-Compliance-Document SP-FG600C-PS Rev 1.00.pdf Regulatory Doc Datei:Regulatory-Compliance-Document SP-FG60C-PDC Rev 1.01.pdf Regulatory Doc Datei:Regulatory-Compliance-Document SP-FG80-PDC Rev 1.pdf
Nachfolgend einige erfasste ALSO Schweiz Artikel betreffend "PowerSupply":
ALSO Art Nr. Hersteller SKU Beschreibung
2694237 SP-FG20C-PA-EU AC power adaptor with EU power plug for FG/FWF-20C series, FG/FWF-30D
2707193 SP-FG30E-PA-EU AC power adaptor with EU power plug for FG-50E, FG-51E, FWF-50E, FWF-51E, FG-30E, FWF-30E
2691555 SP-FG80-PDC AC power adaptor - AC power adaptor for FG/FWF-80C/CM
2690832 SP-FG60C-PDC AC power adaptor - AC power adaptor for FG/FWF-40C, FG/FWF-60C, FG/FWF-60D, FG-70D, FG/FWF-90D
2692305 SP-FG600C-PS AC power supply - AC power supply for FG-600C, FG-600D, FG-800C, and FG-1000C
2698983 SP-FG1240B-PS AC power supply - AC power supply for FG-1200D, FG-1240B, FG-1500D, FG-3040B and FG-3140B
Ebenso stehen für die FortiAP, wie auch für die FortiAP-S "PowerSupplies" zur Verfügung. Weitere Informationen dazu siehe nachstehenden Artikel:
FortiAP:FAQ#Wo_finde_ich_eine_Uebersicht_ob_ein_FortiAP_mit_PowerAdapter_geliefert_wird_oder_PoE_unterst.C3.BCtzt.3F FortiAP-S:FAQ#Wo_finde_ich_eine_Uebersicht_ob_ein_FortiAP-S_mit_PowerAdapter_geliefert_wird_oder_PoE_unterst.C3.BCtzt.3F
SFP Ports
Kann ich für die SFP Ports auf einer FortiGate ebenfalls Fremdprodukte, wie Cisco oder Huawei einsetzen?
Dies ist möglich, jedoch empfehlen wir dies vorgängig ausgiebig zu testen! Von unserer Seite her haben wir Tests sowie Feedback das folgende Transceiver einwandfrei funktionieren:
Copper GigaBit 10/100/1000
GLC-T=746320861579 Cisco Catalyst GigaEthernet SFP Modul 1000Base T
02314171 Huawei Electrical Transceiver SFP Module 1000Base T
NOTE Durch Fortinet werden ebenfalls nicht eigene Transceiver eingesetzt sondern von Fremdherstellern dh. wird ein Transceiver
über Fortinet bestellt, wird ein Transceiver zBsp von Huawei geliefert! Weitere Informationen betreffend "offizielle" SFP/SFP+
Module von Fortinet, sowie den Gebrauch von "nicht offiziellen" siehe folgender Artikel:
FortiGate-5.4-5.6:FAQ#Kann_ich_f.C3.BCr_die_SFP_Ports_auf_einer_FortiGate_ebenfalls_Fremdprodukte_wie_Cisco_oder_Huawai_einsetzen.3F
Welche FortiGate Devices unterstützen SFP's und bei welchen FortiGate Devices werden SFP's mitgeliefert?
Nachfolgende Tabelle zeigt welche FortiGate Devices wieviele SFP's unterstützen und bei welchem FortiGate Device bereits SFP Module mitgeliefert werden:
NOTE NIL = Not Included!
Es können für die FortiGate Devices auch Fremdprodukte als SFP's eingesetzt werden, jedoch gibt es keine Gewährleistung dass diese einwandfrei funktionieren. Weitere Infos siehe nachfolgender Artikel:
FortiGate-5.4-5.6:FAQ#Kann_ich_f.C3.BCr_die_SFP_Ports_auf_einer_FortiGate_ebenfalls_Fremdprodukte_wie_Cisco_oder_Huawai_einsetzen.3F) NOTE Des Weiteren ist nachfolgendes Dokument zu beachten, wenn keine "offiziellen" Tranceiver von Fortinet eingesetzt werden (speziell Seite 2 "3rd Party Transceivers Support"): Datei:Tech Note-Transceivers FAQs-201407-R3.pdf
Basierend auf den "offiziellen" Tranceiver von Fortinet gemäss Preisliste stehen folgende SFP/SFP+ Module zur Verfügung:
Transceiver LX, Long Range; all FortiGate models with SFP interfaces ALSO SKU 2690418 (Hersteller SKU FG-TRAN-LX)
Transceiver SX, Short Range; all FortiGate models with SFP interfaces ALSO SKU 2690421 (Hersteller SKU FG-TRAN-SX)
Transceiver Base-T (Copper); all FortiGate models with SFP interfaces (supports 10/100/1000) ALSO SKU 2690420 (Hersteller SKU FG-TRAN-GC)
10-Gig transceiver, short range SFP+; all FortiGate models with SFP+ interfaces ALSO SKU 2697310 (Hersteller SKU FG-TRAN-SFP+SR)
10-Gig transceiver, short range XFP; all FortiGate models with XFP interfaces ALSO SKU 2690412 (Hersteller SKU FG-TRAN-XFPSR)
10-Gig transceiver, SFP+, Long Range; all FortiGate models with SFP+ interfaces ALSO SKU 2690413 (Hersteller SKU FG-TRAN-SFP+LR)
10-Gig transceiver, XFP, Long Range; all FortiGate models with XFP interfaces ALSO SKU 2690414 (Hersteller SKU FG-TRAN-XFPLR)
40-Gig transceiver, QSFP+, short range; all FortiGate models with QSFP+ interfaces ALSO SKU 2694715 (Hersteller SKU FG-TRAN-QSFP+SR)
40-Gig transceiver, QSFP+, long range; all FortiGate models with QSFP+ interfaces ALSO SKU auf Anfrage (Hersteller SKU FG-TRAN-QSFP+LR)
100-Gig transceiver, CFP2, short Range; all FortiGate models with CFP2 interfaces (10 Channel parallel fiber) ALSO SKU auf Anfrage (Hersteller SKU FG-TRAN-CFP2-SR10)
100-Gig transceiver, CFP2, long Range; all FortiGate models with CFP2 interfaces (only singlemode) ALSO SKU 2707368 (Hersteller SKU FG-TRAN-CFP2-LR4)
Für eine direkte Verbindung zweier Fortigates über ein "direct attach cable" steht folgender Artikel zu Verfügung:
10-Gig transceiver, SFP+, 10m direct attach cable; all FortiGate models with SFP+ and SFP/SFP+ interfaces ALSO SKU auf Anfrage (Hersteller SKU SP-Cable-ADASFP+)
Eine detaillierte Beschreibung der Tranceivereigenschaften können folgendem Dokument entnommen werden:
Was sind die genauen Spezifikationen der SFP's Module welche von Fortinet für die FortiGate Devices geliefert werden?
Im nachfolgenden Artikel wird beschrieben ob ein SFP/SFP+ Module zu einer FortiGate mitgeliefert wird, und welche SFP/SFP+ Module offiziell zu den FortiGate's zur Verfügung stehen:
FortiGate-5.4-5.6:FAQ#Welche_FortiGate_Device.27s_unterst.C3.BCtzen_SFP.27s_und_bei_welchen_FortiGate_Devices_werden_SFP.27s_mitgeliefert.3F
In der nachfolgenden Tabelle werden die technischen Spezifikationen der SFP Module aufgelistet welche von Fortinet für die FortiGate Devices geliefert werden:
NOTE Die Informationen stammen aus einem Fortinet "Knowledgebase Artikel" über welchen auch weitere Informationen verfügbar sind:
http://kb.fortinet.com/kb/dynamickc.do?cmd=show&forward=nonthreadedKC&docType=kc&externalId=13823&sliceId=1
Transceivers
Breackout Cables
Nachfolgend das offizielle "Regulatory Compliance Document" betreffend SFP SX Transceiver:
Regulatory Doc Datei:Regulatory-Compliance-Document FG-TRAN-SX Rev 1.03.pdf Regulatory Doc Datei:Regulatory-Compliance-Document FG-TRAN-CFP2-LR4 Rev 1.00.pdf Regulatory Doc Datei:Regulatory-Compliance-Document FG-TRAN-CFP2-SR10 Rev 1.00.pdf Regulatory Doc Datei:Regulatory-Compliance-Document FG-TRAN-GC Rev 1.02.pdf Regulatory Doc Datei:Regulatory-Compliance-Document FG-TRAN-GC Rev 2.0.pdf Regulatory Doc Datei:Regulatory-Compliance-Document FG-TRAN-LX Rev 2.0.pdf Regulatory Doc Datei:Regulatory-Compliance-Document FG-TRAN-QSFP+-LR Rev 1.00.pdf Regulatory Doc Datei:Regulatory-Compliance-Document FG-TRAN-QSFP+-SR Rev 1.00.pdf Regulatory Doc Datei:Regulatory-Compliance-Document FG-TRAN-SFF Rev 1.00.pdf Regulatory Doc Datei:Regulatory-Compliance-Document FG-TRAN-SFP+-LR Rev 2.0.pdf Regulatory Doc Datei:Regulatory-Compliance-Document FG-TRAN-SFP+-SR Rev 2.0.pdf Regulatory Doc Datei:Regulatory-Compliance-Document FG-TRAN-SFP+-SX Rev 1.02.pdf Regulatory Doc Datei:Regulatory-Compliance-Document FG-TRAN-XFPLR Rev 1.00.pdf Regulatory Doc Datei:Regulatory-Compliance-Document FG-TRAN-XFPSR Rev 1.00.pdf
Wie kann ich ein SFP Module / Tranceiver für ein FortiGate Device überprüfen?
Bis anhin war es nicht möglich über ein FortiGate Device dh. via ein FortiOS ein SFP Module/Tranceiver zu überprüfen dh. zBsp ob dieser korrekt erkannt wurde. Neu, unter FortiOS 5.4 ist dies anhand nachfolgendem Befehl möglich für Devices der FortiGate D-Serie, sowie FGT-1000D oder grösser und für SFP und QSFP Module/Transceiver. Handelt es sich um ein SFP/QSFP Fiber Module/Tranceiver kann ebenfalls die Temperatur, Spannung sowie Optical Power abgefragt werden. Wird ein Fremdprodukt als SFP/QSFP Module/Transceiver eingesetzt, sollte dies kurz anhand des nachfolgenden Befehls überprüft werden:
# get system interface transceiver
Interface port9: SFP/SFP+
Vendor Name: Axcen Photonics
Part No. : AXXE-5886-05B1
Serial No. : AX14170008967
Interface port10: SFP or QSFP transceiver is not detected.
Interface port11: SFP/SFP+
Vendor Name: FIBERXON INC.
Part No. : FTM-8012C-SL
Serial No. : A8660061719307
Optical Optical Optical
SFP/SFP+ Temperature Voltage Tx Bias Tx Power Rx Power
Interface (Celsius) (Volts) (mA) (dBm) (dBm)
------------ ----------- --------- --------- --------- --------
port9 34.1 3.31 6.35 -1.9 -40.0 --
port11 N/A N/A N/A N/A N/A
++ : high alarm, + : high warning, - : low warning, -- : low alarm, ? : suspect.
Wieso werden Fortinet SFP Module als "unsupportet 3rd Party Module" im FortiOS 6.2.2 angezeigt?
Im FortiOS 6.2.2 werden SFP Transceiver, welche als orginal Fortinet Transeiver erworben wurden, zum Teil als "nicht supportet 3rd Party Module" angezeigt:
Es handelt sich hierbei um einen BUG. Dieser sollte im FortiOS 6.2.3 behoben werden:
Diese Information haben wir durch ein L1 Supportticket vom TAC bekommen:
I have looked into this and found engineering ticket 563053 in where this exact behavior was discussed.
For the FG-TRAN-SFP+SR, these were shipped with different vendor names other than Fortinet.
Due to a bug in 6.2.2, these are now showing as third party devices - this has been identified and scheduled to be fixed in 6.2.3.
SPU
Wo und wie wird meine SPU auf der FortiGate verwendet?
Auf der folgenden Tabelle kann ermittelt werden welcher Prozessor für welche Aufgabe zuständig ist:
| System Performanz | Verantwortliche Komponente |
|---|---|
| Firwall Durchsatz | NP Aceleration |
| Firwall Latenz | NP Aceleration |
| Firwall Durchsatz (Pakete per Sekunde) | NP Aceleration |
| Gleichzeitige Sessions | Memorie |
| IPsec VPN Durchsatz | NP Aceleration |
| IPS Durchsatz | CP + CPU (NTurbo) |
| SSL Inspektions Durchsatz | CP + CPU |
| Applikationskontrolle Durchsatz | CP + CPU (NTurbo) |
| NGFW Durchsatz | CP + CPU (NTurbo) |
| Threat Protection Durchsatz | CP + CPU (NTurbo) |
FortiOS
FortiGuard (FDDS)
Wie kann ich auf einer FortiGate einen FortiManager für FortiGuard konfigurieren?
Wenn eine FortiGate so konfiguriert werden soll, dass diese die Updates der FortiGuard über einen FortiManager durchführen soll, so kann dies via CLI konfiguriert werden. Wenn ein FortiGate Device ausschliesslich einen FortiManager für den FortiGuard Server nutzen soll, so kann dies wie folgt konfiguriert werden:
# config system central-management
# config server-list
# edit [vergebe einen entsprechenden Integer zBsp "1"]
# set server-type update rating
# set server-address [IPv4 Adresse des FortiManagers für FortiGuard]
# next
# end
# end
Somit kann zBsp auch ein dezidierter FortiManager konfiguriert werden, welcher nur für FortiGuard zur Verfügung steht und ein zweiter FortiManager welcher das Management der FortiGate übernimmt:
# config system central-management
# set type fortimanager
# set fmg [IPv4 Adresse des FortiManagers für das Device Management]
# config server-list
# edit [vergebe einen entsprechenden Integer zBsp "1"]
# set server-type update rating
# set server-address [IPv4 Adresse des FortiManagers für FortiGuard]
# next
# end
# end
FortiCloud
FortiSandbox
Wieviele Dateien kann ich pro Tag in die FortiSandbox Cloud hochladen?
Wenn man die AntiVirus Lizenz, und mindestens das FortiOS 6.0.1 auf der FortiGate installiert hat, kann die FortiCloud Sandbox genutzt werden.
Folgende Limitierungen gibt es von der Anzahl Files welche pro Tag in die Cloud hochgeladen werden können. Dabei spielt ist die Grösse der FortiGate massgebend:
| Limiten für das hochladen auf die FortiCloud Sandbox: |
|
Referenz: DESCRIPTION FORTISANDBOX CLOUD |
| Konfiguration über das WebGui:
|
|
Über das WebGui der FortiGate kann im Dashboard die aktuelle Quote angezeigt werden: (Beispiel hier einer FortiGate 60F): |
FortiExplorer
USB Port
Was ist beim benutzen eines USB-Sticks an einer FortiGate zu berücksichtigen?
Wenn ein USB-Stick über eine FortiGate formatiert werden soll, so wird dieser im "FAT" Format formatiert! Um den USB Stick über das FortiOS zu formatiert wird folgende Vorgehensweise über die CLI angewendet:
| Konfiguration via CLI:
|
# execute usb-disk format This operation will ERASE all data in USB disk! Do you want to continue? (y/n)'''y''' Format USB disk /dev/sdc1 ... Create file system on /dev/sdc1 ... |
Danach kann der USB-Stick genutzt werden um zBsp ein Forti-Backup auf den USB-Stick zu spielen. Möchte man den USB-Stick vorbereiten, resp. nicht über das FortiOS formatieren, sondern zBsp unter Windows 10, so kann folgendes ausgeführt werden:
- Verbinde den USB-Stick mit der Workstation und verifiziere den zugewiesenen Laufwerksbuchstaben!
- Jetzt eine DOS-Box öffnen (unter Windows 10 = Windows durchsuchen > cmd )
- Danach gebe in der DOS-Box folgendes ein:
| DOS/Shell CMD: |
format [Laufwerks Name zBsp "F"]: /FS:FAT /V:[Name des USB-Sticks/Laufwerk zBsp "FortiGate"]
legen Sie eine neue Diskette in Laufwerk D: ein,
und drücken Sie die EINGABETASTE.
Der Typ des Dateisystems ist EXFAT.
Das neue Dateisystem ist FAT.
Überprüfung von 1009.4 MB
Die Dateizuordnungstabelle (FAT) wird initialisiert...
Formatieren beendet.
1009.1 MB Speicherplatz auf dem Datenträger insgesamt.
1009.1 MB sind verfügbar.
16'384 Bytes in jeder Zuordnungseinheit
64'585 Zuordnungseinheiten auf dem Datenträger verfügbar
16 Bits in jedem FAT-Datensatz.
Volumeseriennummer : 4E6E-9DDF
|
Kann ich ein "Image"/ eine Konfiguration über einen USB-Stick automatisiert auf eine FortiGate aufspielen?
Eine Automatisierung einer Installation einer FortiGate mit einer entsprechenden Konfiguration lässt sich über einen USB-Stick komplett automatisieren.
| Konfiguration über das WebGui:
|
|
| Konfiguration über die CLI:
|
# config system auto-install # set auto-install-config [enable oder disable] # set auto-install-image [enable oder disable] # set default-config-file [File Name] # set default-image-file [File Name] # end |
Die Voraussetzung, dass über einen USB-Stick diese "USB Auto-Install" Funktion genutzt werden kann, ist ein korrekt formatierter USB-Stick. Weitere Informationen dazu siehe nachfolgender Artikel: USB Stick Formatieren Wenn die Funktion des "USB Auto-Install" für das "Image" und/oder "config" File aktiviert, und der USB-Stick entsprechend korrekt formatiert wurde kann in das Root-Verzeichnis des USB-Sticks ein entsprechendes "image" eines FortiOS, wie auch die Konfiguration einer FortiGate, basierend auf dem "image" des FortiOS auf den USB-Stick abgespeichert werden. Dabei müssen die File-Namen des "image", sowie der Konfiguration übereinstimmen mit der Konfiguration resp. Definition des "default-image-file" sowie des "default-config-file"! Wenn nun der USB-Stick an die FortiGate angeschlossen ist, und die FortiGate eingeschaltet oder neu gestartet wird, wird folgendes durchgeführt:
| 1ter Neustart: |
|
Die Funktion "USB Auto-Install" überprüft ob in der aktiven Partition das FortiOS gemäss dem "image" File auf dem USB-Stick installiert ist! Ist dies nicht der Fall wird in der nicht aktiven Partition das FortiOS anhand des "image" Files auf dem USB-Stick installiert! Nach der Installation wird ein Neustart ausgeführt. Ist die aktive Partition mit dem "image" File auf dem USB-Stick identisch, wird eine 2te Neustart-Überprüfung ausgeführt! |
| 2ter Neustart: |
|
Nach der Installation des "images" auf dem USB-Stick, oder bei Übereinstimmung der aktiven Partition mit dem "image" wird geprüft ob die Konfiguration in der aktiven Partition mit dem Konfigurtions-File auf dem USB-Stick übereinstimmt. Ist dies nicht der Fall, wird ein Restore anhand des Konfigurationsfiles auf dem USB-Stick ausgeführt. Ist die Konfiguration auf dem USB-Stick gleich wie jene auf der aktiven Partition wird keine Änderung durchgeführt und der Neustart regulär fortgesetzt! |
Es empfiehlt sich den Vorgang bei einem Test über den Konsolen-Port (RS232) mitzuverfolgen, damit allfällige Fehlermeldungen über die Konsole mitverfolgt werden können. Mit dieser Funktion kann so die FortiGate mit einem entsprechenden "image", sowie mit einer eigenen Konfiguration komplett automatisiert werden. Dabei ist jedoch folgendes zu berücksichtigen: Durch die Funktion "USB Auto-Install" wird die FortiGate nicht von Grundauf neu installiert. Dies bedeutet dass der "boot device" nicht neu formatiert etc. wird wie wenn die FortiGate von Grundauf neu installiert (staging) wird (siehe nachfolgenden Artikel): FortiGate neu Staggen
Kann ich ein "image"/ eine Konfiguration über einen USB Stick automatisiert auf eine FortiGate aufspielen?
Eine Automatisierung einer Installation eines FortiGate Devices mit einer entsprechenden Konfiguration lässt sich über USB Stick komplett automatisieren.
| Konfiguration über das WebGui:
|
|
| Konfiguration über die CLI:
|
# config system auto-install # set auto-install-config [enable oder disable] # set auto-install-image [enable oder disable] # set default-config-file [File Name] # set default-image-file [File Name] # end |
Die Voraussetzung, damit über einen USB Stick diese "USB Auto-Install" Funktion genutzt werden kann, ist ein korrekt formatierter USB Stick. Weitere Informationen dazu siehe nachfolgender Artikel: USB Stick Formatieren Wenn die Funktion des "USB Auto-Install" für das "image" und/oder "config" File aktiviert, und der USB Stick entsprechend korrekt formatiert wurde kann in das Root-Verzeichnis des USB Sticks ein entsprechendes "image" eines FortiOS, wie auch die Konfiguration eines FortiGate Devices, basierend auf dem "image" des FortiOS auf den USB Stick abgespeichert werden. Dabei müssen die Filenamen des "image", sowie der Konfiguration übereinstimmen mit der Konfiguration resp. Definition des "default-image-file" sowie des "default-config-file"! Wenn nun der USB Stick an die FortiGate angeschlossen, und das FortiGate Device eingeschaltet oder neu gestartet wird, wird folgendes durchgeführt:
| 1ter Neustart: |
|
Die Funktion "USB Auto-Install" überprüft ob in der aktiven Partition das FortiOS gemäss dem "image" File auf dem USB Stick installiert ist! Ist dies nicht der Fall wird in der nicht aktiven Partition das FortiOS anhand des "image" Files auf dem USB Stick installiert! Nach der Installation wird ein Neustart ausgeführt. Ist die aktive Partition mit dem "image" File auf dem USB Stick identisch, wird eine 2te Neustart-Überprüfung ausgeführt! |
| 2ter Neustart: |
|
Nach der Installation des "images" auf dem USB Sticks, oder bei Übereinstimmung der aktiven Partition mit dem "image" wird geprüft ob die Konfiguration in der aktiven Partition mit dem Konfigurtionsfileauf dem USB Stick übereinstimmt. Ist dies nicht der Fall, wird ein Restore anhand des Konfigurationsfiles auf dem USB Stick ausgeführt. Ist die Konfiguration auf dem USB Stick gleich wie jene auf der aktiven Partition wird keine Aenderung durchgeführt und der Neustart regulär fortgesetzt! |
Es empfiehlt sich den Vorgang bei einem Test über den Console Port (RS232) mitzuverfolgen damit allfällige Fehlermeldungen über die Console mitverfolgt werden können. Mit dieser Funktion kann somit ein FortiGate Device mit einem entsprechenden "image", sowie mit einer eigenen Konfiguration komplett automatisiert werden. Dabei ist jedoch folgendes zu berücksichtigen: Durch die Funktion "USB Auto-Install" wird ein FortiGate Device nicht von Grundauf neu installiert dh. zBsp der "boot device" wird nicht neu formatiert usw. wie wenn ein FortiGate Device von Grundauf neu installiert (staging) wird (siehe nachfolgenden Artikel): FortiGate neu Staggen
Konsolen Port
Was für ein Kabel wird für den Konsolen-Anschluss (RS-232) benötigt?
Eine Fortigate Firewall kann über den Konsolen-Port, SSH oder HTTPS administriert werden. Für das initiale Setup, wie auch bei der Störungssuche ist der Konsolen-Port die beste Wahl. Der Konsolen-Port auf der FortiGate kommt in Form einer RS232 Schnittstelle daher. Problematisch ist, dass die heutigen Workstations / Laptops nicht mehr über einen RS232 Anschluss verfügen. Als Workaround gibt es Adapterkabel von USB auf RS232. Folgende Adapter bietet ALSO im Sortiment an:
| USB-Stecker Typ A |
|
LINDY USB RS232 Converter w/ COM Port Retention RS-232 Port |
| USB Stecker Typ C |
|
LINDY USB Type C Serial Converter |
Bei beiden Adaptern wird kein RS232-to-RJ45 Kabel mitgeliefert. Dies kann unter folgender ALSO-Artikel-Nr. bezogen werden: 2692654
Nachfolgendes Dokument zeigt wie auf einem MacOSx, basierend auf diesem "USB to RS232 Converter" Adapter konfiguriert wird inklusive der Konfiguration eines TFTP Servers. Dieses Dokument wurde durch einen Kunden zur Verfügung gestellt:
Datei:RS232-USB-Converter-TFTP-Server-Konfig-MacOSx.pdf
Weitere Informationen zur genauen Pinbelegung betreffend Fortinet Appliance und dem seriellen Konsolen-Port siehe nachfolgenden Artikel:
FortiGate-6.0:FAQ#Wie_sieht_die_PIN-Belegung_der_Seriellen_Consolen_.28RS-232_.2F_DB9_.2F_RJ-45_.2F_AUX.29_auf_einem_FortiGate_Device_aus.3F
Wie sieht die Pinbelegung der seriellen Konsolen (RS-232 / DB9 / RJ-45 / AUX) auf der FortiGate aus?
Nachfolgend die technischen Informationen über die Pinbelegung der seriellen Konsole der Fortinet Produkte wie FortiGate, FortiAnalyzer, FortiManager sowie FortiMail. In den meisten Fällen haben die Geräte eine RJ45 Schnittstelle als Konsolen-Port. Ältere Modelle können auch über einen RS-232 DB9 Port verfügen. Es gibt auch Modelle mit einem AUX-Port. Die Geräte haben alle etwas gemeinsam: sie nutzen die gleiche Pinbelegung:
| Pinbelegung RJ45 |
|
|
| Pinbelegung RS232 |
|
|
Kann ich auf einer FortiGate den seriellen Konsolen-Port (RS-232) deaktivieren?
Wenn man zum Beispiel verhindern möchte, dass auf ein Datacenter oder ähnlichem, via seriellen Konsole-Port unerlaubt zugegriffen wird, kann dies mit folgendem Befehl deaktiviert werden:
| Konfiguration über die CLI:
|
# config system console # set login disable # end |
Es wird nur der "Konsolen-Port" deaktiviert und der "USB" Port muss, sofern erwünscht, separat deaktiviert werden:
| Konfiguration über die CLI:
|
# config system console # set fortiexplorer disable # end |
Web-GUI
Wie kann ich den Hostnamen auf der Web-GUI Login Page sichtbar machen?
Wenn man sich über das Web-GUI auf die FortiGate verbindet, wird defaultmässig auf der Anmeldemaske der Hostname der Firewall nicht angezeigt.
Um den Hostname auf der Anmeldemaske zu aktivieren, muss dies über die CLI wie folgt aktiviert werden:
| Konfiguration über die CLI:
|
# config system global # set gui-display-hostname [enable | disable] # end Das Resultat: |
Wie können Abhängigkeiten angezeigt werden?
Damit auf einer FortiGate Firewall Elemente gelöscht werden können, muss zuerst sichergestellt werden, dass keine weiteren Abhängigkeiten (dependencies) von anderen Elementen auf das zu löschende Objekt besteht. Diese Abhängigkeiten können wie folgt angezeigt werden:
Im GUI:
Beispiele von Abhängigkeiten von einem Interface sind jeweils hier zu finden:
Im CLI:
| Konfiguration über die CLI:
|
fgt200-master # diagnose sys cmdb refcnt show system.interface.name port1 entry used by complex system.ha:monitor entry used by table system.dhcp.server:id '3' entry used by child table srcintf:name 'port1' of table firewall.policy:policyid '1' |
CLI
Welche Platzhalter-Variabeln gibt es in der CLI?
Die CLI unterstützt die folgenden Platzhalter-Variabeln. Bei den Variablennamen wird zwischen Gross- und Kleinschreibung unterschieden.
Liste der Platzhalter-Variabeln:
|
Variabel: |
Beschreibung: |
|
$USERFORM |
Die Management Zugriffs Methode (ssh, jsconsole usw.) und die IPv4-Adresse des Administrators, der das Element konfiguriert hat. |
|
$USERNAME |
Der Accountname des Administrators, der das Element konfiguriert hat. |
|
$SerialNum |
Die Serienummer des FortiGate Gerätes |
Beispielsweise kann der Hostname des FortiGate Gerätes auf seine Seriennummer gesetzt werden:
| Konfiguration über die CLI:
|
# config system global # set hostname $SerialNum # end |
Kann ich in der CLI meinen Output nach bestimmten Wörter filtern?
Wenn ich ein show, get oder diagnose Befehl auf der CLI einsetze, bekomme ich oft einen sehr grossen und umfangreichen Ouptut. Daher ist es oft von Nutzen, nur den Output zu sehen, der für mich relevant ist und der Rest nicht angezeigt wird. Im FortiOS kann mit dem grep Befehl der Output gefiltert werden. Der grep-Befehl basiert auf dem Standard-UNIX Grep Befehl, welcher für die Suche nach Textausgaben auf der Basis von regulären Ausdrücken verwendet wird.
Der folgende Befehl zeigt zum Beispiel die MAC-Adresse des internal5 Interfaces an:
| Konfiguration über die CLI:
|
get hardware nic internal5 | grep Current_HWaddr Current_HWaddr 90:6c:ac:a9:d7:47 |
Der folgende Befehl zeigt alle TCP Sessions an, inklusive Zeilennummer welche sich in der Session Liste befinden:
| Konfiguration über die CLI:
|
# get system session list | grep -n tcp 5:tcp 3187 198.18.1.18:54740 146.4.73.70:54740 40.67.254.36:443 - 7:tcp 3544 198.18.1.208:54324 146.4.73.70:54324 40.67.254.36:443 - 10:tcp 3597 198.18.0.1:1065 - 198.18.0.12:514 - 13:tcp 3587 198.18.1.10:64704 146.4.73.70:64704 172.217.168.74:443 - 24:tcp 3593 198.18.1.63:46340 146.4.73.70:46340 52.5.144.164:443 - 27:tcp 9 198.18.0.200:53041 146.4.73.66:53041 172.16.0.1:8013 - 28:tcp 8 198.18.1.143:300 146.4.73.70:811 10.3.0.1:111 - 36:tcp 3597 198.18.1.166:50320 146.4.73.70:50320 54.156.181.70:443 - 51:tcp 3 198.18.0.200:53028 146.4.73.66:53028 172.16.0.1:8013 - 52:tcp 2 198.18.1.178:46020 146.4.73.70:46020 192.168.1.176:389 - 53:tcp 3573 198.18.0.200:52815 146.4.73.66:52815 185.60.216.53:443 - 55:tcp 2469 198.18.1.142:57170 146.4.73.70:57170 40.67.254.36:443 - 56:tcp 3596 198.18.0.1:1415 - 198.18.0.12:514 - 73:tcp 8 198.18.0.21:65394 146.4.73.66:65394 52.5.76.173:8347 - 74:tcp 3 198.18.0.11:38838 217.193.240.162:38838 96.45.33.86:443 - 76:tcp 7 198.18.0.1:14681 - 198.18.0.101:8000 - 81:tcp 3590 198.18.1.63:48378 146.4.73.70:48378 54.84.191.209:443 - 86:tcp 9 198.18.200.45:29948 146.4.73.68:29948 194.115.91.54:25 - 91:tcp 3595 198.18.1.163:55696 146.4.73.70:55696 192.146.155.80:443 - 92:tcp 3600 198.18.0.200:52835 - 198.18.0.1:22 - 102:tcp 8 198.18.0.9:34137 146.4.73.66:34137 198.18.6.10:139 - 105:tcp 5 198.18.0.200:53029 146.4.73.66:53029 172.16.0.1:8013 - 107:tcp 3490 198.18.0.200:52729 146.4.73.66:52729 40.67.251.132:443 - 118:tcp 3599 198.18.1.163:54718 146.4.73.70:54718 192.146.155.82:443 - 119:tcp 0 198.18.1.163:53038 146.4.73.70:53038 192.146.155.81:443 - 120:tcp 3513 198.18.1.18:56352 146.4.73.70:56352 40.79.67.176:443 - 126:tcp 3586 172.16.99.4:55785 146.4.73.71:55785 13.224.96.67:443 - 129:tcp 3599 172.16.99.4:57452 146.4.73.71:57452 172.217.168.46:443 - 144:tcp 3572 198.18.1.10:49867 146.4.73.70:49867 54.186.97.86:443 - 148:tcp 6 198.18.0.200:53034 146.4.73.66:53034 172.16.0.1:8013 - 150:tcp 3599 198.18.1.163:42980 146.4.73.70:42980 192.146.155.76:443 - 151:tcp 3598 198.18.0.1:24004 - 198.18.0.11:541 - 152:tcp 3595 198.18.0.1:1073 - 198.18.0.12:514 - 167:tcp 1 198.18.0.200:53017 146.4.73.66:53017 172.16.0.1:8013 - 169:tcp 3589 146.4.73.66:9421 - 154.45.1.53:514 - 173:tcp 3599 198.18.1.209:37791 146.4.73.70:37791 3.135.144.181:443 - 175:tcp 3583 198.18.1.224:57385 146.4.73.70:57385 13.59.223.49:443 - 176:tcp 3585 198.18.1.2:44996 146.4.73.70:44996 3.212.241.156:443 - 177:tcp 3595 198.18.0.1:1074 - 198.18.0.12:514 - |
Der folgende Befehl zeigt alle Zeilen in der HTTP Replacement-Message an, die das Wort URL oder url enthalten:
show system replacemsg http | grep -i url
Weitere Optionen die verfügbar sind:
- -A <num> After (Nachher)
- -B <num> Before (Vorher)
- -C <num> Context (Kontext)
Die Option -f ist verfügbar, um kontextuelle Ausgaben zu unterstützen und die komplette Konfiguration anzuzeigen. Das folgende Beispiel zeigt den Unterschied, wenn -f verwendet wird und wenn -f nicht benutzt wird:
| grep ldap-group1 Ohne -f | grep -f ldap-group1 Mit -f: |
show | grep ldap-group1
edit "ldap-group1"
set groups "ldap-group1"
|
show | grep -f ldap-group1
config user group
edit "ldap-group1"
set member "pc40-LDAP"
next
end
config firewall policy
edit 2
set srcintf "port31"
set dstintf "port32"
set srcaddr "all"
set action accept
set identity-based enable
set nat enable
config identity-based-policy
edit 1
set schedule "always"
set groups "ldap-group1"
set dstaddr "all"
set service "ALL"
next
end
next
end
|
Wie kann ich ein Fragezeichen in regulären Ausdrücken über die CLI einfügen?
Wenn man über die CLI ein Fragezeichen ? eingibt, wird standartmässig das Hilfemenu aufgerufen und angezeigt. Es kann vorkommen, dass man aber das Fragezeichen in einem regulären Ausdruck braucht.
Weil aber das Symbol des Fragezeichens für das Hilfemenu reserviert ist, wird es nicht möglich sein, das Fragezeichen in den Ausdrücken einzugeben, einzufügen oder zu kopieren.
Im folgenden Beispiel eines DLP Sensor wird das Fragezeichen ? für den regexp Syntax benötigt:
| Konfiguration über die CLI:
|
config dlp sensor
edit "default"
set comment "Default sensor."
config filter
edit 1
set proto smtp pop3 imap http-post
set filter-by regexp
set regexp "('?s:(\\d{10}.*))"
set action block
next
end
next
end
|
Lösung:
Damit man das Fragezeichen Symbol einfügen kann muss mit zBsp. einem Putty-Client gearbeitet werden.
- Putty öffnen
- Tastenkombination ctrl-V und dann ? eingeben
|
Mit der im WebGui verfügbaren CLI Console funktioniert diese Methode nicht! |
Veranschauung:
| Konfiguration über die CLI:
|
|
Ich gebe in der CLI einfach das Fragezeichen ? ein. Es wird automatisch das Hilfemenu angezeigt: # config Configure object get Get dynamic and system information show Show configuration diagnose Diagnose facility execute Execute static commands alias Execute alias commands exit Exit the CLI Ich drücke zuerst ctrl+v und sehe danach in der CLI das Fragezeichen ohne dass das Hilfemenu aufgerufen wird: # ? |
Upgrade
Wo finde ich den Upgrade-Pfad um das FortiOS auf eine neue Version anzuheben?
Seit September 2018 hat Fortinet folgendes Tool zu Verfügung gestellt welches ein korrektes Update vereinfacht:
Alternativ kann der Upgrade-Pfad auf dem Supportportal im Download Center entnommen werden (support.fortinet.com). Leider ist dieser nur bis zur Startversion 5.2.9 hinterlegt.
| FortiOS Download über das Supportportal: |
support.fortinet.com -> DOWNLOAD -> FIRMWARE IMAGES |
Wenn von einer früheren Version upgegradet werden soll, unterstützt folgender Link:
Was muss ich beachten wenn ich auf das FortiOS 6.2.2 upgraden will?
|
|
Vorsicht wenn eine FortiGate welche einen SoC3 verbaut hat und man auf die Version 6.2.2 upgraden will. Es muss beachtet werden, dass die Authentifizierung mit dem Mobile Token für das SSL-VPN nicht mehr funktioniert. |
Welche Geräte sind betroffen?
- FG-60E
- FG-60E-POE
- FG-61E
- FG-80E
- FG-80E-POE
- FG-81E
- FG-81E-POE
- FG-100E
- FG-100EF
- FG-101E
- FG-140E
- FWF-60E
- FWF-61E
Diese Information kann aus den Release Notes von OS 6.2.2 entnommen werden:
https://docs.fortinet.com/document/fortigate/6.2.2/fortios-release-notes/501077/mobile-token-authentication
Über ein Fortinet Support Ticket haben wir noch folgendes in Erfahrung bringen können:
Dieses Problem wurde im 6.2.3 gelöst.
Empfohlener Workaround:
Versuchen sie sich mit dem SSL-VPN zu verbinden. Beim Passwort-Feld das Passwort eingeben und danach ohne Leerzeichen gleich den Tokencode eingeben. (Passwort und TokenCode bilden eine Zeichenkette)
Achtung, es muss nicht sein das dies zu 100% funktioniert. Es wurde im Ticket ausdrücklich auf versuchen verwiesen für diesen Workaround.
Backup / Restore
Wie kann ich das Konfigurationsfile von der FortiGate backupen?
"Backup ist nur für Feiglinge". Dieser Spruch hört oder liest man oft, doch wenn die FortiGate ersetzt werden muss ist man froh wenn man ein aktuelles Backup der Konfiguration besitzt. Es empfiehlt sich vor und nach jeder Konfigurationsänderung ein Backup zu erstellen. So ist es jederzeit möglich, wieder auf den ursprünglichen Stand zurück zu kehren.
| Konfiguration über das WebGui:
|
Das Backup kann mittels "Backup to" auf den lokalen PC, oder falls ein USB Stick an der FortiGate eingesteckt ist auch diesen als Speicherziel wählen. Die Option Encryption ist dafür da, dass man das Backup File verschlüsselt abspeichern kann. Das Passwort, welches man definieren muss, darf nicht verloren gehen. Wenn das Passwort nicht mehr bekannt ist, gibt es keine Möglichkeit dieses Backupfile wieder in die FortiGate einzulesen. Auch über ein Support Ticket wird dies unmöglich sein. Wenn man das Backup verschlüsselt ablegt, ist es nicht mehr möglich die Konfiguration im Texteditor zu lesen oder zu bearbeiten. Es kann definiert werden, wohin das Backup File abgespeichert werden soll. Es wird eine Datei mit der Endung .conf abgelegt. Diese Datei kann im Texteditor bearbeitet werden. Somit können gewisse Änderungen direkt im Backupfile vorgenommen werden. Man kann dies dann wieder als .conf Datei abspeichern und sie in die FortiGate einlesen. |
| Konfiguration über die CLI:
|
|
Über die CLI gibt es noch weitere Orte auf welche das Backup abgespeichert werden kann. Zum Beispiel ist es möglich, das Backup auf einen FTP oder TFTP Server zu speichern. # execute backup config ? flash Backup config file to flash. ftp Backup config file to ftp server. management-station Backup config file to management station. tftp Backup config file to TFTP server. usb Backup config file to USB disk. usb-mode Backup config file for USB mode. Um ein Backup auf einen FTP Server zu speichern kann wie folgt vorgegangen werden: execute backup config ftp <File_Name> <FTP_Server_IP> [<Port>] [<Usermame>] [<Passwort>] |
Firmware
Wo finde ich die Release Notes für FortiOS 6.0?
Die aktuellen Release Notes für das FortiOS 6.0 kann der folgenden Tabelle entnommen werden:
Die aktuellen Release Notes, welche von Fortinet direkt gepflegt & geupdatet werden sind auf der Docs-Seite aufgeführt:
Wo finde ich die Release Notes für FortiOS 6.2?
Die aktuellen Release Notes für das FortiOS 6.2 kann der folgenden Tabelle entnommen werden:
| FortiOS 6.2 Release Notes |
Die aktuellen Release Notes, welche von Fortinet direkt gepflegt & geupdatet werden sind auf der https://docs.fortinet.com Seite: aufgeführt:
Wo finde ich die Release Notes für FortiOS 6.4?
Die aktuellen Release Notes für das FortiOS 6.4 kann der folgenden Tabelle entnommen werden:
| FortiOS 6.4 Release Notes |
Die aktuellen Release Notes, welche auch immer gepflegt werden, findet man auf der https://docs.fortinet.com Seite:
Unterstützt mein FortiGate Gerät eine bestimmte FortiOS Version?
In den folgenden Tabellen kann entnommen werden, ob wann ein bestimmtes FortiGate Gerät nicht mehr mit einer FortiOS GA Version funktioniert. Bevor man eine neue GA Version auf ein FortiGate Gerät installiert, sollte man in den Release Notes schauen, ob die entsprechende Version auch für dieses Gerät vorhanden ist. Alle folgenden Angaben kommen von der Fortinet Support Seite und sind ohne Gewähr.
https://support.fortinet.com/Information/ProductLifeCycle.aspx
Die unten aufgeführten Hardware-Modelle unterstützen die FortiOS-Version 5.4 nicht:
|
FortiGate Modelle die 5.4 nicht unterstützen: |
|
|
FortiGate Wifi Modelle die 5.4 nicht unterstützen: |
|
Der Zugang zum Fortinet-Kundendienst für Support zu 5.2 ist für diese Hardware-Modelle bis zum Erreichen des Hardware-End-of-Support-Datums möglich.
Die unten aufgeführten Hardware-Modelle unterstützen die FortiOS-Version 6.0 nicht:
|
FortiGate Modelle die 6.0 nicht unterstützen: |
|
|
FortiGate Wifi Modelle die 6.0 nicht unterstützen: |
|
Die unten aufgeführten Hardware-Modelle unterstützen die FortiOS-Version 6.2 nicht:
|
FortiGate Modelle die 6.2 nicht unterstützen: |
|
|
FortiGate Wifi Modelle die 6.2 nicht unterstützen: |
|
|
FortiGate Rugged Modelle die 6.2 nicht unterstützen: |
|
Die unten aufgeführten Hardware-Modelle unterstützen die FortiOS-Version 6.4 nicht:
|
FortiGate Modelle die 6.4 nicht unterstützen: |
|
|
FortiGate Wifi Modelle die 6.4 nicht unterstützen: |
|
|
FortiGate Rugged Modelle die 6.4 nicht unterstützen: |
|
Wann geht eine FortiOS Version "End of Support" - wo wird dies ausgewiesen, resp. wo kann ich dies nachschauen?
Um zu wissen ob auf der vorhandenen OS-Version der FortiGate noch Support-Anspruch besteht / noch unterstützt wird, kann dies am einfachsten auf dem Partner-Portal, welches immer geupdated wird, überprüft werden. Im Partner-Portal ist dies hier zu finden:
|
|
https://support.fortinet.com/Information/ProductLifeCycle.aspx |
So wird zum Beispiel das FortiOS 6.0 im September 2023 "End of Support" gehen.
Der Life Cycle vom FortiOS ist wie folgt definiert:
Die GA-Phase dauert 36 Monate, danach geht das FortiOS automatisch in den Status "End of Engineering Support". Nach weiteren 18 Monaten geht das FortiOS "End of Support". Sobald das FortiOS in diesem Stadium ist, gibt es seitens Fortinet keinen technischen Support. Dies bedeutet, dass Tickets erst bearbeitet werden, wenn die FortiGate auf einen aktuellen Software Stand angehoben wurde. Der ganze Life Cycle einer FortiOS Generation dauert entspechend 54 Monate.
Mehr zum TAC Support : Fortinet:Support-Case#Was_wird_vom_Technischen_Fortinet_Support_.28TAC.29_nicht_unterst.C3.BCtzt.3F
In der nachstehenden Tabelle sind die Daten welche der offiziellen Fortinet Supportseite entnommen wurden:
| Software Version | Release Date (GA) | End of Engineering Support Date (EOES) | End of Support Date (EOS) |
|---|---|---|---|
| 3.3 | 02.10.2006 | - | 02.10.2009 |
| 3.4 | 29.12.2006 | - | 29.12.2009 |
| 3.5 | 03.07.2007 | - | 07.03.2010 |
| 3.6 | 04.02.2008 | - | 04.02.2011 |
| 3.7 | 08.07.2008 | - | 18.07.2011 |
| 4.0 | 24.02.2009 | - | 24.02.2012 |
| 4.1 | 24.08.2009 | - | 24.08.2012 |
| 4.2 | 01.04.2010 | - | 01.04.2013 |
| 4.3 | 19.03.2011 | - | 19.03.2014(1) |
| 5.0 | 01.11.2012 | 01.11.2015 | 01.05.2017 |
| 5.2 | 13.06.2014 | 13.06.2017 | 13.12.2018 |
| 5.4 | 21.12.2015 | 21.12.2018 | 21.6.2020 |
| 5.6 | 2017-03-30 | 2020-03-30 | 30.9.2021 |
| 6.0 | 29.03.2018 | 29.03.2021 | 29.09.2022 |
| 6.2 | 28.03.2019 | 28.03.2022 | 28.09.2023 |
| 6.4 | 31.03.2020 | 31.03.2023 | 30.09.2024 |
(1) Das v4.0MR3 End of Support Date für Hardware, welche FortiOS Version 5.0 unterstützt, ist 2014-03-19. (Zusätzlich, und nach eigenem Ermessen, wird Fortinet den Kunden bei der Umstellung auf 5.0 in begrenztem Umfang beratend zur Seite stehen. Der beratende Support beschränkt sich auf technischen Support, Konfigurationshilfe, allgemeine Fragen und die Einreichung von Fehlerberichten.
Quelle: https://support.fortinet.com/Information/ProductLifeCycle.aspx
Wie wird eine FortiGate von Grund auf mit einem entsprechenden FortiOS installiert (staging)?
Wenn ein FortiGate Device von Fortinet ausgeliefert wird, kann dieses Device auf irgend einem FortiOS basieren! Grundsätzlich werden immer die neusten FortiOS Versionen durch Fortinet vorinstalliert. Wenn es sich um ein neu lanciertes Modell eines FortiGate Devices handelt, basiert dies oft auf einem sogenannten "Branche Release". Ein "Branche Release" ist eine Vorabversion eines "GA" Releases (General Availibility). Aus diesem Grund empfehlen wird bei jedem FortiGate Device ein "staging" mit einem FortiOS nach Wahl durchzuführen. Dabei spielt es keine Rolle welches FortiOS oder welche Konfiguration auf der FortiGate existiert oder vorhanden ist, da durch ein "staging" die FortiGate von Grundauf neu installiert wird und sämtliche Konfiguration und das bestehende FortiOS dabei verloren gehen. Somit sollte jedes FortiGate Device nach diesem Vorgehen aufgesetzt werden. Zwingende Voraussetzung für ein "staging" ist eine korrekte Verbindung von der entsprechenden Workstation zum "Consolen Port" (RS232) des FortiGate Devices. Dies bedeutet:
| Parameter für RS232 Verbindung |
8 bits no parity 1 stop bit 9600 baud (the FortiGate-300 uses 115,000 baud) Flow Control = None |
Die heutigen Laptop/Workstation verfügen in den seltensten Fällen einen "RS-232" Port. Dies bedeutet dass mit einem entsprechenden Device, zBsp "USB Konverter" gearbeitet werden muss. Wir empfehlen den "EX-1301-2" USB Konverter welcher sich durch eine hohe Kompatibilität auszeichnet. Weitere detaillierte Informationen betreffend "Konsolen Port" resp. RS-232 Console findet man im folgenden Artikel:
FortiGate-6.0:FAQ#Was_f.C3.BCr_ein_Kabel_.28Konverter.29_ben.C3.B6tige_ich_f.C3.BCr_den_Konsolen_Anschluss_.28Seriell_RS-232.29_auf_einer_FortiGate.3F
Beim "staging" Prozess überträgt das BIOS des FortiGate Devices das entsprechende FortiOS welches von einem TFTP Server auf die FortiGate um dies nachträglich zu installieren. Aus diesem Grund muss auf der entsprechende Workstation, welche mit dem FortiGate Device verbunden ist ein TFTP Server installiert werden. Wir empfehlen folgenden TFTP Server welcher kostenlos erhältlich ist:
http://www.solarwinds.com/downloads/ (Abschnitt: Free Trial Downloads > TFTP Server & SFTP/SCP Server > DOWNLOAD FREE Tool > Free TFTP Server > DOWNLOAD NOW) https://www.solarwinds.com/free-tools/free-tftp-server (Direkter Link)
Für den "Solarwinds TFTP Server" muss eine Standard-Installation durchgeführt werden. Nach der Installation steht im Startmenü "SolarWinds TFTP Server" zur Verfügung und unter dem Menu-Punkt "TFTP Server". Starte den TFTP Server anhand dieses Menu-Eintrages. Danach wähle:
File > Configure > Start
Der TFTP Server wird gestartet und dies wird auch unter der Position "Status" als "Started" angezeigt. Nun bestätige durch "OK" das "Configure" Fenster und sobald dies geschieht "initial" wird der TFTP Server gestoppt. Der Grund hierfür ist der folgender: Beim ersten Start des TFTP Servers wird das "TFTP Server Root Directory" angelegt und der Server stoppt. Standardmässig befindet sich das "TFTP Server Root Directory unter folgendem Verzeichnis "C:\TFTP-Root". Kontrolliere kurz ob dieses Verzeichnis angelegt wurde und starte den TFTP Server mehrmals und kontrolliere dessen Status:
File > Configure > Start [Kontrolliere den Status "Started"]
Nun muss in das "TFTP Server Root Direktory" das entsprechende FortiOS Image kopiert werden. Benenne dieses Image um in "image.out". Als nächsten Schritt konfiguriere die Netzwerkkarte der entsprechende Workstation welche mit dem FortiGate Device über "Consolen Port" verbunden ist mit folgender IPv4-Adresse / Subnet Maske und deaktiviere sämtlichen anderen Netzwerkkarten wie zBsp jenes für das WLAN:
192.168.1.100
255.255.255.0
NOTE Die IPv4-Adresse des TFTP Servers resp. der Netzwerkkarte der entsprechenden Workstation kann für die verschiedenen
Modelle des FortiGate Devices variieren. Beim "staging" Prozess kann diese jedoch eruiert werden!
Die Konfiguration der Netzwerkkarte benötigt keinen "Default Gateway" und auch keinen DNS Server. Achte darauf, dass auf der entsprechenden Workstation sämtliche Firewall, Endpoint Security usw. deaktiviert wurden damit die Anfrage des FortiGate Devices für die Übertragung des FortiOS Image zum TFTP Server zugelassen wird. Aus diesen Ausführung ergibt sich folgende Konstellation:
_____________________________
| RS232 Verbindung |
Consolen Port | |
___________|___ | RS-232 Anschluss
| | ____|_______________
| FortiGate 50E | 192.168.1.100/24 | |
|_______________| _____| LapTop/Workstation | --> SolarWindsTFTP Server Status "Started"
| | NIC |____________________| --> FortiOS als "image.out" im C:\TFTP-Root
WAN1 | | --> Fireweall, Endpoint Security deaktiviert!
|_____________________|
NOTE Als Verbindung von WAN1 zur Netzwerkkarte der entsprechenden Workstation benutze ein normales RJ-45 Kabel. Der entsprechende
Netzwerk-Port in unserem Beispiel ("WAN1") ist abhängig des FortiGate Devices. Der entsprechend zu nutzende Port wird während
dem "staging" Prozess aufgelistet!
Nun muss das FortiGate Device neu gestartet werden (execute restart) oder ein "power-on" ausgeführt werden. Sobald die FortiGate startet muss auf folgende Meldung geachtet werden um den Start-Prozess abzubrechen und so in dass BIOS der FortiGate zu gelangen:
| Konfiguration über die CLI:
|
Please wait for OS to boot, or press any key to display configuration menu.. FortiGate-50E (12:55-08.13.2015) Ver:05000011 Serial number: FGT50E3U15000635 CPU(00): 1600MHz Total RAM: 2GB Initializing boot device... Initializing MAC... egiga1 Please wait for OS to boot, or press any key to display configuration menu.. |
Wenn der Start-Prozess mit "press any key...." abgebrochen wurde wird folgendes Menü angzeigt:
| Konfiguration über die CLI:
|
[C]: Configure TFTP parameters. [R]: Review TFTP parameters. [T]: Initiate TFTP firmware transfer. [F]: Format boot device. [I]: System information. [B]: Boot with backup firmware and set as default. [Q]: Quit menu and continue to boot. [H]: Display this list of options. |
Nun kann für den TFTP "staging" Prozess anhand "[R]: Review TFTP parameters." die vorgegebenen Konfiguration eingesehen werden. Möchte man diese Konfiguration verändern kann dies anhand "[C]: Configure TFTP parameters." durchgeführt werden. Dabei ist zu beachten das diese Veränderung "persistens" ist und zukünftig für jeden "staging" Prozess betreffend TFTP Parameter für dieses FortiGate Device gilt:
| Konfiguration über die CLI:
|
Enter C,R,T,F,I,B,Q,or H: R Image download port: WAN1 DHCP status: Disabled Local VLAN ID: <NULL> Local IP address: 192.168.1.188 Local subnet mask: 255.255.255.0 Local gateway: 192.168.1.254 TFTP server IP address: 192.168.1.100 Firmware file name: image.out |
Führe folgende Kontrolle betreffend der Konfiguration des "staging" Prozesses durch:
- Ist das RJ-45 Kabel am korrekten Netzwerk-Port der FortiGate angeschlossen (Beispiel: WAN1)
- Wurde die korrekte IPv4-Adresse, wie auch die Subent Maske auf der Netzwerkkarte der entsprechenden Workstation konfiguriert
- Ist der TFTP Server gestartet und befindet sich im "TFTP Server Root Directory" (C:\TFTP-Root) das entsprechende Image des FortiOS als File "image.out"
Als nächsten Schritt muss der "boot device" neu formatiert werden. Dabei wird die Boot-Partition gelöscht und neu angelegt. Sämtliche vorhandenen Daten/Informainen gehen dabei verloren. Wähle die Position "[F]: Format boot device.":
| Konfiguration über die CLI:
|
Enter C,R,T,F,I,B,Q,or H: F It will erase data in boot device. Continue? [yes/no]: yes Formatting............................ Done. |
Nun, um den "staging" Prozess zu starten führe den Punkt "[T]: Initiate TFTP firmware transfer." aus:
| Konfiguration über die CLI:
|
Enter C,R,T,F,I,B,Q,or H: T |
Nun wird der "staging" Prozess durchgeführt. Achte dabei auf den "TFTP Server" resp. dessen Console in welcher der Transfer des Files bestätigt wird! Auf dem FortiGate Device wird eine korrekte Übertragung folgendermassen angezeigt:
| Konfiguration über die CLI:
|
Please connect TFTP server to Ethernet port 'WAN1'.
MAC: 90:6c:ac:13:80:10
Connect to tftp server 192.168.1.100 ...
#############################################################
Image Received.
Checking image... OK
Save as Default firmware/Backup firmware/Run image without saving:[D/B/R]? D
Wenn "D" für "default" ausgeführt wird, so wird das FortiOS in die Partition installiert und diese "active" gesetzt und somit beim nächsten Neustart des Devices verwendet. Wird "B" für "backup" gewählt, so wird die Partition nicht "active" gesetzt und beim nächsten Neustart nicht genutzt. Wenn "R" für "run" ausgeführt wird, so wird das FortiOS in den Memory Bereich installiert. Dies bedeutet dass nach einem Neustart des Devices diese Installation nicht mehr zur Verfügung da durch den ausgeführten Neustart der Memory Bereich gelöscht wird! Für ein "staging" speziell wenn der "boot device" Formatiert wird ist immer "D" zu wählen für "default".
Programming the boot device now.
....................................
.............................................................
.............................................................
...............................................................
...
Booting OS...
Reading boot image... 2800640 bytes.
Initializing firewall...
System is starting...
FGT50E3U15000635 login:
|
Das FortiOS ist nun grundsätzlich installiert. Als nächsten Schritt sollte die "disk" eines FortiGate Devices formatiert werden. Bei kleineren FortiGate Devices steht die "disk" für ein "Logging" nicht mehr zur Verfügung. Dennoch sollte die "disk" Formatiert werden da ein FortiOS für viele Funktionen diese "disk" benutzen wird, wie zBsp DHCP Lease File, Caching Informationen usw. Steht die "disk" nicht zur Verfügung, da diese nicht formatiert wurde, werden diese Informationen in den Memory-Bereich geschrieben was das Memory zusätzlich belastet oder stehen teilweise gänzlich nicht zur Verfügung. Um sich Initial nach einem "staging" auf einem FortiGate Device einzuloggen müssen folgende Login-Informationen verwendet werden:
| Konfiguration über die CLI:
|
User: admin Password: [Kein Passwort] |
Nun kann die "disk" mittels folgendem Befehl formatiert werden:
| Konfiguration über die CLI:
|
# execute formatdisk Log disk is /dev/sdb4 Formatting this storage will erase all data on it, including Logs, quarantine files; WanOpt caches; and requires the unit to reboot. Do you want to continue (y/n) y |
Nach dem Formatieren der "disk" wird ein Neustart ausgeführt! Dieser Befehl "execute formatlogdisk" kann auf neueren FortiGate Modellen, wie zBsp einer FG-50E nicht ausgeführt werden. Der Grund ist der wie folgt: Diese FortiGate Modelle verfügen zwar über eine "disk" jedoch die "disk" wird als Subsystem im Flash-Bereich angelegt (MTD; Memory Technology Device). Die "MTD" Technology ist Bestandteil des Linux Kernels resp. des FortiOS Kernels. Um festzustellen ob das FortiGate Modell über eine "MTD" Implementation verfügt kann folgender Befehl eruiert werden:
| Konfiguration über die CLI:
|
# fnsysctl df -h Filesystem Size Used Available Use% Mounted on rootfs 123.9M 53.6M 70.2M 43% / /dev/root 123.9M 53.6M 70.2M 43% / none 1.5G 1.5M 1.4G 0% /tmp none 1.5G 0 1.5G 0% /dev/shm none 1.5G 16.9M 1.4G 1% /dev/cmdb /dev/mtd5 18.0M 6.6M 11.3M 37% /data /dev/mtd7 30.0M 2.3M 27.6M 8% /data2 |
Bei den Verzeichnissen "/data" sowie "/data2" welche als "/dev/mtd*" indiziert werden und somit als "MTD" Subsysteme gelten, handelt es sich effektiv um die "disk". Diese "disk" resp. das "MTD Subsystem" wird anhand eines Files, welches in den Flash-Bereich kopiert wird angelegt. Dabei muss berücksichtigt werden, dass alle Informationen der "disk" verloren gehen. Somit FortiGate Modelle, welche anhand dieser "MTD Subsystem" Technology verfügen resp. anhand dieser eine "disk" dargestellt wird können Informationen nicht "persistent" speichern dh. nach einem Neustart gehen alle Informationen verloren! Für ein "MTD" Subsystem wird auf einer FortiGate-50E 128 MB alloziert. Als nächster Schritt im "staging" Prozess sollten die Interface's auf dem internal Switch aufgebrochen werden. Um dies durchzuführen muss zwischen folgenden Möglichkeiten unterschieden werden:
- Das FortiGate Device verfügt über einen internen Hardware "Switch Controller"!
- Das FortiGate Device verfügt über keinen internen Software "Switch Controller"!
- Auf dem FortiGate Device kann kein "Interface Mode" durchgeführt werden!
https://fortinet.also.ch/wiki/index.php?title=FortiGate-6.0:FAQ#Wie_wird_ein_virtueller_Switch_komplett_gel.C3.B6scht.3F
Durch das Aufbrechen des internen Swichtes gehen sämtliche Konfigurationen auf den Interfaces für den "internen" Switch verloren Dies beutet dass nach dem ausgeführten Neustart auf den Interfaces für den internen Switch einzeln verfügbar sind keine IP Adressen mehr konfiguriert sind. Um auf einen Zugriff über das Mgmt. Interfaces der FortiGate zu gewährleisten muss folgendes auf einem entsprechenden Interface ausgeführt werden:
Verifiziere die einzelnen Interface Namen
| Konfiguration über die CLI:
|
# show system interface |
Konfiguriere ein entsprechendes Interface
| Konfiguration über die CLI:
|
# config system interface # edit [Name des Interface zB "internal1"] # set ip [IPv4 Adresse plus Subnet Maske zB "192.168.1.99 255.255.255.0] # set allowaccess [http | https | ssh | telnet | ping] # end |
Wenn "http" sowie "https" aktiviert werden wird standardmässig ein "redirect" auf "https" durchgeführt. Möchte man dies unterbinden kann folgendes zusätzlich ausgeführt werden:
| Konfiguration über die CLI:
|
# config system global # set admin-https-redirect [enable | disable] # end |
Der "staging" Prozess ist nun abgeschlossen und due FortiGate kann in Betrieb genommen werden!
Hier kann eine Anleitung heruntergeladen werden:
Wie kann ich einen FortiOS Rollback durchführen?
Auf der FortiGate bestehen zwei Partitionen auf der Festplatte, auf welcher die Konfiguration und das FortiOS Image geschrieben wird. Es ist immer eine Partion mit dem aktuellen FortiOS und der aktuellen Konfiguration aktiv. Wenn ein Upgrade auf eine neue FortiOS Version durchgeführt wird, wird die Konfiguration auf die passive Partition geschrieben und auf dieser das neue FortiOS installiert. Nach der Installation wird dann diese Partition aktiv geschalten und die andere passiv.
Durch dieses Verhalten ist es möglich, dass wir nach einem missglückten OS-Update wieder ein Schritt zurück gehen können indem wir mit der passiven Partition die FortiGate neu starten. So initiert die FortiGate nach einem Reboot wieder mit der vorherigen OS-Version und deren Konfiguration.
Wichtig zu wissen ist, dass man immer nur ein Schritt zurück gehen kann. Daher empfiehlt es sich nach jedem Update-Schritt das Verhalten der FortiGate zu überprüft.
Als Erstes müssen wir schauen, welche Partition momentan gerade aktiv ist. Dies kann mit diagnose sys flash list überprüft werden.
Danach müssen wir definieren, mit welcher Partition wir beim nächsten Mal starten wollen (primäre oder sekondäre)
| Konfiguration über die CLI:
|
# diagnose sys flash list Partition Image TotalSize(KB) Used(KB) Use% Active 1 FGT60E-6.02-FW-build1010-191008 253920 83060 33% No 2 FGT60E-6.02-FW-build1066-191218 253920 82168 32% Yes 3 ETDB-77.00885 3021708 130964 4% No Image build at Dec 18 2019 22:30:39 for b1066
Mit dem Befehl In unserem Beispiel wollen wir den Fallback auf das FortiOS 6.2.2. Dies bedeutet, dass wir die primäre Partition auswählen müssen: # execute set-next-reboot primary Default image is changed to image# 1. Wir können dies jetzt auch mit # diagnose sys flash list
Partition Image TotalSize(KB) Used(KB) Use% Active
1 FGT60E-6.02-FW-build1010-191008 253920 82168 32% Yes
2 FGT60E-6.02-FW-build1066-191218 253920 82168 32% No
3 ETDB-77.00885 3021708 130964 4% No
Image build at Dec 18 2019 22:30:39 for b1066
Mit |
Datei:HowTo FortiOS rollback.pdf
3G/4G Modem
DNS
Wie konfiguriere ich auf einer FortiGate die System DNS Server?
Dem DNS Server auf einer FortiGate kommt eine wichtige Funktion zu. Die FortiGate nutzt die DNS Server für unzählige Funktionen und müssen entsprechend einwandfrei funktionieren. Die DNS Server-Einstellung ist eine globale Einstellung. Dies bedeutet, dass wenn mit VDOM gearbeitet wird der System DNS Server für alle gleich ist. Konfiguriert werden die System-DNS-Einstellungen im Menu DNS:
| Konfiguration über das WebGui:
|
|
Über das Menu Network > DNS |
Über die CLI werden die System DNS Server wie folgt konfiguriert:
| Konfiguration über CLI: |
# config system dns # set primary [IPv4 Adresse des DNS 1 Serves] # set secondary [IPv4 Adresse des DNS 2 Servers] # set ip6-primary :: [IPv6 Adresse des DNS1 Server] # set ip6-secondary :: [IPv6 Adresse des DNS2 Server] # set domain [Lokale Domaine] # set source-ip [Source IP die benützt werden soll für die DNS Anfrage] # end |
Über die CLI kann die Speicherdauer, wie lange der DNS-Eintrag im Cache gespeichert werden soll, konfiguriert werden. Weiter kann auch konfiguriert werden wie viele DNS Einträge im Cache maximal gespeichert werden sollen.
| Konfiguration über CLI: |
# config system dns # set dns-cache-limit [Maximum Einträge die im Cache verbleiben; Standard 5000] # set dns-cache-ttl [Maximum Zeit in der die DNS Cache vebleibt; Standard 1800] # end |
Die Anweisung "cache-notfound-response" ist ein Log relevanter Eintrag. Wird dieser aktiviert, und sind die relevanten Log's aktiviert, so wird im Log, sofern die Anfrage im "local cache" nicht gefunden wird ein "NOTFOUND" ausgegeben. Defaultmässig ist diese Option deaktiviert.
| Konfiguration über CLI: |
# config system dns # set cache-notfound-response [enable | disable] # end |
Bei FortiGate Geräten mit mehreren CPUs können die DNS-Prozessnummer von 1 bis zur Anzahl der CPUs eingestellt werden. Die Standard-DNS-Prozessnummer ist 1.
| Konfiguration über CLI: |
# config system global # set dnsproxy-worker-count <integer> # end |
Wie konfiguriere ich auf der FortiGate "DNS over TLS"?
Seit dem FortiOS 6.2 wurde diese Option DNS over TLS (DoT) hinzugefügt.
Wie funktioniert DoT?
Der noch recht junge Standard "DNS over TLS" (RFC 7858) soll drei Probleme von DNS und DNSSEC lösen:
- Schützen der Privatsphäre von Anwender und gegen abhören schützen
- Einschleusen von manipulierten DNS-Informationen unterbinden
- Verhindern von Denial-of-Service-Attacken via DNS
Die Funktion von DoT ist ziemlich einfach. Klassisch ruft der Client die DNS Informationen beim Resolver über eine ungesicherte UDP Kommunikation auf. Bei DoT wird dies über eine TCP Verbindung in der Security Schicht aufgerufen, welche authentifiziert und verschlüsselt ist. So bezieht der Client eine DNSSEC validierte Information des Namensservers. So kann ausgeschlossen werden dass Drittpersonen mitlesen. Die Namensauflösung des Resovers erfolgt dann im Klartext. Dies ist aber nicht gravierend, da der Urheber der Anfrage nicht ersichtlich ist. Es soll aber bereits Pläne geben welche die Kommunikation zwischen DNS-Resolver und dem zuständigen DNS-Server via DoT auch gesichert wird. DoT kommuniziert mit dem TCP Port 853. Ein Client der DoT fähig ist versucht die DNS-Anfrage zuerst über dieses Protokoll. Falls der Dienst nicht verfügbar ist, wird in der Regel über UDP53 die Anfrage getätigt (dies ist jedoch abhängig wie die Sicherheitseinstellungen des Systems sind). Auf der FortiGate ist es so eingestellt, dass wenn die DoT Anfrage nicht funktioniert normal über UDP53 die Anfrage unverschlüsselt abgesetzt wird. Dies ist problematisch da der Port 853 an vielen Orten (Perimeter Firewalls, Hotels oder öffentliche Hot Spots) noch blockiert wird. Des Weiteren bringt TCP, zusätzlich in Kombination mit TLS, einiges an Verwaltungs-Overhead mit sich, der die für zügiges surfen elementare Namensauflösung bremst.
Wie konfiguriere ich DoT auf der FortiGate?
Um "DNS over TLS" zu aktivieren kann im WebGUI über das Menu: Network > DNS der entsprechende Status konfiguriert werden:
- disable DNS over TLS ist deaktiviert
- enable DNS over TLS soll für DNS-Abfragen verwenden werden, sofern TLS verfügbar ist
- force Nur TLS für DNS-Abfragen verwenden. Greift nicht auf unverschlüsselte DNS-Abfragen zurück, wenn TLS nicht verfügbar ist
| Konfiguration über die CLI:
|
# config system dns # set dns-over-tls [disable|enable|force] # set ssl-certificate "Fortinet_Factory" # end |
Wie kann ich auf einer FortiGate das DNS Cache löschen?
Das DNS Cache einer FortiGate kann über CLI mit folgendem Befehl gelöscht werden:
diagnose test application dnsproxy 1
Die Option "1" steht für "Clear DNS cache". Unter "dnsproxy" stehen noch folgende weitere Optionen zu Verfügung:
| Weitere Optionen für diagnose test application dnsproxy [Option]: |
diagnsoe test application dnsproxy ? 1. Clear DNS cache 2. Show stats 3. Dump DNS setting 4. Reload FQDN 5. Requery FQDN 6. Dump FQDN 7. Dump DNS cache 8. Dump DNS DB 9. Reload DNS DB 10. Dump secure DNS policy/profile 11. Dump Botnet domain 12. Reload Secure DNS setting 13. Show Hostname cache 14. Clear Hostname cache 15. Show SDNS rating cache 16. Clear SDNS rating cache 17. DNS debug bit mask 99. Restart dnsproxy worker |
DNS Database
Wie kann ich auf einer FortiGate einen Split-DNS Server einrichten?
Ein Split-DNS Server ist ein DNS-Server der auf Anfrage einer bestimmten Source/Environement (internal und/oder external) die entsprechende Antwort liefert. Nehmen wir an wir hätten einen DMZ WebServer mit der IP Adresse 192.168.1.1 (FQDN www.mydomain.ch). Dieser FQDN ist auf dem external DNS Server (authoritativ) registriert. Wenn kein Split-DNS-Server konfiguriert ist und ein User im "internal LAN" diesen Server, im Browser versucht zu öffenen (www.mydomain.ch), so wird diese Anfrage an den DNS Server gesendet (konfigurierter Public-DNS-Server der FortiGate). Dieser Request wird vom DNS Server (sofern für www.mydomain.ch nicht authoritativ) an den Root-Server gesendet. Dies geschieht nur sofern die Anfrage nicht bereits schon im Cache des DNS-Servers vorhanden ist, welcher den autoritativen DNS-Server für www.mydomain.ch anfragen. Die Antwort, welche zurückgegeben wird ist die "public IP" (Virtual IP). Nun kann es zu Problemen kommen wenn der User sich im internen LAN befindet und vom DNS die Public IP (Virtual IP) erhält um www.mydomin.ch aufzurufen. Auch die DNS-Auflösung benötigt Zeit und verlangsamt den Zugriff zusätzlich. Um nun die zwei Welten (intern & extern) abzubilden kann ein Split-DNS-Server konfiguriert werden. Mit einer FortiGate kann dies mittels «DNS Database» umgesetzt werden. Standardmässig ist dieses Feature auf der FortiGate NICHT ERSICHTLICH und muss erst unter folgendem Abschnitt konfiguriert werden:
| Konfiguration über das WebGui:
|
|
Über das Menu :System -> Feature Visibility muss das Feature DNS Database eingeschaltet werden: |
| Konfiguration über die CLI:
|
# config system settings # set gui-dns-database enable # end |
Sobald die Funktion aktiviert ist, erscheint unter "Network" -> "DNS Servers" der entsprechende Punkt. In unserem Beispiel sind wir davon ausgegangen, dass unser DMZ Server folgende Infos betreffend DNS hat:
| Konfigurations Parameter: | ||||||
|
Nehmen wir an im internen LAN würde es ebenfalls die Domaine "mydomain.ch" geben. Ziel wäre es, dass wenn die User im "internen LAN" www.mydomain.ch im Browser eingeben der DNS Server anstelle der Public IP 212.59.153.115 die interne Adresse des WebServers im DMZ (192.168.1.1) zurückgibt, da die Anfrage vom "INTERNEN" LAN kommt und nicht von extern. Um so eine Konfiguration durchzuführen muss folgendes angepasst werden:
| Konfiguration über das WebGui:
|
| Über das Menu Network -> DNS-Servers bei "DNS Database" auf "Create New" eine neue DNS-Zone für MyDomain.ch erfassen: |
|
Der zu konfigurierende DNS Server muss als MASTER Server konfiguriert werden, jedoch NICHT als Authoritativ! |
|
Der DNS Server ist konfiguriert - nun muss für die entsprechende Zone ein "A" Record für www.mydomain.ch erfasst werden! |
|
Es ist zu empfehlen für den Host ebenfalls einen "PTR-Record" zu erstellen! |
|
Um die Einträge für einen DNS Server auf einer FortiGate aufzulisten resp. die DNS Database zu "dumpen" kann folgender Befehl verwendet werden:
|
| Konfiguration über die CLI:
|
# config system dns-database # edit MYDOMAIN.CH # set domain mydomain.ch # set type master # set view shadow # set ttl 86400 # set primary-name dns # set contact hostmaster@mydomain.ch # set authoritative disable # config dns-entry # edit 1 # set hostname www.mydomain.ch # set type A # set ip 192.168.1.1 # set status enable # end # end |
Diese Art der Konfiguration ist ein Hybrid d. h. KEIN echter Split-DNS Server, da der Authoritative DNS Server im Internet steht und nicht auf der FortiGate konfiguriert ist. Um jedoch zu gewährleisten, dass unser neu konfigurierte DNS Server NICHT authoritativ ist und das NICHT gefundene DNS Einträge extern abgefragt werden, muss die View auf shadow gesetzt werden!
| Konfiguration DNS Dienst - Externes Interface |
|
Um die Konfiguration abzuschliessen muss der externe Port (WAN) auf "Recursive" gesetzt werden, das heisst, dass der externe Port "Recursive" Anfragen absetzt:
|
| Konfiguration über die CLI: |
# config system dns-server # edit wan1 # set mode recursive # set dnsfilter-profile "[Profile_Name]" -> "default" # end |
| Konfiguration DNS Dienst - Internes Interface |
|
Damit auf dem "internen" Interface der DNS Server - den wir erstellt haben - erreichbar ist, muss folgende Konfiguration durchgeführt werden:: |
| Konfiguration über die CLI:
|
# config system dns-server # edit internal # set mode recursive # end |
Nun fehlt nur noch der letzte Schritt -> User über DHCP der entsprechende DNS Server zugeweisen:
| Konfiguration DHCP Server internal Interface: |
|
| Konfiguration über die CLI:
|
# config system dhcp server # edit 1 # set dns-service local # set default-gateway 192.168.1.99 # set netmask 255.255.255.0 # set interface "internal" # config ip-range # edit 1 # set start-ip 192.168.1.110 # set end-ip 192.168.1.210 # next # end # set timezone-option default # next # end |
Die Konfiguration ist abgeschlossen. Wenn nun ein User im "Internal" LAN ein DNS Request absetzt (DNS Server dem User zugewiesen über DHCP 192.168.1.99) schaut die FortiGate im internen DNS Server nach und, sofern ein Eintrag gefunden wird diesen ausgeliefert. Ist kein entsprechender Eintrag vorhanden wird die Anfrage über das "WAN" Interface an die externen DNS Server weitergeleitet (definierte System DNS Server).
Wie kann ich auf der Fortigate für den DNS Server und eine bestimmten Zone ein "Zonen Transfer" aktivieren?
Wenn auf einer FortiGate ein DNS Server konfiguriert wird, ob mit oder ohne Split-DNS Server, stellt sich die Frage ob die entsprechende Zone, zum Beispiel "mydomain.ch", automatisch ein Update erhält, wenn der "authoritative" DNS Server für "mydomain.ch" ein Update für einen Eintrag durchführt.
| Konfiguration über die CLI:
|
# config system dns-database # edit [Name des entsprechenden Zonen Eintrages zB. "mydomain.ch"] # set allow-transfer [Gebe die IPv4 Adresse des "authoritativen" Servers an für "mydomain.ch"] # end |
Wie auf einer FortiGate ein DNS Server eingerichtet wird kann dem folgenden Artikel entnommen werden:
FortiGate:FAQ#Wie_kann_ich_auf_einer_FortiGate_einen_Split-DNS_Server_einrichten.3F
Des Weiteren ist bei der Komunikation zwischen "authoritativen" und/oder "none-authoritativen" Servern darauf zu achten, mit welcher IP die Komunikation durchgeführt wird. Dies bedeutet, dass im Normalfall der "non-authoritative" Server (in unserem Beispiel die FortiGate) ebenfalls im "authoritativen" Server eingetragen wird. Kommuniziert die FortiGate nicht die gewünschte "Source IP Adresse" zum authoritativen Server, kann diese mit folgender Konfiguration entsprechend manuell gesetzt werden:
| Konfiguration über die CLI:
|
# config system dns-database # edit [Name des entsprechenden Zonen Eintrages zB. "mydomain.ch"] # set source-ip [IPv4 Adresse die als Source konfiguriert werden soll] # end |
Kann ich auf einer FortiGate eine bestimmte DNS Anfrage umschreiben / verändern?
Wenn in einer bestimmten Umgebung eine DNS Anfrage anderst beantwortet werden soll als in einer anderen Umgebung, so spricht man von einem Split DNS Server. Dies bedeutet, dass dieser Anfragen von bestimmten Source Adressen anders beantwortet als von anderen Source Adressen. Dies wird dann genutzt wenn "interne" Informationen und "externe" kollidieren.
Beispiel:
Wenn ein User als Mail Server "mail.mydomain.ch" konfiguriert hat, so wird dieser Mail Server ausserhalb des "Office" als "Public IP" aufgelöst, z.B. "212.59.153.125". Benutzt der User den Mail Server im "Office", und im Office existiert "kein" interner DNS Server, so wird "mail.mydomain.ch" abermals als "Public IP" aufgelöst. Der Nachteil ist, obwohl sich der User und Mail Server im gleichen Segment befinden, wird der Traffic von "mail.mydomain.ch" zur Firewall gesendet, da dieser mit der Public IP aufgelöst wird. Der Grund ist Routing bedingt, d. h. "212.59.153.125" befindet sich nicht im internen Netz, also wird der Traffic über den default Gateway des Users zur Firewall gesendet. Die richtige Lösung für dieses Problem ist ein "Split DNS" Server. Dies bedeutet, dass wenn ein interner DNS Server vorhanden ist ein "Forwarder" für "mydomain.ch" konfiguriert wird und für "mail.mydomain.ch" die IP Adresse zBsp "192.168.1.100" konfiguriert, welche die interne Adresse von "mail.mydomian.ch" darstellt. Ist kein interner DNS Server vorhanden kann die "Split DNS" Server Funktion auf einer FortiGate benutzt werden. Weitere Informationen können nachstehendem Artikel entnommen werden:
FortiGate:FAQ#Wie_kann_ich_auf_einer_FortiGate_einen_Split-DNS_Server_einrichten.3F
Kann / möchte man aus irgendwelchen Gründen KEIN "Split DNS" Server konfigurieren, so kann die Funktion "dnstranslation" angewendet werden. Diese Funktion steht im Zusammenhang mit dem "Session-Helper". Um eine "dnstranslation" zu implementieren gehe folgendermassen vor:
| Beispiel: |
|
| Schritt 1: |
|
Kontrolliere als Erstes ob für DNS (UDP) ein DNS Session-Helper existiert: # show system session-helper ................ edit 13 set name dns-udp set port 53 set protocol 17 ................ Ist der Session-Helper für DNS (UDP) nicht vorhanden, so konfiguriere diesen wie folgt: # config system session-helper # edit [Wähle einen Integer zB 20] # set name dns-udp # set port 53 # set protocol 17 # end NOTE Weitere Informationen über die Option "protocol" können folgendem Artikel entnommen werden: Allgemein:Assigned-Internet-Protocol-Numbers-RFC |
| Schritt 2: |
|
Als nächstes konfigurieren wir die "dnstranslation" gemäss unserem Beispiel: # config firewall dnstranslation # edit [Gebe einen Integer an zB "1"] # set dst [IPv4 Internal Adresse von mail.mydomain.ch "192.168.1.100"] # set netmask [Netmask für mail.mydomain.ch "255.255.255.255"] # set src [IPv4 Public Adresse von mail.mydomain.ch "212.59.153.125"] # end |
| Erklärung: |
|
Die Anfrage an den Public DNS Server, wie auch dessen Antwort werden wie folgt auf der FortiGate abgearbeitet: NOTE wie hier in diesem Beispiel gezeigt, kann die Funktion anhand "nslookup" getestet, und somit verifiziert werden ob die "dnstranslation" korrekt funktioniert! |
In diesem Sinne kann jede DNS Anfrage, welche über die FortiGate geht umgeschrieben werden. Natürlich ist diese Funktion nicht "nur" auf Public DNS Server beschränkt, sondern nur auf Port 53 DNS (UDP). Dies bedeutet, dass diese Funktion "dnstranslation" ebenfalls für temporäre Umleitungen im internen Bereich benutzt werden kann. Diese Funktion kann, oder sollte jedoch kein Split DNS Server ersetzen da die verschiedenen Einträge auf der FortiGate nicht ersichtlich sind.
DDNS
Wie kann ich DDNS debuggen?
| Konfiguration über die CLI:
|
# diagnose debug application ddnscd -1 # diagnose debug enable Um das Debug zu beenden: # diagnose debug disable # diagnose debug reset Beispiel: 1592256317: Start to update FortiGuardDDNS (sekinfw.float-zone.com) 1592256317: next wait timeout 10 seconds [111] __ssl_cert_ctx_load: Added cert /etc/cert/factory/root_Fortinet_Factory.cer, root ca Fortinet_CA, idx 0 (default) [111] __ssl_cert_ctx_load: Added cert /etc/cert/factory/root_Fortinet_Factory_Backup.cer, root ca Fortinet_CA_Backup, idx 1 [721] ssl_ctx_create_new_ex: SSL CTX is created [748] ssl_new: SSL object is created fgt_ddns_connect()-725: SSL connecting [621] __ssl_info_callback: before SSL initialization [621] __ssl_info_callback: SSLv3/TLS write client hello __ddns_ssl_connect()-651: ssl_res=1 [621] __ssl_info_callback: SSLv3/TLS write client hello [621] __ssl_info_callback: SSLv3/TLS read server hello [621] __ssl_info_callback: SSLv3/TLS read server certificate [645] __ssl_info_callback: Current cert idx 0, SSL verion 'TLS 1.2' [656] __ssl_info_callback: Got server cert chain, num 2 [664] __ssl_info_callback: Server root issuer /C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Certificate Authority/CN=support/emailAddress=support@fortinet.com [667] __ssl_info_callback: Client root issuer /C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Certificate Authority/CN=fortinet-ca2/emailAddress=support@fortinet.com [596] __ssl_switch_cert: Update with next cert, idx 1 [621] __ssl_info_callback: SSLv3/TLS read server key exchange [621] __ssl_info_callback: SSLv3/TLS read server certificate request [621] __ssl_info_callback: SSLv3/TLS read server done [621] __ssl_info_callback: SSLv3/TLS write client certificate [621] __ssl_info_callback: SSLv3/TLS write client key exchange [621] __ssl_info_callback: SSLv3/TLS write certificate verify [621] __ssl_info_callback: SSLv3/TLS write change cipher spec [621] __ssl_info_callback: SSLv3/TLS write finished __ddns_ssl_connect()-651: ssl_res=1 [621] __ssl_info_callback: SSLv3/TLS write finished [621] __ssl_info_callback: SSLv3/TLS read server session ticket [621] __ssl_info_callback: SSLv3/TLS read change cipher spec [621] __ssl_info_callback: SSLv3/TLS read finished __ddns_ssl_connect()-651: ssl_res=0 fgd_ddns_fcp_exchange()-860: Sending FCPC=Protocol=3.4|SerialNumber=FGT61FTK19000538|Firmware=FGT61F-FW-6.02-1066|Command=DDNSUpdate|DomainName=sekinfw.float-zone.com|Address=Automatic fgt_unpack_fcpr()-567: Unpacked obj: Protocol=3.4|SerialNumber=DDNS-R710-VM-01|ResponseStatus=1|Command=DDNSUpdate|DomainName=sekinfw.float-zone.com|Address=198.18.254.15 fgd_ddns_fcp_exchange()-891: Recvd FCPR=Protocol=3.4|SerialNumber=DDNS-R710-VM-01|ResponseStatus=1|Command=DDNSUpdate|DomainName=sekinfw.float-zone.com|Address=198.18.254.15 [201] __ssl_data_ctx_free: Done [1012] ssl_free: Done [193] __ssl_cert_ctx_free: Done [1022] ssl_ctx_free: Done [1003] ssl_disconnect: Shutdown fgd_ddns_extract_fcpr_rcode()-416: code=1 fgd_ddns_extract_fcpr_bound_ip()-446: Bound ip=198.18.254.15 1592256318: Succeed to update FortiGuardDDNS (sekinfw.float-zone.com ==> 198.18.254.15) |
DHCP
Wie kann ich eine Vendor DHCP Option auf einem WAN Interface konfigurieren?
]]
Wenn ich die FortiGate an eine VDSL Leitung von der Swisscom anschliesse, bekommt die FortiGate die IP Adressen automatisch per DHCP auf das WAN Interface zugewiesen. Damit dies korrekt funktioniert ist es notwendig, dass man die DHCP Client Option Vendor ID der Swisscom auf dem WAN Interface konfiguriert. Seit FortiOS 6.4.0 ist dies möglich:
| Konfiguration über die CLI:
|
# config system interface # edit "[INTERFACE]" --> Interface Name # set mode dhcp # config client-options # edit 1 # set code [integer] --> DHCP Client Optionen 0-255 default Wert ist 0 # set type [hex | string | ip | fqdn] --> DHCP Client Option Typ default Wert ist hex # set value [Wert für DHCP Client Option] --> Wert für DHCP Client Option # end # end Für das Swisscom VDSL Setup mit DHCP Client Option 60 (Vendor ID) muss der String "100008,0001,fortigate" konfiguriert werden: # config system interface # edit "wan1" # set mode dhcp # config client-options # edit 1 # set code 60 # set type string # set value "100008,0001,fortigate" # end # end |
Vielen Dank an Daniel von IQantum GmbH
ARP
Wie kann ich im FortiOS einer FortiGate "ARP"-Einträge auflisten, hinzufügen oder löschen?
Um eine Liste der ARP-Einträge auf der FortiGate zu erhalten nutzt man den get system arp Befehl auf der CLI:
| Konfiguration über die CLI:
|
# get system arp Address Age(min) Hardware Addr Interface 10.60.60.10 0 48:8d:36:61:84:28 internal 10.60.60.100 0 1c:1b:0d:6a:27:80 internal 10.60.60.11 0 00:19:fd:4c:97:9b internal 10.60.100.10 0 70:4c:a5:89:01:48 dmz 10.60.60.101 0 1c:1b:0d:68:ff:94 internal 10.60.61.100 1 38:ca:da:b5:a1:db luz0002-prod 10.60.61.103 0 64:5d:86:fd:97:79 luz0002-prod 192.168.50.2 0 7c:b7:33:3b:a1:18 wan1 |
Die Position "Age(min)" im hier gezeigtem "output" zeigt die Zeit in Minuten welche verstrichen ist seit kein Traffic mehr für den entsprechenden "ARP" Eintrag stattgefunden hat. Wenn für einen entsprechenden "ARP" Eintrag kein Traffic stattgefunden hat während einer vordefinierte Zeit, so wir dieser "ARP" Eintrag auf "age out" gesetzt.
Eine weitere Möglichkeit "ARP" Einträge mit entsprechenden Details aufzulisten ist folgender Befehl: diagnose ip arp list
| Konfiguration über die CLI:
|
# diagnose ip arp list index=22 ifname=internal 10.60.60.10 48:8d:36:61:84:28 state=00000002 use=27 confirm=740 update=740 ref=3 index=22 ifname=internal 10.60.60.100 1c:1b:0d:6a:27:80 state=00000002 use=373 confirm=2004 update=2004 ref=8 index=22 ifname=internal 10.60.60.11 00:19:fd:4c:97:9b state=00000008 use=1 confirm=2847 update=204 ref=4 index=7 ifname=dmz 10.60.100.10 70:4c:a5:89:01:48 state=00000002 use=2 confirm=671 update=671 ref=2 index=22 ifname=internal 10.60.60.101 1c:1b:0d:68:ff:94 state=00000002 use=457 confirm=87 update=87 ref=7 index=20 ifname=luz0002-prod 10.60.61.100 38:ca:da:b5:a1:db state=00000004 use=39878 confirm=39878 update=618 ref=1 index=20 ifname=luz0002-prod 10.60.61.103 64:5d:86:fd:97:79 state=00000002 use=2 confirm=2607 update=2607 ref=2 index=5 ifname=wan1 192.168.50.2 7c:b7:33:3b:a1:18 state=00000002 use=4 confirm=119 update=1416 ref=48 |
Wenn sehr viele "ARP" Einträge auf verschiedenen Interface's exisiteren, und man einen spezifischen Eintrag sucht sollte im Zusammenhang mit dem "diagnose" Kommando "grep" benutzt werden:
| Konfiguration über die CLI:
|
# diagnose ip arp list | grep 10.60.60.100 index=22 ifname=internal 10.60.60.100 1c:1b:0d:6a:27:80 state=00000004 use=2968 confirm=6101 update=594 ref=9 |
Weitere Informationen dazu wie "grep" benutzt wird siehe nachfolgenden Artikel:
FortiGate:FAQ#Kann_ich_in_der_CLI_meinen_Output_nach_bestimmten_W.C3.B6rter_filtern.3F
Anhand dieses Kommando "diagnose" lässt sich ein "ARP" Eintrag "temporär" hinzufügen oder löschen. Das hinzufügen eines "ARP" Eintrages anhand des "diagnose" Kommandos ist nicht "persistent". Dies bedeutet wenn ein Neustart der FortiGate ausgeführt wird geht diese Konfiguration verloren:
| Konfiguration über die CLI:
|
|
Füge einen "ARP" Eintrag "temporär" hinzu # diagnose ip arp add [Interface Name zBsp "internal"] [IPv4 Adresse für den ARP Eintrag] [MAC Adresse für den ARP Eintrag XX:XX:XX:XX:XX:XX] Lösche einen "ARP" Eintrag # diagnose ip arp delete [Interface Name zB "internal"] [IPv4 Adresse für den ARP Eintrag] |
Möchte man einen permanenten "ARP" Eintrag konfigurieren, welcher auch nach einem Neustart der FortiGate aktiv bleibt, muss diese Konfiguration anhand der "arp-table" durchgeführt werden. Dies wird wie folgt konfiguriert:
| Konfiguration über die CLI:
|
# config system arp-table # edit [Gebe einen entsprechenden Integer an zBsp "1"] # set interface [Name des Interfaces zBsp "wan1"] # set ip [IPv4 Adresse für den ARP Eintrag] # set mac [MAC Adresse für den ARP Eintrag zBsp für "wan1"] # end |
Um die entsprechende MAC Adresse eines Interfaces zu eruieren, können folgende Behehle ausgeführt werden:
| Konfiguration über CLI: |
# diagnose hardware deviceinfo nic
The following NICs are available:
dmz
internal1
internal2
internal3
internal4
internal5
internal6
internal7
wan1
wan2
# diagnose hardware deviceinfo nic wan1
Driver Name :Fortinet NP4Lite Driver
Version :1.0.0
Admin :up
Current_HWaddr 08:5b:0e:47:db:58
Permanent_HWaddr 08:5b:0e:47:db:58
Status :up
Speed :100
Duplex :Half
Host Rx Pkts :11371
Host Rx Bytes :835610
Host Tx Pkts :16174
Host Tx Bytes :2043274
Rx Pkts :11370
Rx Bytes :994717
Tx Pkts :16168
Tx Bytes :1883038
rx_buffer_len :2048
Hidden :No
cmd_in_list : 0
promiscuous : 1
enabled 802.1x : 0
authorized : 0
mac bypass : 0
|
Wenn die "ARP" Informationen auf den neusten Stand gebracht werden sollen so muss ein "flush" ausgeführt werden. Dies bedeutet: Alle "dynamischen" ARP Einträge werden gelöscht und neu durch "who-as" gelernt. Somit wird gewährleistet, dass nicht mehr verbundene Devices aus der "ARP" Tabelle gelöscht werden. Um ein "flush" durchzuführen gebe auf der CLI folgendes ein:
| Konfiguration über die CLI:
|
# execute clear system arp table |
Wenn dies durchgeführt wird kann über das "sniffer" Kommando das "neu lernen" der "ARP" Einträge mitverfolgt werden:
| Konfiguration über die CLI:
|
# diagnose sniffer packet any arp interfaces=[any] filters=[arp] 0.682098 arp who-has 198.18.3.3 tell 198.18.3.1 0.682251 arp reply 198.18.3.3 is-at 8:5b:e:5d:f7:c |
Was ist der Unterschied zwischen den Funktionen "system arp-table" und "proxy-arp?
Wenn im FortiOS auf dem externen Interface, zBsp "wan1" ein public IP Range konfiguriert wird, sei es über statische und/oder dynamischer Konfiguration, und zu diesem konfigurierten public IP Range eine neuer public IP Range dazu konfiguriert werden soll, hat man verschiedenen Möglichkeiten dies vorzunehmen. Eine Möglichkeit ist, den neuen public IP Range auf dem externen Interface als "Secondary Interface" zu konfigurieren. Dadurch wird der neue public IP Range auf dem Secondary Interface zur MAC Adresse des Interface hinzugefügt auf dem die "Secondary Interface" Konfiguration durchgeführt wird. Eine andere Möglichkeit ist ein VIP Objekt zu erstellen. Durch die Erstellung eines VIP Objekts wird durch die Option "arp-reply enable" auf Layer 4 ein entsprechender ARP Eintrag anhand der MAC Adresse durchgeführt, das Interface das im VIP Objekt konfiguriert wird. Da dieser ARP Eintrag auf Layer 4 durch "arp-reply enable" konfiguriert wird, ist dieser ARP Eintrag auf Layer 3 anhand des Kommandos "get system arp" nicht ersichtlich. Wiederum eine andere Möglichkeit ist ein statischer ARP Eintrag mittels "system arp-table" zu erstellen. Alle diese Möglichkeiten haben das Ziel anhand der MAC Adressen den zusätzlichen public IP Range auf das entsprechende Interface zu binden. Wenn jedoch der neue public IP Range nicht auf dem externen Interface verwendet wird, sondern zBsp lediglich auf dem "dmz" Interface für eine Public IP Adressierung der Server, muss dem externen Interface mitgeteilt werden, dass dieses "dmz" Interface für diesen neuen IP Range zuständig ist. Dies da dieser public IP Range auf das externe Interface, zBsp "wan1" geroutet wird. Wird dies mit einem statischen ARP Eintrag in der "system arp-table" auf dem externen Interface durchgeführt, wird der Traffic nicht auf das "dmz" Interface weitergeleitet da das FortiOS davon ausgeht, dass sich der neue public IP Range auf dem externen Interface, zBsp "wan1" befindet. In so einem Fall wird ein "system proxy-arp" erstellt dh., es wird dem FortiOS durch einen "system proxy-arp" Konfiguration mitgeteilt, dass die Zuständigkeit einer oder mehrer public IP/s sich nicht mehr auf dem externe Interface befindet, wie zBsp "wan1" sondern auf dem "dmz" Interface. Dies bedeutet: Das FortiOS nimmt den/die neue/n public IP Range/s auf dem externen Interface an und leitet diesen an das Interface gemäss der Konfiguration "system proxy-arp" weiter. Diese Art der Implementierung wird auch "IP Adresse zu MAC Adress Translation" genannt! Um einen "system proxy-arp" zu konfigurieren muss über CLI folgendes durchgeführt werden:
| Konfiguration über CLI: |
# config system proxy-arp # set interface [Namen des Externes Interface zB "wan1"] # set ip [Public IPv4 Adresse des Servers im DMZ] # set end-ip [Public IPv4 End Adresse des Servers im DMZ] # end |
Im FortiOS kann anhand der Option "end-ip" die End Adresse des Public IP Ranges definiert werden. Diese steht im Zusammenhang mit der Option "ip" dh., es wird nur die Iption "ip" benutzt und so gilt nur diese Konfiguration einer IPv4 Adresse. Wird "end-ip" definiert gilt die Option "ip" als Start Adresse des IPv4 Adress Definition.
Routing
Wie funktioniert das Routing auf einer FortiGate?
Beim Routing entscheidet die FortiGate, welche im NAT-Modus betrieben wird, wohin die Pakete gesendet werden sollen, die empfangen oder durch die FortiGate selber erzeugt werden.
Alle Netzwerkgeräte, die ein Routing durchführen, besitzen eine Routingtabelle. Eine Routingtabelle enthält eine Reihe von Regeln. Jede Regel gibt den nächsten Hop an, der das endgültige Ziel des Pakets sein kann, oder auch an einen nächsten Hop geht. Jeder Routing-Hop im gerouteten Pfad erfordert eine Routingtabellensuche (Routing Lookup), um das Paket weiterzuleiten, bis dies das endgültige Ziel erreichen kann.
Beim Routing von Paketen findet die FortiGate zunächst eine passende Route in ihrer Routing-Liste, basierend auf der Zieladresse des Pakets. Bei dieser Übereinstimmung wertet die FortiGate die gesamte Routingtabelle aus, um die spezifischste Übereinstimmung zu finden, bevor eine Route ausgewählt wird. Wenn die FortiGate mehrere Übereinstimmungen findet, verwendet sie verschiedene Routenattribute, um die beste Route zu ermitteln.
Die richtige Routing-Konfiguration ist wichtig. Wenn Routen falsch konfiguriert sind, erreichen die Pakete ihr Ziel nicht und gehen verloren.
Standardmässig sind viele Aspekte auf FortiGate "stateful". So entscheidet die FortiGate viele Dinge zu Beginn einer Session, also dann, wenn sie das erste Paket erhält.
Für jede Session führt die FortiGate zwei Routing-Lookups durch:
- Für das erste vom Absender gesendete Paket
- Für das erste Antwortpaket, das vom Responder kommt
Nach diesen beiden Lookups schreibt die FortiGate die Routinginformationen in ihre Session-Tabelle. Alle folgenden Pakete werden gemäss Session-Tabelle, und nicht nach der Routingtabelle weitergeleitet. So werden alle Pakete, welche zur gleichen Session gehören dem gleichen Pfad zugewiesen, auch nach einer Änderung der statischen Routen. Es gibt jedoch eine Ausnahme dieser Regel. Wenn es eine Änderung in der Routingtabelle gibt, entfernt die FortiGate die Routeninformationen für die Session Tabelle, und dann führt sie eine zusätzliche Routingtabellen des Lookups durch, um diese Informationen wiederherzustellen.
Eine Methode der manuell konfigurierten Routen ist die statische Route. Wenn man eine statische Route konfiguriert, wird der FortiGate mitgeteilt: "Wenn du ein Paket siehst, dessen Ziel innerhalb eines bestimmten Bereichs liegt, sende dies über ein bestimmtes Netzwerkinterface an einen bestimmten Router". Man kann auch die Distanz und die Priorität so konfigurieren, dass die FortiGate die beste Route zu jedem Ziel ermitteln kann, welche mehreren Routen entspricht.
In einfachen Heimnetzwerken ruft beispielsweise DHCP automatisch eine statische Route ab und konfiguriert diese selbstständig. Das Modem des ISPs sendet dann den gesamten ausgehenden Datenverkehr über dessen Internet-Router, welcher die Pakete an ihr Ziel weiterleitet. Dies wird typischerweise als Standard-Route bezeichnet, da der gesamte Traffic, der nicht mit anderen Routen übereinstimmt, standardmässig über diese Route geleitet wird. Hier ein Beispiel einer Standardroute:
Das Ziel-Subnetzwert von 0.0.0.0.0.0/0.0.0.0.0 passt zu allen Adressen innerhalb eines Subnetzes. Da die meisten FortiGates als Perimeter-Gerät des Netzwerkes fungieren, verfügen über mindestens eine dieser Standardrouten. Damit wird sichergestellt, dass der Internettraffic an den ISP weitergeleitet wird.
Subnetze welche auf der FortiGate über eine direkt Layer 2 Konnektivität verfügen benötigen keine statische Route.
Jede Route in einer Routingtabelle hat folgende Attribute:
- Network
- Gateway IP
- Interfaces
- Distance
- Metric
- Priority
Distanz:
Die Distanz, resp. die administrative Distanz ist eine Zahl, die von Routern verwendet wird, um zu bestimmen, welche Route für ein bestimmtes Ziel bevorzugt wird. Wenn es zwei Routen zum gleichen Ziel gibt, wird jene mit der geringeren Distanz als besser angesehen und für die Routenführung verwendet. Die Routen mit grösseren Entfernungen sind inaktiv und werden nicht in die Routingtabelle aufgenommen.
Standardmässig haben Routen, die über das RIP-Protokoll gelernt wurden, einen höheren Distanzwert als Routen, die über das OSPF-Protokoll gelernt wurden. Dabei gilt das OSPF-Protokoll als genauer als das RIP.
Die folgenden Werte sind die Distanzen auf einer FortiGate:
0 - direkt angeschlossen
5 - DHCP-Gateway
20 - externe BGP (EBGP) Routen
200 - interne BGP (IBGP) Routen
110 - OSPF-Routen
120 - RIP-Routen
10 - statische Routen
Metric:
Das Metric Attribut wird verwendet, um die beste Route zu einem Ziel zu bestimmen, wenn es um Routen geht, welche durch ein dynamisches Routing-Protokoll gelernt wurden. Wenn zwei Routen den gleichen Abstand haben, wird der metrische Wert verwendet um das Band zu brechen. Für das Routing wird die Route mit der niedrigsten Metric gewählt.
Wie der Metric-Wert gemessen wird, hängt vom Routing-Protokoll ab. Zum Beispiel verwendet RIP die Hop Count, d.h. die Anzahl der Router, die das Paket durchlaufen muss, um das Ziel zu erreichen. OSPF verwendet Kosten, die sich danach richten, wie viel Bandbreite eine Verbindung zu Verfügung hat.
Priorität:
Wenn mehrere statische Routen den gleichen Distanzwert haben, sind beide in der Routingtabelle aktiv. Welche Route wird also verwendet, um passende Pakete zu routen? In diesem Szenario verwendet die FortiGate den Prioritätswert als Tiebreaker, um die beste Route zu ermitteln. Routen mit geringerer Priorität werden stets bevorzugt.
Das Prioritätsattribut gilt nur für statische Routen und wird unter den erweiterten Optionen auf der Benutzeroberfläche konfiguriert. Standardmässig haben alle statischen Routen eine Priorität von 0.
Was bedeutet der Begriff "ECMP" beim Routing?
Im Normallfall wird die Beste Route anhand von Routenattributen ermittelt, welche durch das Routing zu Verfügung gestellt werden. (Metric, Distanz, Priorität ..) Was passiert also, wenn zwei oder mehrere Routen zur gleichen Destination die gleichen Werte für alle Attribute besitzen? Wenn mehrere Routen zum gleichen Ziel die gleiche Distanz, Metric und Priorität haben, gelten sie alle als der beste Kandidat. Wenn die Routen statisch, OSPF oder BGP sind, gleicht die FortiGate die Last des Traffics über alle Routen aus. Dies wird als Equal Cost Multi-Path (ECMP) bezeichnet.
ECMP kann den Ausgleichstraffic mit einer dieser vier Methoden behandeln:
- Source IP (default)
- Source-Destination IP
- Weighted
- Usage (spillover)
|
Source IP Based: |
|
Session können je nach Source IP Adresse, Source und Destination IP Adressen Routen oder Gewichtung des Interfaces, oder Interface Sitzungen können je nach Quell-IP-Adresse, Quell- und Ziel-IP-Adresse, Routen- oder Interfacegewicht oder Interfacevolumenschwellwert auf gleiche Routen verteilt werden. |
|
Source-Destination IP Based: |
|
Die Source-Destination-IP-Methode funktioniert ähnlich, berücksichtigt aber auch die Destination IP. Es wird also erwartet, dass die Session von einer bestimmten Source zu einer bestimmten Destination den gleichen Pfad verwenden. |
|
Weight Based: (Gewichtung) |
|
Wenn die ECMP Methode auf weighted konfiguriert ist, verteilt die FortiGate die Sessions mit verschiedenen Destination IPs, indem sie einen Zufallswert erzeugt um die zu wählende Route zu bestimmen. Die Wahrscheinlichkeit eine Route über eine andere auszuwählen basiert auf dem Weight Wert jeder Route oder Interface. Es ist wahrscheinlicher, dass höhere Weights gewählt werden. |
|
Spillover (Usage Based) |
|
Es gibt eine zusätzliche Methode namens usage-based (oder spillover). Beim nutzungsabhängigen Lastausgleich verwendet die FortiGate eine primäre Route, bis ein Schwellenwert des Verkehrsaufkommens erreicht ist; danach verwendet es die nächste verfügbare Route. |
|
|
Wenn eine der ECMP-Routen ausfällt, und aus der Routingtabelle entfernt wird, wird der Traffic über die restlichen Routen geleitet. |
Die FortiGate verwendet source-ip-based als Standard-ECMP-Methode. In der CLI kann die gewünschte Methode konfiguriert werden:
|
Source IP Based: |
# config system settings # set v4-ecmp-mode source-ip-based # end |
|
Source-Destination IP Based: |
# config system settings # set v4-ecmp-mode source-dest-ip-based # end |
|
Weight Based: (Gewichtung) |
# config system settings # set v4-ecmp-mode weight-based # end Auf den Interfaces muss die Gewichtung konfiguriert werden: # config system interface # edit [INTERFACE_NAME] # set weight [Wert definieren zwischen 0 und 255] # end Gewichtung muss pro Route definiert werden: # config router static # edit [ROUTEN-ID] # set weight [Wert definieren zwischen 0 und 255] # end |
|
Spillover (Usage Based) |
# config system settings # set v4-ecmp-mode usage-based # end Für Spillover-ECMP müssen die Spillover-Schwellenwerte per Interface konfiguriert werden: # config system interface # edit [INTERFACE_NAME] # set spillover-threshold [Wert zwischen 0 und 16776000 definieren] |
BEISPIEL:
In diesem Szenario hat die FortiGate zwei gleichwertige Kandidatenrouten für das Subnetz 192.168.4.0/24 mit Port1 bzw. Port2. Unter Verwendung der standardmässig Sourcebasierten ECMP-Methode kann die FortiGate einen der beiden Wege nutzen, um Datentraffic für das Subnetz 192.168.4.0/24 von Benutzer A und Benutzer B zu liefern. Wenn Port1 die Verbindung verliert, verwendet die FortiGate automatisch Port2, um den gesamten Datentraffic für das Subnetz 192.168.4.0/24 zu liefern.
ECMP ermöglicht es uns, mehrere Links für dasselbe Ziel zu verwalten und ein integriertes Failover bereitzustellen. Dies kann für alle Netzwerkressourcen bereitgestellt werden welche eine hohe Bandbreitenanforderungen haben und unternehmenskritisch sind. Die Verwendung von ECMP für diese Ressourcen ermöglicht es uns, die verfügbare Bandbreite mehrerer Links zu aggregieren und den Lastausgleichstraffic über diese Links zu verteilen.
Wenn wir ECMP verwenden, müssen wir über die richtigen Firewallregeln verfügen, damit der Datentraffic alle am ECMP beteiligten Interfaces verlassen kann. Während wir ECMP verwenden können, um mehrere Internet-(WAN)-Verbindungen auf der FortiGate zu verwalten, kann es effizienter sein, die softwaredefinierte WAN-Funktion (SD-WAN) zu verwenden, um dies zu erreichen. Wir können ECMP weiterhin für interne Ressourcen verwenden.
# get router info routing-table all
S 192.168.4.0/24 [10/0] via 192.168.1.254, port1, [5/0]
192.168.4.0/24 [10/0] via 192.168.2.254, port1, [5/0]
C 192.168.1.0/24 is directly connected, port1
C 192.168.2.0/24 is directly connected, port2
C 192.168.3.0/24 is directly connected, port3
Wie funktioniert das "Reverse Path Forwarding" auf der FortiGate (Antispoofing)?
Pakete werden manchmal aus Routing- oder/und Sicherheitsgründen gelöscht. Reverse Path Forwarding (RPF) ist ein Mechanismus der FortiGate welcher das Netzwerk vor IP-Spoofing-Angriffen schützt. Dabei wird überprüft, ob es eine Route zurück zur Destination des Paketes gibt. Diese Prüfung wird auf dem ersten Paket einer neuen Session durchgeführt. Ebenso wird diese Prüfung nach einer Routenänderung auf dem nächsten Paket in der ursprünglichen Richtung ausgeführt.
Es gibt zwei RPF-Methoden:
- Loose
- Strict
Veranschauungsbeispiel:
| Beschreibung |
|
In diesem Szenario wird der eingehende Internetverkehr, welcher bei wan1 ankommt akzeptiert, da die Standardroute eine gültige Route zurück zur Source ist. Es gibt jedoch zwei Interfaces welche eingehenden Datentraffic nicht weiterleiten: port1 und wan2. Port1 wird den Datentraffic nicht weiterleiten, da das Subnetz für Benutzer C 192.168.4.0/24 ist. Es gibt keine aktive Route für dieses Subnetz via Port1. So wird der Datentraffic von 192.168.4.0.0/24 zu Port1 eingestellt, weil dieser bei der RPF-Prüfung fehlgeschlagen ist. Das andere Interface, welches den Datentraffic nicht weiterleitet, ist wan2. Während wan2 physisch mit dem Internet verbunden ist, sind die einzigen IP-Adressen, welche als Sourcen oder Destinationen für wan2 gelten jene im Subnetz 198.18.2.0/24. So wird der eingehende Datentraffic einer anderen Source nicht durch die RPF-Prüfung geleitet und umgehend gelöscht. # get router info routing-table all S* 0.0.0.0/0 [10/0] via 198.18.1.254, wan1 C 198.18.1.0/24 is directly connected, wan1 C 198.18.2.0/24 is directly connected, wan2 C 192.168.3.0/24 is directly connected, port1 |
| Diagramm |
|
|
So fixen wir das Problem:
| Beschreibung |
|
Das erste Problem wird behoben indem eine statische Route zu 10.0.4.0.0/24 über Port1 hinzugefügt wird. Wenn die FortiGate nun die RPF-Prüfung für die Pakete von Benutzer C ausführt, findet diese eine aktive Route zu diesem Subnetz über Port1 und das Paket wird akzeptiert. Das zweite Problem wird ebenfalls gelöst indem eine statische Route hinzugefügt wird. In diesem Fall ist es eine Standardroute für wan2. Diese zweite Standardroute muss die gleiche Distanz aufweisen wie jende für wan1. Damit wird sichergestellt, dass beide Routen in der Routingtabelle aktiv sind. Beide können unterschiedliche Prioritäten haben, aber sie müssen die gleiche A haben, um aktiv zu sein. In diesem Beispiel wurden zwei Routen mit gleicher Distanz, aber unterschiedlicher Priorität konfiguriert. Eine Route ist also die bessere (jene mit der niedrigsten Priorität), aber beide sind aktiv. Die beste Route wird für den ausgehenden Traffic verwendet, aber beide können eingehende Traffic empfangen, ohne die RPF-Prüfung zu durchlaufen. # get router info routing-table all
S* 0.0.0.0/0 [10/0] via 198.18.1.254, wan1
[10/0] via 198.18.2.254, wan2, [5/0]
S 192.168.4.0/24 [10/0] via 10.0.3.254, port1
C 198.18.1.0/24 is directly connected, wan1
C 198.18.2.0/24 is directly connected, wan2
C 192.168.3.0/24 is directly connected, port1
|
| Diagramm |
|
|
Das RPF kann entweder stricte oder loose durchgesetzt werden.
Im loose Modus wird das Paket akzeptiert solange ein aktiver Weg zur Source-IP über das eingehende Interface besteht. Es muss nicht die beste, sondern lediglich eine aktive Route sein.
Im Strict Modus überprüft die FortiGate ob der beste Weg zur Source-IP-Adresse über das eingehende Interface führt. Die Route muss entgegen dem "loose Modus" nicht nur aktiv sein, sondern auch die beste.
Die RPF-Prüfung kann auf zwei Arten deaktiviert werden. Wenn man das asymmetrische Routing aktiviert, wird die RPF-Prüfung systemweit deaktiviert. Dies reduziert jedoch die Sicherheit des gesamten Netzwerks erheblich. Funktionen wie Antivirus und IPS werden wirkungslos. Wenn man also die RPF-Prüfung deaktivieren muss, kann man dies auf der Interface-Ebene mit folgenden Befehlen vornehmen:
| Loose RPF |
|
Defaultmässig ist die FortiGate im Loose Mode # config system interface # edit [INTERFACE_NAME] # set src-check disable # end Global in den System Settings: # config system setting # set strict-src-check disable # end |
| Strict RPF |
|
Per Interfaces: # config system interface # edit [INTERFACE_NAME] # set src-check enable # end Global in den System Settings: # config system setting # set strict-src-check enable # end |
| Beispiel 1 | ||
|
In diesem Beispiel sendet der Host 10.0.4.1 ein SYN-Paket an 10.0.1.2, spooft aber eine Quell-IP von 10.0.1.1. Dadurch scheint das Paket aus dem internen Netzwerk hinter Port1 initiiert zu werden. Lose RPF erlaubt diesen Traffic, da die aktive Route auf wan1 eine Standardroute (0.0.0.0.0.0/0) ist. Anschlissßend würde 10.0.1.2 (Benutzer B) das SYN/ACK-Paket an das reale Gerät mit der IP-Adresse 10.0.1.1.1 (Benutzer A) senden. Da 10.0.1.1.1 (Benutzer A) keine SYN/ACK-Pakete erwartet (weil dieser zuvor kein SYN-Paket an 10.0.1.2 gesendet hat), antwortet er mit einem RST-Paket (Reset). | ||
| Beispiel 2 | ||
|
In diesem Beispiel sendet der Host 10.0.4.1 ein SYN-Paket an 10.0.1.2, spooft aber eine Source-IP von 10.0.1.1. Dadurch scheint das Paket aus dem internen Netzwerk hinter Port1 initiiert zu werden. Loose RPF erlaubt diesen Traffic, da die aktive Route auf wan1 eine Standardroute (0.0.0.0.0.0/0) ist. Was passiert aber im gleichen Szenario, wenn Strict RPF verwendet wird?
Obwohl das stricte RPF sicherer ist, kann dies bei Verwendung des dynamischen Routings zu Fehlalarmen führen. Dynamische Routen können sich schnell ändern, und sie können die FortiGate veranlassen, legitimierte Pakete jedes Mal zu verwerfen sobald sich die bevorzugte Route ändert. Im Allgemeinen wird empfohlen loose RPF in Kombination mit Firewallregeln zu verwenden. So kann gefälschter Datenverkehr blockiert werden anstelle strict RPF zu diesem Zweckzu verwenden. |
Wie wird auf einer FortiGate das Routing abgearbeitet?
Dieser Artikel beschreibt wie die FortiGate das Routing abarbeitet und selektiert was heisst, welches Routing zuerst greift (wie zum Beispiel Cache, Policy Routen usw.). Wenn verschiedene Routings verwendet werden zum Beispiel Policy Route (Layer 4), Distanz (Layer 3) ist es wichtig zu wissen, wie diese Routings abgearbeitet werden. In der folgenden Liste kann entnommen werden, wie die FortiGate das Routing generell abarbeitet (Abarbeitung von oben nach unten)
- 0) Routing Cache
- 1) Policy Route
- 2) Longest Match
- 3) Distance
- 4) Priority
- 5) Metric (Dynamisches Routing)
- 6) ECMP (Equal Cost Multiple Path)
|
|
Ein FortiOS resp. eine FortiGate im "Transparent Mode" aggiert wie eine Bridge und leitet den Traffic im Layer-2 weiter. Dies bedeutet dass Ethernet-Packetebasierend deren "MAC Adressen" abgearbeitet werden und "nicht" anhand deren IP's. |
Wie der "cache" eines Routing eingesehen und auf den neusten Stand gebracht werden kann kann nachfolgendem Artikel entnommen werden: Routing Cache anzeigen
Nachfolgendes Diagramm zeigt wie ein "lookup" in Zusammenhang mit den verschiedenen "Routing Tabellen" durchgeführt wird:
| Routing Flow Diagramm:
|
|
Dieses Diagramm zeigt auf dass verschiede "Routing Tabellen" existieren welche für die verschieden eingesetzten Routing Technologien wie Policy Route, Cache, Statische Route usw. entscheidend sind. Die Informationen dieser "Routing Tabellen" spielen somit eine entscheidende Rolle ob ein Routing selektiert wird oder nicht! Diagramm: |
Wie kann ich auf einer FortiGate die Routing-Tabelle ansehen?
Wenn ich ab dem FortiOS 5.4 die Routing-Tabelle auf einer FortiGate ansehen möchte, so muss folgendes beachtet werden. Es besteht die Möglichkeit die aktiven Routen in der Routing-Tabelle anzuschauen (nur Routen die momentan aktiv sind). Es gibt auch ein Befehl, mit welchem ich alle Routen sehen kann, welche in der Routing-Tabelle eingetragen sind (aktive, und auch inaktive Routen).
Über das WebGui kann ich nur die aktive Routing-Tabelle anschauen:
| Konfiguration über das WebGui:
|
|
Routing-Tabelle im WebGui für FortiOS Versionen 5.6/6.0/6.2: Über das WebGui kann ich nur die aktive Routing-Tabelle anschauen: Gehe auf Monitor -> Routing Monitor Routing-Tabelle im WebGui ab FortiOS Version 6.4: Menu Dashboard -> Network und dann beim Widget Static & Dynamic Routing auf die Grafik klicken Nun sieht man die Routing-Tabelle im Diagramm und in aufgelisteter Form. |
In der CLI ist die FortiOS Version nicht relevant, da ist der Syntax bei allen gleich:
| Konfiguration über die CLI:
|
|
Um auf der CLI nur die "aktiven" Routing-Einträge aufzulisten kann folgender Befehl ausgeführt werden: # get router info routing-table all
Routing table for VRF=0
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default
S* 0.0.0.0/0 [10/0] via 217.193.240.161, vdom-wan1
S 172.16.10.0/24 [10/0] via 198.18.0.138, sg0e0-hp0
S 172.16.20.0/24 [10/0] via 198.18.0.138, sg0e0-hp0
S 172.16.30.0/24 [10/0] via 198.18.0.138, sg0e0-hp0
S 172.16.40.0/24 [10/0] via 198.18.0.138, sg0e0-hp0
S 172.16.99.0/24 [10/0] via 198.18.0.138, sg0e0-hp0
C 198.18.0.0/27 is directly connected, port1
S 198.18.0.40/29 [10/0] via 198.18.0.142, sg0e0-dmz0
S 198.18.0.48/29 [10/0] via 198.18.0.142, sg0e0-dmz0
C 198.18.0.128/30 is directly connected, sg0e0-cisco0
C 198.18.0.136/30 is directly connected, sg0e0-hp0
C 198.18.0.140/30 is directly connected, sg0e0-dmz0
S 198.18.0.160/28 [10/0] via 198.18.0.142, sg0e0-dmz0
S 198.18.0.176/28 [10/0] via 198.18.0.142, sg0e0-dmz0
S 198.18.0.192/28 [10/0] via 198.18.0.142, sg0e0-dmz0
S 198.18.1.0/24 [10/0] via 198.18.0.130, sg0e0-cisco0
S 198.18.3.0/24 [10/0] via 198.18.0.138, sg0e0-hp0
C 198.18.4.0/24 is directly connected, sg0-e-link-lan
S 198.18.10.0/25 [10/0] is directly connected, ssl.root
S 198.18.11.0/25 [10/0] is directly connected, ssl.root
S 198.18.13.0/25 [10/0] is directly connected, ssl.root
S 198.18.13.128/25 [10/0] is directly connected, ssl.root
C 217.193.240.160/29 is directly connected, vdom-wan1
|
Wenn ich die gesamte Routing-Tabelle sehen möchte (aktive und inaktive Routen) kann ich die Routing Datenbank wie folgt abfragen:
(Routen welche mit * markiert sind, sind aktive Routen)
|
Konfiguration über CLI: get router info routing-table database |
# get router info routing-table database
Routing table for VRF=0
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
> - selected route, * - FIB route, p - stale info
S *> 0.0.0.0/0 [10/0] via 217.193.240.161, vdom-wan1
S *> 172.16.10.0/24 [10/0] via 198.18.0.138, sg0e0-hp0
S *> 172.16.20.0/24 [10/0] via 198.18.0.138, sg0e0-hp0
S *> 172.16.30.0/24 [10/0] via 198.18.0.138, sg0e0-hp0
S *> 172.16.40.0/24 [10/0] via 198.18.0.138, sg0e0-hp0
S *> 172.16.99.0/24 [10/0] via 198.18.0.138, sg0e0-hp0
C *> 198.18.0.0/27 is directly connected, port1
S *> 198.18.0.40/29 [10/0] via 198.18.0.142, sg0e0-dmz0
S *> 198.18.0.48/29 [10/0] via 198.18.0.142, sg0e0-dmz0
C *> 198.18.0.128/30 is directly connected, sg0e0-cisco0
C *> 198.18.0.136/30 is directly connected, sg0e0-hp0
C *> 198.18.0.140/30 is directly connected, sg0e0-dmz0
S *> 198.18.0.160/28 [10/0] via 198.18.0.142, sg0e0-dmz0
S *> 198.18.0.176/28 [10/0] via 198.18.0.142, sg0e0-dmz0
S *> 198.18.0.192/28 [10/0] via 198.18.0.142, sg0e0-dmz0
S *> 198.18.1.0/24 [10/0] via 198.18.0.130, sg0e0-cisco0
S *> 198.18.3.0/24 [10/0] via 198.18.0.138, sg0e0-hp0
C *> 198.18.4.0/24 is directly connected, sg0-e-link-lan
S *> 198.18.10.0/25 [10/0] is directly connected, ssl.root
S *> 198.18.11.0/25 [10/0] is directly connected, ssl.root
S *> 198.18.13.0/25 [10/0] is directly connected, ssl.root
S *> 198.18.13.128/25 [10/0] is directly connected, ssl.root
C *> 217.193.240.160/29 is directly connected, vdom-wan1
|
Folgende Optionen stehen weiter für das Commande get router info routing-table zur Verfügung:
| Parameter | Beschreibung |
|---|---|
| details | Anzeigen der Detail-Informationen der Routing-Tabelle |
| all | Anzeigen von allen Einträgen in der Routing-Tabelle |
| rip | Anzeigen der RIP Routing-Tabelle |
| ospf | Anzeigen der OSPF Routing-Tabelle |
| bgp | Anzeigen der BGP Routing-Tabelle |
| isis | Anzeigen der IS-IS Routing-Tabelle |
| static | Statische Routing-Tabelle anzeigen |
| connected | zeigt die Routing-Tabelle der verbundenen Routen an |
| database | zeigt die Datenbank der Routing-Tabelle an (alle aktiven und passiven Routen) |
Wie kann ich auf einer FortiGate den Routing "cache" auflisten und aktualisieren?
Auf der FortiGate wird ein Cache angelegt. Dies bedeutet, dass wenn ein Routing Eintrag erstellt wird (wie zum Beispiel eine statische Route konfiguriert wird), so wird beim ersten Nutzen der Route im Hintergrund automatisch ein Eintrag im Cache angelegt. Dadurch muss die FortiGate nicht jedes Mal die Routing Tabelle konsultieren, sondern erhält bei einer nächsten Anfrage die Routinginformationen schneller und direkter aus dem Cache. Wenn ich sehen will, welche Routen im Cache sind kann ich folgenden Befehl verwenden:
|
Konfiguration über CLI: diagnose ip rtcache list |
# diagnose ip rtcache list family=02 tab=254 vf=0 type=02 tos=0 flag=80000200 0.0.0.0@0->198.18.0.1@64(root) gwy=0.0.0.0 prefsrc=198.18.0.1 ci: ref=1 lastused=1 expire=0 err=00000000 used=819 br=0 pmtu=16436 family=02 tab=254 vf=0 type=03 tos=0 flag=90000200 193.193.135.65@5(wan1)->193.193.135.95@64(root) gwy=0.0.0.0 prefsrc=0.0.0.0 ci: ref=1 lastused=220 expire=0 err=00000000 used=5 br=0 pmtu=1492 family=02 tab=254 vf=0 type=02 tos=0 flag=80000200 193.193.135.65@5(wan1)->193.193.135.66@64(root) gwy=0.0.0.0 prefsrc=193.193.135.66 ci: ref=3 lastused=0 expire=0 err=00000000 used=348 br=0 pmtu=1492 family=02 tab=254 vf=0 type=01 tos=0 flag=00000200 198.18.3.1@0->198.18.3.3@4(dmz) gwy=0.0.0.0 prefsrc=0.0.0.0 ci: ref=1 lastused=8 expire=0 err=00000000 used=952 br=0 pmtu=1500 family=02 tab=254 vf=0 type=03 tos=0 flag=90000200 0.0.0.0@66(fortinet4intern)->255.255.255.255@64(root) gwy=0.0.0.0 prefsrc=198.18.2.1 ci: ref=1 lastused=282 expire=0 err=00000000 used=0 br=0 pmtu=1500 family=02 tab=254 vf=0 type=01 tos=0 flag=00000200 0.0.0.0@0->193.193.135.65@5(wan1) gwy=0.0.0.0 prefsrc=193.193.135.66 ci: ref=1 lastused=0 expire=0 err=00000000 used=2109 br=0 pmtu=1492 family=02 tab=254 vf=0 type=01 tos=0 flag=00000200 0.0.0.0@0->193.193.135.65@5(wan1) gwy=0.0.0.0 prefsrc=193.193.135.66 ci: ref=1 lastused=0 expire=0 err=00000000 used=8022 br=0 pmtu=1492 family=02 tab=254 vf=0 type=01 tos=0 flag=00000200 0.0.0.0@0->198.18.3.3@4(dmz) gwy=0.0.0.0 prefsrc=198.18.3.1 ci: ref=1 lastused=4 expire=0 err=00000000 used=59 br=0 pmtu=1500 family=02 tab=254 vf=0 type=03 tos=0 flag=90000200 198.18.2.2@66(fortinet4intern)->198.18.2.127@64(root) gwy=0.0.0.0 prefsrc=0.0.0.0 ci: ref=1 lastused=135 expire=0 err=00000000 used=61 br=0 pmtu=1500 family=02 tab=254 vf=0 type=01 tos=0 flag=00000200 198.18.2.1@0->198.18.2.2@66(fortinet4intern) gwy=0.0.0.0 prefsrc=0.0.0.0 ci: ref=1 lastused=48 expire=0 err=00000000 used=22 br=0 pmtu=1500 family=02 tab=254 vf=0 type=01 tos=0 flag=00000200 0.0.0.0@0->198.18.0.90@7(internal1) gwy=0.0.0.0 prefsrc=198.18.0.1 ci: ref=1 lastused=3 expire=0 err=00000000 used=491 br=0 pmtu=1500 family=02 tab=254 vf=0 type=02 tos=0 flag=80000200 198.18.3.2@4(dmz)->198.18.3.1@64(root) gwy=0.0.0.0 prefsrc=198.18.3.1 ci: ref=3 lastused=13 expire=0 err=00000000 used=572 br=0 pmtu=1500 family=02 tab=254 vf=0 type=02 tos=0 flag=80000200 198.18.2.2@66(fortinet4intern)->198.18.2.1@64(root) gwy=0.0.0.0 prefsrc=198.18.2.1 ci: ref=10 lastused=0 expire=0 err=00000000 used=20 br=0 pmtu=1500 family=02 tab=254 vf=0 type=01 tos=0 flag=00000200 198.18.3.1@0->198.18.3.2@4(dmz) gwy=0.0.0.0 prefsrc=0.0.0.0 ci: ref=1 lastused=13 expire=0 err=00000000 used=660 br=0 pmtu=1500 family=02 tab=254 vf=0 type=01 tos=0 flag=00000200 198.18.0.1@0->198.18.0.90@7(internal1) gwy=0.0.0.0 prefsrc=0.0.0.0 ci: ref=1 lastused=1 expire=-2395 err=00000000 used=440 br=0 pmtu=1500 family=02 tab=254 vf=0 type=02 tos=0 flag=80000200 198.18.3.3@4(dmz)->198.18.3.1@64(root) gwy=0.0.0.0 prefsrc=198.18.3.1 ci: ref=3 lastused=4 expire=0 err=00000000 used=1 br=0 pmtu=1500 |
Der Cache selbst kann nicht direkt verändert oder manipuliert werden. Es ist auch nicht möglich einzelne Einträge aus dem Cache zu löschen.
Will man den Cache aktualisieren oder löschen so kann dies indirekt über das refreshen der Routing Tabelle vorgenommen werden. Mit diesem Kommando execute router restart werden im Cache, wie auchim Kernel die Routing Informationen auf den neuesten Stand gebracht:
|
Konfiguration über CLI: execute router restart |
# execute router restart |
Aus diesem Grund wird empfohlen nach jeder Routing Änderungen diesen Befehl abzusetzen um gewährleisten zu können, dass alle Routing Informationen aller Routing Tabellen auf den neusten Stand gebracht wurden.
Was ist eine Blackhole-Route?
Eine Blackhole-Route ist eine Route, die den gesammten, an sie gesendeten Datentraffic unterbindet. Dies funktioniert sehr ähnlich wie /dev/null in der Linux-Programmierung. Blackhole-Routen werden verwendet, um Pakete zu entsorgen, anstelle auf verdächtige Anfragen zu reagieren. Dies bietet zusätzliche Sicherheit, da der Absender keine Informationen aus dem Destination-Netzwerk erhält.
Blackhole-Routen können auch den Traffic in einem Subnetz einschränken. Wenn einige Subnetzadressen nicht verwendet werden, kann der Traffic zu diesen Adressen (Traffic, welcher gültig oder bösartig sein kann) an ein Blackhole-Route geleitet werden. So kann zusätzliche Sicherheit gewährleisten werden oder den Traffic zum Subnetz zu reduziert werden.
Zum Beispiel bei einer IPSec Side-to-Side Verbindung wird, wenn das Tunnelinterface aktiv ist (und somit der VPN Tunnel up), ein Routing Eintrag erstellt. Wenn dieser Tunnel und somit auch das Tunnelinterface down geht, wird die nächste zutreffende Route für die Session genutzt. Meist ist dies die Default Route zum Standard Gateway. Dies bedeutet, dasss der Traffic welcher für die remote Lokation des Tunnels gedacht ist, ins Internet geroutet wird. Kommt jetzt das Tunnelinterface wieder hoch, bleibt die Session aber über den Standard Gateway aktiv. Dieser Zustand bleibt solange bestehen bis diese Session nicht mehr aktiv ist oder manuell beendet wird. Ein "Refreshing" der Routing Tabelle mit dem Befehl "execute router restart" löst dieses Problem nicht, weil durch dieses Kommando eine Session nicht beendet wird. Die einzige Möglichkeit wäre, die Session manuell zu löschen. Jetzt kommt die Blackhole-Route ins Spiel. Die Blackhole-Route wird das Netz an ein Nulldevice routen. Eine Blackhole-Route muss mit einer grösseren Distanz konfiguriert werden, als die anderen Routen. Empfohlen wird die Distanz 254 zu wählen.
| Konfiguration über das WebGui:
|
|
Im Menu Netzwork -> Static Routes
|
| Konfiguration über die CLI:
|
config router static edit [ID] -> Route ID angeben z.B 1 set dst 172.16.16.0 255.255.255.0 set distance 254 set comment "Blackhole Route 172.16.16.0/24" set blackhole enable end |
Statische Route 172.16.16.0/24 auf Tunnel Interface aktiv:
Wir haben ein VPN-Tunnel welcher das Netz 172.16.16.0/24 auf das Tunnel Interface vpn_to_sideB routet. Wenn wir die Routingtabelle anschauen, sehen wir dass dieses Netz 172.16.16.0/24 auf das Interface vpn_to_sideB mit der Distanz 10 geroutet wird.
| Konfiguration über das WebGui:
|
|
| Konfiguration über die CLI:
|
get router info routing-table all
Routing table for VRF=0
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default
S* 0.0.0.0/0 [1/0] via 198.18.0.1, wan1
S 172.16.16.0/24 [10/0] is directly connected, vpn_to_sideB
C 192.168.2.0/24 is directly connected, internal
C 198.18.0.0/27 is directly connected, wan1
|
Statische Route 172.16.16.0/24 auf Tunnel Interface aktiv:
Jetzt wird der VPN-Tunnel unterbrochen und das Tunnel Interface vpn_to_sideB wird inaktiv. Wenn wir jetzt keine default Route hätten, würde das Netz 172.16.16.0/24 auf den default Gateway (198.18.0.1) geroutet. Da wir jetzt aber die Blackhole-Route für die 172.16.16.0/24, mit der Distanz 254 konfiguriert haben, sehen wir in der Routingtabelle, dass der ganze Traffic zum Destinations Netz 172.16.16.0/24 auf das Blackhole Interface routet wird:
| Konfiguration über das WebGui:
|
|
| Konfiguration über die CLI:
|
get router info routing-table all
Routing table for VRF=0
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default
S* 0.0.0.0/0 [1/0] via 198.18.0.1, wan1
S 172.16.16.0/24 [254/0] is a summary, Null
C 192.168.2.0/24 is directly connected, internal
C 198.18.0.0/27 is directly connected, wan1
Wenn ich die ganze Routing Tabelle anschaue (auch mit den inaktiven Routen) sehe ich beide Routen auf die Adresse 172.16.16.0/24. Die Route welche mit einem * markiert wird, ist die aktive Route. get router info routing-table database
Routing table for VRF=0
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
> - selected route, * - FIB route, p - stale info
S *> 0.0.0.0/0 [1/0] via 198.18.0.1, wan1
S 172.16.16.0/24 [10/0] is directly connected, vpn_to_sideB inactive --> Die Route auf das Tunnel Interface ist inaktiv
S *> 172.16.16.0/24 [254/0] is a summary, Null --> Die Route auf das Null Device (Blackhole) ist aktiv
C *> 192.168.2.0/24 is directly connected, internal
C *> 198.18.0.0/27 is directly connected, wan1
|
|
|
Grundsätzlich kann man auf jeder FortiGate die privaten IP Ranges auf eine Blackhole-Route konfigurieren. Mit diesen drei Routen kann so jeglicher Traffic, welcher in das Public WAN (INTERNET) geroutet wird, direkt abgefangen werden. Für folgende private Netze kann also eine Blackhole Route defaultmässig eingerichtet werden: Private Netze Gemäss RFC1918:
Siehe auch : https://tools.ietf.org/html/rfc1918 |
| Konfiguration über die CLI:
|
config router static edit 1 set dst 10.0.0.0/8 set distance 254 set comment "Blackhole 10.0.0.0/8 - RFC1918" set blackhole enable next edit 2 set dst 172.16.0.0/12 set distance 254 set comment "Blackhole 172.16.0.0/12 -RFC1918" set blackhole enable next edit 3 set dst 168.168.0.0/16 set distance 254 set comment "Blackhole 192.168.0.0/16-RFC1918" set blackhole enable next end |
Weitere Informationen betreffend privatem IP Adress-Bereich siehe auch: https://de.wikipedia.org/wiki/Private_IP-Adresse
|
|
Wenn ein Class D (Verwendung für Multicast-Anwendungen) oder Class E Netz (reserviert für zukünftige Zwecke) in eine Blackhole-Route konfiguriert werden soll, wird dies von der FortiGate nicht unterstützt. Weitere Infos über die Netzklassen : https://de.wikipedia.org/wiki/Netzklasse Beispiel in der CLI: config router static
edit 0
new entry '0' added
set blackhole enable
set distance 254
set dst 224.0.0.0/3
ip address must be a class A, B, or C ip
value parse error before '224.0.0.0/3'
Command fail. Return code -8
|
Wie kann ich das Swisscom TV über die FortiGate betreiben?
ARTIKEL NOCH IN BEARBEITUNG und nicht VOLLSTÄNDIG
Um das Swisscom TV über die FortiGate zu routen müssen Multicast Routen eingerichtet werden. Wir gehen in diesem Fall von folgendem Szenario aus: Wir haben einen Swisscom Router, eine FortiGate und die Swisscom TV Box. Wir wollen die FortiGate zwischen dem Router und der TV-Box dazwischen als Perimeter Firewall schalten. Dafür müssen wir auf dem Swisscom Router die "DMZ" Funktion aktiveren und sämtlichen eingehenden Traffic auf die FortiGate weiterleiten. Zwischen der FortiGate und dem Swisscom Router konfigurieren wir ein Transit Netz. Jetzt haben wir sämtlichen Traffic (ausser die Telefone welche direkt am Router angehängt sind) auf der FortiGate. Jetzt können auf der FortiGate die Multicast Policies konfiguriert werden und das Swisscom TV läuft. In dieser Anleitung zeige ich ein praktisches Beispiel wie man das konfigurieren könnte:
Als erstes auf dem Swisscom Router folgende Konfigurationen vornehmen:
DMZ Funktion einschalten und auf die FortiGate weiterleiten.
| Bild | Beschreibung |
|---|---|
 |
Um sämtlichen eingehenden Traffic auf die FortiGate weiter zu leiten, muss auf dem Swisscom Router die DMZ Funktion aktiviert werden. Als Destination wird die FortiGate ausgewählt. |
Wir nutzen auf der FortiGate auf dem internal Interface (LAN) den DHCP Dienst. Damit die Swisscom TV Box immer die selbe IP Adresse bekommt, konfigurieren wir eine MAC Reservierung:
config system dhcp server edit 1 config reserved-address edit 1 set ip 10.60.60.10 set mac 48:8d:XX:XX:XX:XX set description "swisscom TV Box" next end next end
Auf der FortiGate erfassen wir ein Adressen Objekt für die Swisscom TV Box (in unserem Fall 10.60.60.10/32)
config firewall address edit "h_swisscomTV-10.60.60.10-32" set comment "Swisscom TV Device" set color 3 set subnet 10.60.60.10 255.255.255.255 next end
Nun muss auf der FortiGate das Multicast Routing ausgeschaltet oder überprüft werden dass dieses ausgeschaltet ist:
config router multicast set multicast-routing disable end
Die Multicast Weiterleitung konfigurieren:
config system settings set multicast-forward enable end
Wir wollen verhindern, dass die FortiGate bei den weitergeleiteten Multicast Paketen den TTL Wert nicht erhöht:
config system settings set mutlicast-ttl-notchange enable end
Im nächsten Schritt müssen zwei Multicast Regeln konfiguriert werden. Damit wir im WebGui die Option sehen, muss diese eventuell noch aktiviert werden:
Policy&Objects -> Mutlicast Polciy -> Create New+
Jetzt müssen wir zwei Multicast Adress-Objekte für 224.0.0.0 - 224.255.255.255 und 239.0.0.0 - 239.255.255.255 erstellen.
| Konfiguration über das WebGui:
|
Konfiguration über die CLI:
|
|---|---|
|
Menu:Policy & Objects -> Addresses -> Create New+ -> Category Multicast Address |
config firewall multicast-address
edit "mc-swisscom_224.0.0.0-224.255.255.255"
set start-ip 224.0.0.0
set end-ip 224.255.255.255
set color 26
next
edit "mc-swisscom_239.0.0.0-239.255.255.255"
set start-ip 239.0.0.0
set end-ip 239.255.255.255
set color 26
next
end
|
Regel 1: von 0.0.0.0/0 zu den Multicast Adressen SNAT in dieser Regel nicht aktivieren.
Regel 2:
Von der Swisscom TV Box zu den Multicast Adressen
SNAT muss in dieser Regel aktiviert werden
Nun sollte das Swisscom TV über die FortiGate funktionieren.
SD-WAN
Dieser Artikel beschreibt, wie Sie eine Hilfssitzung mit ECMP oder SD-WAN aktivieren können.
Wie kann ich für ECMP oder SD-WAN Hilfesession (Auxiliary-session) auf der FortiGate aktivieren?
]]
Wenn wir ECMP oder SD-WAN benutzen, sind mehrere Interfaces für den eingehenden oder ausgehenden Traffic definiert. Dies bedeutet, dass der Traffic eingehend oder ausgehend auf einem anderen Interface stattfinden kann. Wenn der Datentraffic wieder von der FortiGate ausgeht, versucht er einer bestehenden TCP Session zu entsprechen. Diese TCP-Session wird aber fehlschlagen, da sich das Interface für den eingehenden Datentraffic geändert hat.
Default mässig wird nur eine Session zur Abwicklung des Datentraffics verwendet. Jede Änderung auf dem eingehenden Interface (Orginal/Antwort) führt zu einer dirty Session und wird verworfen.
Aktiviert man die auxiliary-session Funkion wird eine Multisession aktivert. Dies bedeutet dass eine Hauptsession und Hilfssesions (verschiedene eingehende Interfaces) gibt um den Traffic zu handeln.
| Konfiguration über die CLI:
|
id=20085 trace_id=10 func=print_pkt_detail line=5501 msg="vd-root:0 received a packet(proto=6, 172.22.4.99:47287->172.23.4.100:443) from vlan4. flag [S], seq 3291199818, ack 0, win 65535" id=20085 trace_id=10 func=init_ip_session_common line=5666 msg="allocate a new session-000015a7" id=20085 trace_id=10 func=vf_ip_route_input_common line=2596 msg="find a route: flag=04000000 gw-80.78.133.251 via tun1" id=20085 trace_id=10 func=fw_forward_handler line=771 msg="Allowed by Policy-14: SNAT" id=20085 trace_id=10 func=ids_receive line=289 msg="send to ips" id=20085 trace_id=10 func=__ip_session_run_tuple line=3286 msg="SNAT 172.22.4.99->192.168.1.1:47287" id=20085 trace_id=10 func=ipsecdev_hard_start_xmit line=777 msg="enter IPsec interface-tun1" id=20085 trace_id=10 func=esp_output4 line=904 msg="IPsec encrypt/auth" id=20085 trace_id=11 func=print_pkt_detail line=5501 msg="vd-root:0 received a packet(proto=6, 172.22.4.99:47287->172.23.4.100:443) from vlan4. flag [.], seq 3291199819, ack 1663915319, win 1034" id=20085 trace_id=11 func=resolve_ip_tuple_fast line=5581 msg="Find an existing session, id-000015a7, original direction" id=20085 trace_id=11 func=ids_receive line=289 msg="send to ips" id=20085 trace_id=11 func=ip_session_core_in line=6275 msg="outgoing dev changed:44->42 dir=original, drop" id=20085 trace_id=12 func=print_pkt_detail line=5501 msg="vd-root:0 received a packet(proto=6, 172.22.4.99:47287->172.23.4.100:443) from vlan4. flag [.], seq 3291199819, ack 1663915319, win 1034" id=20085 trace_id=12 func=vf_ip_route_input_common line=2596 msg="find a route: flag=04000000 gw-192.168.1.1 via tun1" id=20085 trace_id=12 func=fw_forward_dirty_handler line=385 msg="no session matched" |
Default mässig ist die Funktion deaktiviert. Dies können wir auch über die CLI wie folgt ermitteln:
| Konfiguration über die CLI:
|
# config system settings # show full-configuration | grep aux # set auxiliary-session disable |
Die Funktion kann wie folgt eingeschaltet werden:
| Konfiguration über die CLI:
|
# config system settings # set auxiliary-session enable # end |
Welche OIDs gibt es im Zusammenhang mit dem Link Monitor um den SD-WAN Status abzufragen?
Folgende OIDs gibt es welche den Status vom Link Monitor angeben:
| OID | Beschreibung |
|---|---|
| .1.3.6.1.4.1.12356.101.4.8.2 | fgLinkMonitorTable |
| .1.3.6.1.4.1.12356.101.4.8.2.1.1 | fgLinkMonitorID |
| .1.3.6.1.4.1.12356.101.4.8.2.1.2 | fgLinkMonitorName |
| .1.3.6.1.4.1.12356.101.4.8.2.1.3 | fgLinkMonitorState |
| .1.3.6.1.4.1.12356.101.4.8.2.1.4 | fgLinkMonitorLatency |
| .1.3.6.1.4.1.12356.101.4.8.2.1.5 | fgLinkMonitorJitter |
| .1.3.6.1.4.1.12356.101.4.8.2.1.6 | fgLinkMonitorPacketSend |
| .1.3.6.1.4.1.12356.101.4.8.2.1.7 | fgLinkMonitorPacketRecv |
| .1.3.6.1.4.1.12356.101.4.8.2.1.8 | fgLinkMonitorPacketLoss |
Kann eine FG-90D in die die neue SD-WAN Orchestration eingebunden werden?
SD-WAN Orchestration kann mit der FG90D aktuell nicht genutzt werden, da dieses Modell aktuell noch nicht unterstützt wird:
https://docs.fortinet.com/document/fortimanager/6.4.1/sd-wan-orchestrator-release-notes/798783/supported-fortigate-models
Policy Routing
Email Service
Wie kann auf einer FortiGate den "Email-Service" konfigurieren?
Im FortiOS bezeichnet die "Email Service" Funktion die Konfiguration eines SMTP Servers. Ein Email Server auf der FortiGate wird für verschiedene Funktionen benötigt:
- Alert Email
- Two-Factor Authentifizierung
- Wireless Guest-Provisioning
Der "Email-Service" wird über das Web-GUI folgendermassen konfiguriert:
| Konfiguration über das WebGui:
|
|
Menu: System > Settings -> Email Service (6.2)
|
| Konfiguration über die CLI:
|
# config system email-server # set type custom # set reply-to [Absender Email Adresse] # set server [FQDN SMTP Server] # set port [Gebe einen entsprechenden Port an zBsp "25"] # set source-ip [Optional gebe eine Source IPv4 Adresse an für den Absender der SMTP Nachricht] # set source-ip6 [Optional gebe eine Source IPv6 Adresse an für den Absender der SMTP Nachricht] # set authentication [enable | disable] # set username [Username für die Authentifizierung] # set password [Passwort für die Authentifizierung] # set validate-server [enable| disable] # set security [none | smtps | starttls] # end |
Es ist auch möglich von Fortinet den SMTP Server zu benutzen:
| Konfiguration über das WebGui:
|
|
| Konfiguration über die CLI:
|
# config system email-server # set reply-to [Absender Email Adresse] # set server "notification.fortinet.net" # set port 465 # set Security smtps # end |
Zwei Faktor Authentifizierung
Wie kann ich die Timeouts für die 2FA Dienste auf der FortiGate anpassen?
Wenn das SSL-VPN mit Zwei-Faktor-Authentifizierungen(2FA) wie E-Mail, SMS, FortiToken konfiguriert ist, kann unter Umständen ein längerer Token-Ablauf des Timers erforderlich sein, als jener der Standardeinstellung von 60 Sekunden. Die Ablaufzeiten können wie folgt konfiguriert werden:
| Konfiguration über die CLI:
|
# config system global # set two-factor-ftk-expiry [Zeit in Sekunden] -> FortiToken Session Timeout # set two-factor-ftm-expiry [Zeit in Sekunden] -> FortiToken Mobile Session Timeout # set two-factor-sms-expiry [Zeit in Sekunden] -> SMS Session Timeout # set two-factor-fac-expiry [Zeit in Sekunden] -> FortiAuthenticator Token Session Timeout # set two-factor-email-expiry [Zeit in Sekunden] -> Email Session Timeout # end |
Während diese Timer für die Token selbst gelten (und die Token-Codes so lange gültig bleiben, wie sie konfiguriert sind), muss beim SSL-VPN jedoch nicht für die gesamte Dauer der Gültigkeit der Token akzeptieren. Um sicherzustellen, dass SSL-VPN die Token akzeptiert, muss ein weiterer Zeitgeber konfiguriert werden:
| Konfiguration über die CLI:
|
# config system global # set remoteauthtimeout [1-300s] # end |
Die maximal konfigurierbare Zeitüberschreitung hierfür beträgt 5 Minuten. Das SSL-VPN wartet maximal 5 Minuten auf die Bereitstellung eines gültigen Token-Codes, bevor die Verbindung beendet wird, auch wenn der Token-Code länger gültig ist.
|
|
Die Das bedeutet, dass wenn der Timer erhöht wird, die FortiGate beinträchtig werden kann. Der Server ist nicht erreichbar, wenn der erhöhte Timer zu lange benötigt, um die FortiGate zu erreichen. |
FortiGate und FortiAuthentikator:
Was auch beachtet werden muss ist, dass wenn mit einem FortiAuthenticator gearbeitet wird, dieser auch einen Timer für die Token hat. Die FortiGate verwendet die RADIUS-Authentifizierung für die SSL-VPN-Benutzerauthentifizierung. Der FortiAuthenticator wird als RADIUS-Server verwendet. Um die Sicherheitsstufen zu verstärken, ist FortiAuthenticator so konfiguriert, dass für eine erfolgreiche Authentifizierung eine Zwei-Faktor-Authentifizierung (2FA) erforderlich ist. Der FortiAuthenticator verfügt über mehrere Optionen, um 2FA von einem Benutzer zu verlangen. Diese können Hardware FortiToken, FortiToken Mobile, Mail oder SMS-Dienste sein. Bei den letzteren beiden kann es zu Zeitüberschreitungen kommen. Standardmässig erwartet FortiAuthenticator den Token-Code nach 60 Sekunden. Dieser Wert kann angepasst werden. Es reicht jedoch nicht aus, nur das Timeout im FortiAuthenticator zu ändern, da die FortiGate auch einen eigenen Timeout-Wert hat. Man muss diesen Wert also auch ändern, wenn man die Zeit zwischen der Eingabe von Benutzername/Passwort und Token-Code erhöhen möchten. Die Timer sind auf der FotiGate wie oben erklärt, anpassbar.
Auf dem FortiAuthentikator kann das unter folgendem Menue konfiguriert werden:
| Konfiguration im FortiAuthenticator 6.x:
|
|
Über das Menue User Account Policies -> Tokens können die Timeouts konfiguriert werden:
|
Wie kann ich auf einer FortiGate einen SMS Service / Provider konfigurieren?
Wenn auf einer FortiGate eine Two-Factor Authentication konfiguriert wird, so soll basierend auf ODA (On-Demand Authentication) muss ein entsprechender SMS Service resp. Provider konfiguriert werden. Per Standard steht auf einer FortiGate ein FortiGuard SMS Provider zur Verfügung jedoch ist dieser FortiGuard SMS Provider nicht in FortiCare und/oder FortiGuard enthalten. Bei diesem FortiGuard SMS Provider handelt es sich um den Amerikanischen SMS Provider Clickatell.
Anstelle des FortiGuard SMS Services kann auch ein lokaler SMS Provider gewählt werden. Dabei muss beachtet werden, dass der SMS Provider einen SMS Versandt über EMail unterstützt. Grund ist, dass die FortiGate kein SMS Versand über HTTP/S GET und POST unterstützt. Ein paar SMS-Provider welche wir empfehlen:
- Swisscom (@sms.ip-plus.net)
- F24 (Dolphin) (https://www.f24.com/tochtergesellschaften/f24-schweiz-ag/)
- Truesenses (http://www.truesenses.com/)
Da der SMS Versand über den Email Service durchgeführt wird, gilt die Konfiguration eines Email Service als Voraussetzung für die Konfiguration eines SMS Service. Wie der Email Service zu konfigurieren ist siehe nachfolgender Artikel: Email Service auf der FortiGate konfigurieren. Danach sind die Voraussetzungen gegeben einen SMS Service respektive Provider auf der FortiGate zu konfigurieren. Die Konfiguration kann über CLI durchgeführt werden:
| Konfiguration über die CLI:
|
# config system sms-server # edit [Name des Service/Provider zB "swisscom"] # set mail-server [FQDN des Mail Server für SMS Versandt zB "sms.ip-plus.net"] # end |
Wird ein User lokal erfasst und dieser mittels SMS eine Two-Factor Authentifizierung aktiviert werden muss für, diesen User eine entsprechende Mobile Nummer definiert werden. Wird über einen Service auf der FortiGate eine Two-Factor Authentifizierung ausgelöst so wird im Hintergrund über den definierten SMS Service/Provider der für die Mobiel Nummer konfiguriert wurde ein Email generiert in folgender Form: [Land][Vorwahl][Mobile Nummer]@[FQDN des Mail Server für SMS Versandt]
Siehe auch: Wie konfiguriere ich einen User mit SMS Zweifaktor Authentifizierung?
Wie kann ich den Lizenzkey für den FortiGuard SMS Service auf der FortiGate einlesen?
Auf der FortiGate kann ich Two Factor Authentifizierung einrichten. Es gibt die Möglichkeit von Fortinet selber einen SMS Dienst zu erwerben. Die SMS werden von der FortiGuard her ausgelöst. Diese Lizenz enthält jeweils 100 SMS. Der Artikel welcher hierfür erworben werden kann:
SMS-ELIC-100 FortiSMS - License for 100 SMS text messages
Der Lizenz Key kann über folgenden Befehl auf die FortiGate eingelesen werden:
| Konfiguration über die CLI:
|
# execute fortiguard-message add xxxx-xxxx-xxxx-xxxx-xxxx ---> Den Aktivierungs Code der SMS Lizenz gemäss erhaltenem Dokument einfügen. # execute fortiguard-message update |
Das Guthaben kann wie folgt über die CLI abgefragt werden: execute fortiguard-message info
| Konfiguration über die CLI:
|
# execute fortiguard-message info Controller server status: registered Expiry date: 20200102 SMS max allowed: 4 SMS used: 4 Last update: Wed Apr 17 10:31:02 2019 Current message server: 208.91.113.184:443 Message server status: unknown |
FortiView
Wo ist die Ansicht "All-Session" im FortiOS 6.4.0?
]]
Im FortiOS 6.4.0 fällt einem sicher sehr schnell auf, dass die Option All-Session in der FortiView nicht mehr vorhanden ist.
Es handelt sich hier um einen Bug im FortiOS 6.4.0. Wir haben es dem TAC gemeldet und diese haben es an das Developpentteam weitergeleitet.
Der Bug wird unter der Nummer 615524 behandelt.
In der Zwischenzeit kann man unter den Top Policies by Session im Drilldown-Menu zu den Sessions gelangen:
| Konfiguration über das WebGui:
|
|
|
Der Bug ist im FortiOS 6.4.1 behoben worden
Nun findet man die Session-Ansicht in der FortiView:
| Konfiguration über das WebGui:
|
|
|
Prozesse
Wie kann ich auf einer FortiGate die Prozesse auflisten?
Auf einer FortiGate existieren unzählige von Prozesse und Dienste welche zuständige sind um die verschiedenen Aufgaben einer Firewall durchzuführen. Um die Prozesse aufzulisten kann folgendes Kommando benutzt werden:
| Konfiguration über die CLI:
|
# diagnose sys top [refresh_time_sec] [number_of_lines] |
|
Wenn man die "top" 20 Prozesse (Standard) auflisten möchte, kann der # diagnose sys top
Run Time: 0 days, 2 hours and 1 minutes
0U, 0N, 0S, 100I, 0WA, 0HI, 0SI, 0ST; 1866T, 636F
ipsengine 358 S < 0.1 5.0
extenderd 178 S 0.1 0.4
lnkmtd 161 S 0.1 0.3
newcli 554 R < 0.1 0.3
ipsengine 356 S < 0.0 5.0
ipsengine 357 S < 0.0 5.0
ipsengine 359 S < 0.0 5.0
ipshelper 355 S < 0.0 4.2
scanunitd 352 S < 0.0 2.1
scanunitd 525 S < 0.0 2.0
scanunitd 526 S < 0.0 2.0
scanunitd 523 S < 0.0 1.9
scanunitd 524 S < 0.0 1.9
cmdbsvr 100 S 0.0 1.7
forticron 136 S 0.0 1.4
pyfcgid 495 S 0.0 1.2
cw_acd 168 S 0.0 1.2
httpsd 212 S 0.0 1.0
httpsd 210 S 0.0 1.0
httpsd 127 S 0.0 0.9
Um den Befehl respektive die Funktion zu beenden benütze "Ctrl + C". Beschreibung: Datei:Fortinet-307.jpg |
Die in der zweiten Ausgabezeile angezeigten Codes haben folgende Bedeutung:
0U, 0N, 0S, 100I, 0WA, 0HI, 0SI, 0ST; 1866T, 636F
- U ist der Prozentsatz der User-Space-Anwendungen, welche die CPU verwenden. Im Beispiel bedeutet 0U 0 % der User-Space-Anwendungen, die CPU verwenden.
- S ist % der Systemprozesse (oder Kernelprozesse), welche die CPU verwenden. Im Beispiel bedeutet 0S, dass 0 % der Systemprozesse die CPU verwenden.
- I ist % die ungenutzte CPU. Im Beispiel bedeutet 98I, dass die CPU zu 100% im Leerlauf ist.
- T ist der gesamte FortiOS-Systemspeicher in Mb. In dem Beispiel bedeutet 1866T, dass 1866 Mb des Systemspeichers vorhanden ist.
- F ist der freie Speicher in Mb. Im Beispiel bedeutet 636F, dass 636 Mb freier Speicher vorhanden sind.
- KF ist die Summe der verwendeten Shared-Memory-Seiten. Wenn zum Beispiel 32KF stehen würde, bedeutet dies, das System 32 Seiten des gemeinsamen Speichers verwendet werden.
Jede zusätzliche Zeile der Befehlsausgabe zeigt Informationen für jeden der auf der FortiGate laufenden Prozesse an. Die dritte Zeile der Ausgabe lautet in diesem Beispiel:
ipsengine 358 S < 0.1 5.0
- ipsengine ist der Name des Prozesses. Andere Prozessnamen können newcli, sshd, cmdbsrv, httpsd, scanunitd und miglogd enthalten.
- 358 ist die Prozess-ID. Die Prozess-ID kann eine beliebige Zahl sein.
- S ist der Zustand in welchem sich der Prozess befindet. Es gibt folgende Prozesszustände:
- S = Sleeping
- R = Running
- D = Do not disturb
- Z = Zombie
R und S Status Informationen eines Prozesses sind normal.
Das ein Prozess in den Status D wechselt kann für kurze Zeit vorkommen. Bleibt der Status jedoch für längere Zeit im Status D ist dies ein Indiz dass dieser Prozess nicht korrekt arbeitet.
Ein Status Z für einen Prozess ist klar ein Indiz das dieser Prozess nicht korrekt läuft. Ein Prozess im Status Z kann nicht mit "kill" beendet werden dh., um diesen Prozess zu beenden ist ein Neustart des Devices notwendig! Um eine FortiGate neu zu starten benutze : execute reboot
- 0.1 ist die Menge von der CPU, welche der Prozess verwendet. Der CPU-Verbrauch kann von 0.0 (für einen Prozess der schläft), bis zu höheren Werten reichen wenn ein Prozess viel CPU-Zeit benötigt.
- 5.0 ist die Menge an Memory, welche der Prozess verwendet. Der Speicherverbrauch kann von 0.1 bis 5.5 und höher gehen.
Während der diagnose sys top Befehl ausgeführt wird, kann mit folgenden Tasten eingewirkt werden:
- Taste q zum beenden.
- Taste c um die Prozesse nach Benutzung der CPU zu sortieren.
- Taste m um die Prozesse nach Benutzung des Memories zu sortieren.
Wenn Prozesse untersucht/beobachtet werden sollen kann anhand "refresh_time_sec" und "number_of_lines" der Befehl erweitert werden. Das folgenden Beispiel zeigt, wie der Befehl ausgeführt wird mit einer "refresh_time_sec" von 5 Sekunden und "number_of_lines" von 10. Dies heisst, es werden nur die Top 10 Prozesse/Dienste aufgelistet:
| Konfiguration über die CLI:
|
# diagnsoe sys top 5 10
Run Time: 0 days, 2 hours and 7 minutes
0U, 0N, 0S, 100I, 0WA, 0HI, 0SI, 0ST; 1866T, 651F
miglogd 196 S 0.3 0.9
ipsengine 356 S < 0.1 5.0
ipsengine 357 S < 0.1 5.0
cw_acd 168 S 0.1 1.2
miglogd 195 S 0.1 0.9
src-vis 152 S 0.1 0.6
lnkmtd 161 S 0.1 0.3
newcli 568 R < 0.1 0.3
proxyd 144 S 0.1 0.3
ipsengine 359 S < 0.0 5.0
|
Wie kann ich auf der FortiGate die Prozesse nach Memorie-Auslastung auflisten?
Eine weitere Möglichkeit die Prozesse aufzulisten ist:
| Konfiguration über die CLI:
|
# diagnose sys top-summary -h
Usage: top-summary [options]
Options:
-n LINES, --num=LINES
Number of top processes to show (20 by default)
-i INTERVAL, --interval=INTERVAL
Update interval, in seconds (1 by default)
-s SORT, --sort=SORT Sort mode: [cpu_percent (default)|mem|fds|pid]
-d, --dump Dump stats to the files
-h, --help show this help message and exit
Anhand dieser Optionen kann folgender Befehl abgesetzt werden um mit "-s mem" die Prozesse nach Memory-Nutzung zu sortieren und alle 60 Sekunden "-i 60" einen Refresh durchzuführen, sowie mit "-n 10" die Top 10 Prozesse aufzulisten: # diagnose sys top-summary '-s mem -i 60 -n 10' CPU [|||||||||| ] 25.0% Mem [|||||||||||||||||||||||||| ] 65.0% 1227M/1866M Processes: 10 (running=1 sleeping=135) PID RSS CPU% ^MEM% FDS TIME+ NAME * 130 420M 0.0 22.5 423 02:32.11 ipsmonitor [x6] 352 39M 0.0 2.1 53 00:31.92 scanunitd [x5] 100 32M 0.0 1.7 14 00:07.14 cmdbsvr 136 26M 0.0 1.4 26 00:09.10 forticron 495 24M 0.0 1.3 12 00:00.56 pyfcgid [x4] 168 23M 0.0 1.2 31 05:45.90 cw_acd 127 20M 0.0 1.1 41 00:26.25 httpsd [x11] 125 17M 0.0 0.9 65 00:12.11 miglogd [x3] 167 13M 0.0 0.7 22 00:00.98 fgfmd 591 12M 0.0 0.7 12 00:00.66 newcli [x2] Die Angabe "-s mem" indiziert die Spalte "MEM%" das heisst die Prozesse sollen nach "CPU%" Auslastung sortiert werden anstelle von "-s mem" die Angabe "-s cpu" benützt werden! |
Welche Prozesse existieren auf einer FortiGate und welche Aufgaben haben diese?
Auf der FortiGate existieren unzählige Prozesse welche für verschiedene Aufgaben zuständig sind. Diese könne zBsp anhand "diagnose sys top 5 99" eingesehen werden. Viele Prozesse existieren nur dann, wenn eine entsprechende Konfiguration durchgeführt wird. Andere existieren nur dann, wenn ein bestimmtes FortiGate Modell benutzt wird wie zBsp PoE (Power over Ethernet). Wiederum andere existieren und sind mit dem Stauts "idle" versehen da die Funktion deaktiviert wurde wie zBsp Wirless Controller "cw_acd". Nachfolgend eine Auflistung der bekannten Prozess und einer Kurzbeschreibung dieser:
| Prozess: | Beschreibung: |
| initXXXXXXXXXXX | its job is to start other processes |
| zebos_launcher | zebos launcher daemon |
| hp_api | hp api |
| cmdbsvr | cmdb server - update processes / configuration |
| uploadd | upload daemon |
| adsl2plus | adsl2plus daemon |
| sqldb | sqldb |
| reportd | report daemon |
| sql_logd | sql log daemon |
| miglogd | log daemon |
| chlbd | chassis loadbalance daemon |
| haocd | content cluster HA over chassis daemon |
| kmiglogd | kernel log daemon |
| httpsd | https daemon |
| pyfcgid | python config daemon |
| sslvpnd | ssl vpn |
| info_sslvpnd | ssl vpn info daemon |
| smbcd | smb client daemon |
| lcdapp | Control the LCD panel |
| proxyd | proxy daemon |
| imd | IM proxy daemon |
| wad_launcher | wan acceleration proxy |
| wad | explicit proxy, mapi rpc |
| wad_diskd | wan acceleration disk daemon |
| dlpfingerprint | dlp fingerprint daemon |
| dlpfpcache | dlp fingerprint cache daemon |
| scanunitd | scanunit daemon |
| getty | wait for console/telnet connection |
| mingetty tty1 | mingetty tty1 daemon |
| mingetty tty2 | mingetty tty2 daemon |
| iked | ike daemon |
| nids_monitor_name | ips monitor daemon |
| updated | update daemon <= to init some shared memory segment used by other executables |
| merged_daemons | merge daemon - should be split in future. There is a mantics. |
| fclicense | FC license daemon |
| amc_monitor | AMC monitor daemon |
| forticron | crl update daemon |
| bypass_monitor | bypass monitor daemon |
| chassis5000d | chassis 5000 daemon |
| chassisd 192.168.127.254 | chassis daemon |
| fdsmgmtd | fortiguard management daemon |
| fds_msg | fds message daemon |
| snmpd | snmp |
| dhcpd | dhcp server |
| dhcpcd | dhcp client |
| dhcprd | dhcp relay |
| hatalk | ha protocol module |
| haysnc | ha synchronization module |
| harelay | ha relay module for tcp |
| pptpd | pptp |
| l2tpd | l2tp |
| ipldbd | ipldbd daemon |
| vsd | virtual server daemon |
| acd | aggregate controller daemon |
| src-vis | source visibility daemon |
| pppoed | pppoe daemon |
| ddnscd | ddns client daemon |
| urlfilter | URL filter daemon |
| ntpd | ntp server daemon |
| sshd | ssh daemon |
| tftpd | tftp daemon |
| telnetd | telnet daemon |
| authd | authenticated daemon |
| fssod | fsso daemon |
| quard | quarantine daemon |
| rtmon | ping server |
| radvd | router adv daemon |
| alertemail | alertemail daemon |
| dnsproxy | dns proxy daemon |
| sflowd | sflow protocol daemon |
| nat64d | NAT64 daemon |
| radiusd | radius daemon |
| notifd | notification daemon = carrier only |
| gtpgkd | gtp daemon = carrier only |
| mass_mmsd | mass mms daemon, carrier only |
| alarmd | alarm daemon |
| pptpcd | pptp client daemon |
| wpad_client | port access client daemon - atheros wifi |
| wpad | port access entity daemon - prism54 wifi |
| eap_proxy | epa proxy - wpa enterprise wifi |
| modemd | modem daemon |
| dialinsvr | dial-in server daemon |
| cardmgr | pcmcia card manager daemon |
| getty aux | getty aux daemon |
| pppoatmd | ppp over atm daemon |
| adsl_mon | adsl monitor daemon |
| l2tpcd | l2tp client daemon |
| httpclid | http client daemon |
| sessionsync | session sync daemon |
| fgfmd | fortigate/fortimanager communication daemon |
| wccpd | wccp daemon |
| garpd | vip gratuitous arp daemon |
| cw_acd | capwap ac daemon |
| wpad_ac | wpad ac daemon |
| cw_wtpd | capwap wtp daemon |
| cw_stad | capwap sta daemon |
| fortilinkd | fortilinkd |
| cu_acd | cu_acd |
| swctrl_authd | Switch controller authentication daemon |
| vrrpd | vrrp daemon |
| usbmuxd | usbmux daemon |
| fsd | forti-start daemon |
| proxyacceptor | proxyacceptor daemon |
| proxyworker | proxyworker daemons |
| sslacceptor | sslacceptor daemon |
| sslworker | sslworker daemons |
| imd | imd daemons |
| fcnacd | forticlient NAC daemon |
| stpd_name | spanning tree protocol daemon |
| wiredapd | wired ap 802.1x port based auth daemon |
| confsynchbd | conf-sync heartbeat daemon |
| confsyncd | conf-sync daemon |
| poed | poe daemon |
| cbp | cbp daemon |
| nsm | routing FIB update |
| imi | routing related |
| bgpd | bgp |
| ospfd | ospf |
| ospf6d | ospfv3 |
| pim6d | pim multicast v6 |
| pimd | pim multicast |
| pdmd | pim dense monde |
| ripd | rip |
| ripngd | ripv6 |
| netscan | netscan daemon |
| dhcp6s | dhcp6 server |
| dhcp6r | dhcp6 relay |
| dhcp6c | dhcp6 client |
| lted | usb lte daemon - start only if hardware has usb port and not run in vmware |
| newcli | CLI commands execution - ssh, telnet |
| vpd | vpn policy daemon - handle vpn traffic to know to which policy the traffic corresponds |
| rlogd | reliable syslog daemon |
Referenz der Prozesse aus: https://kb.fortinet.com/kb/documentLink.do?externalID=FD40822
Wie finde ich die PID von einem bestimmten Prozess heraus?
Die PID ist die Prozess Nummer (Prozess ID). Um einen Prozess zu stoppen muss diese angegeben werden. Damit man die Prozessnummer(n) herausfindet kann dies mit folgendem Befehl durchgeführt werden:
diagnose sys process pidof [ProzessName]
Wenn ich zum Beispiel die Prozessnummern für httpsd haben möchte gebe ich folgendes ein:
| Konfiguration über die CLI:
|
# diagnose sys process pidof httpsd 127 210 212 214 225 228 248 295 323 326 475 |
Wie kann ich auf der FortiGate einen laufenden Prozess stoppen?
Folgender Befehl kann verwendet werden um einen laufende Prozesse zu stoppen:
diagnose sys kill [Signal] [Prozess-ID]
Beschreibung:
- Signal kann eine beliebige Zahl sein. Es empfiehlt sich die 11 zu nehmen, weil dieses Signal eine Ausgabe an das Crashlog sendet, welches vom Fortinet-Support zur Fehlerbehebung verwendet werden kann.
- Prozess-ID ist die Prozess-ID, die vom Befehl
diagnose sys topaufgelistet wird. (Siehe Artikel Wie kann ich auf einer FortiGate die Prozesse auflisten?)
Mit diagnose sys kill 11 956 wird der Prozess mit der ID 956 gestoppt.
Wie kann ich herausfinden, welcher Prozess auf welchem CPU Core läuft?
]]
| Konfiguration über CLI: |
|
Als Erstes müssen wir wissen, welcher Prozess welche Prozess-Nummer erhalten hat. Dies wird mit dem Befehl # diagnose sys top
Run Time: 0 days, 7 hours and 50 minutes
0U, 0N, 0S, 100I, 0WA, 0HI, 0SI, 0ST; 2012T, 681F
ipshelper 314 S < 0.0 3.9
cmdbsvr 124 S 0.0 3.3
ipsengine 315 S < 0.0 3.0
httpsd 379 S 0.0 3.0
miglogd 144 S 0.0 2.4
pyfcgid 284 S 0.0 2.3
httpsd 209 S 0.0 2.2
httpsd 380 S 0.0 2.0
reportd 163 S 0.0 2.0
httpsd 317 S 0.0 1.8
pyfcgid 286 S 0.0 1.8
forticron 155 S 0.0 1.7
httpsd 656 S 0.0 1.6
cw_acd 180 S 0.0 1.4
httpsd 1338 S 0.0 1.4
miglogd 196 S 0.0 1.4
|
Wir ermitteln jetzt auf welchem CPU-Kern der Prozess ipsengine läuft. Wir haben herausgefunden, dass die Prozessnummer für ipsengine die 315 ist. Mit dem Befehl diagnose sys process dump [PROZESS_ID] | grep Cpu kann der Kern ermittelt werden:
| Konfiguration über CLI: |
# diagnose sys process dump 315 | grep Cpu Cpus_allowed: 1 <---- 0001 (binär umgerechnet). Cpus_allowed_list: 0 <---- CPU Nummer 0 |
Bei einem zweiten Beispiel wollen wir vom Prozess miglogd wissen, auf welchem Kern dieser läuft. Hier ist die ProzessID die 196
| Konfiguration über CLI: |
# diagnose sys process dump 196 | grep Cpu Cpus_allowed: 2 <----- 0010 (binär umgerechnet). Cpus_allowed_list: 1 <----- CPU Nummer 1 |
|
|
Hier ist ein Link um dezimale Zahlen in binäre Zahlen umzurechnen: |
System
Wie generiere ich einen TAC Report für den technischen Support von Fortinet?
Damit der technische Support von Fortinet effizient arbeiten kann, ist es von grossem Nutzen bei einem Störungsfall den TAC Report beim Supportticket hochzuladen. In den meisten Fällen wird dieser Report sowieso eingefordert und man gewinnt Zeit indem man diesen Report gleich von Anfang an mitsendet. Wen man den Report ausführt wird ein vordefiniertes Skript eine Reihe von Diagnose-Befehlen durchführen. Diese ermöglichen eine Momentaufnahme des aktuellen Zustands der FortiGate festzuhalten. Diese Ausgaben der Befehle können dann in eine Log Datei geschrieben, und so dem technischen Support von Fortinet zur Verfügung gestellt werden.
Im TAC Report werden folgende Daten generiert und abgelegt:
- Seriennummer des Gerätes
- Benutzte Firmwareversion
- Status der FortiGuard-Updates
- Memorie und CPU Auslastung
- Globale Konfiguration
- Hardware Features
- Interface Fehler
- Traffic Statistiken
- HA-Diagnostik
- Prozess Crash Logs
Der TAC Report kann folgendermassen generiert und heruntergeladen werden:
| Konfiguration über das WebGui:
|
|
| Konfiguration über die CLI:
|
# execute tac report |
Datei:HowTo FortiOS TAC-Report.pdf
Zertifikate
Wie kann unter Windows 10 ein SelfSign Zertifikat erstellt werden, welches auf die Firewall geladen werden kann?
Unter Windows 10 kann ein entsprechendes Zertifikat mit Powershell erstellt werden. Folgende Parameter werden dazu benötigt:
PS C:\temp> New-SelfSignedCertificate -CertStoreLocation Cert:\LocalMachine\My -DnsName "meineseite.local" -FriendlyName "MySiteCert" -NotAfter (Get-Date).AddYears(10) PSParentPath: Microsoft.PowerShell.Security\Certificate::LocalMachine\My Thumbprint Subject ---------- ------- 9598EC7B469ADFE74474CD75C5FEFCBF8B7EB478 CN=meineseite.local
Um dieses Zertifikat anschliessend auch als File vom Windows Zertifikatsspeicher in ein passwortgeschütztes *.pfx-File exportieren zu können, muss erst das Passwort in einer Variablen abgelegt werden, bevor dann mittels CMDlet das Zertifikat exportiert werden kann:
PS C:\temp> $CertPwd = ConvertTo-SecureString -String "test" -Force -AsPlainText PS C:\temp> Export-PfxCertificate -cert cert:\localMachine\my\9598EC7B469ADFE74474CD75C5FEFCBF8B7EB478 -FilePath C:\temp\test.pfx -Password $CertPwd Verzeichnis: C:\temp Mode LastWriteTime Length Name ---- ------------- ------ ---- -a---- 27.06.2018 16:43 2749 test.pfx
Das Zertifikat wird anschliessend wie folgt importiert:
Wie kann unter Windows 10 ein CA erstellt werden, welches auf die Firewall geladen werden kann?
- Herunterladen des Tools XCA Datei:Setup xca-1.4.1.zip
- Installieren von XCA auf einem Windows PC
- Generieren einer CA mit XCA gemäss folgender Anleitung: Datei:Xca howto.pdf (Quelle: barracuda.com)
- Exportieren der CA im *.pem Format
- Importieren des Zertifikates auf der Fortigate Firewall unter System > Certificates > Import > CA Certificate > Type=File
Interface
Was bedeutet die Funktion "Role" innerhalb einer Interface Konfiguration?
Wenn man ab dem FortiOS 5.4 im Interface die verschiedenen Konfigurationspositionen näher anschaut, fällt einem die Position "Role" auf:
| Konfiguration über das WebGui:
|
|
| Konfiguration über die CLI:
|
# config system interface # edit [Name des entsprechenden Interface zB "internal"] # set role [lan | wan | dmz | undefined] # end |
Nun stellt sich die Frage wobei es sich bei diesem Konfigurationspunkt handelt. Nach Auskunft von Fortinet handelt es sich hierbei um ein neues Feature unter FortiOS 5.4 das Fehlkonfigurationen auf früheren FortiOS verhindern soll. Dies wiederum bedeutet: Durch das hinzufügen einer bestimmten "Role" zu einem Interface stehen diesem bestimmte Konfigurationen nicht mehr zur Verfügung. Dadurch wird verhindert das zBsp auf einem "DMZ" Interface eine DHCP Server Konfiguration durchgeführt wird. Dabei ist wichtig zu wissen welche Konfigurationspunkte durch welche "Role" auf einem Interface entfernt werden. Nachfolgend eine Übersicht der zur Verfügung stehenden "Role" für ein Interface:
| Rolen Typen |
|
Undefined Role: Alle Optionen im WebGui sind sichtbar und können konfiguriert werden. WAN Role:
LAN Role
DMZ Role
|
Wir empfehlen grundsätzlich diese "Role" nicht zu benutzen und für ein Interface die Einstellung "undefined" zu benutzen wodurch alle Funktionen resp. Konfigurationen für ein Interface zur Verfügung stehen. Nach Auskunft von Fortinet sind diese "Role" im FortiOS nicht konfigurierbar dh. diese sind "hardcoded" implementiert und können nicht verändert werden. Es stehen auf der CLI keine Befehle zur Verfügung um diese "Role" zu verändern oder abzufragen um allenfalls herauszufinden zu können welche Funktionen für eine bestimmte "Role" entfernt wurde oder zur Verfügung steht.
Wie kann ich die Interface Statistik auf einer FortiGate anschauen?
Um die Interface Statistik anzuschauen kann über die CLI folgender Befehl eingegeben werden:
| Konfiguration über die CLI:
|
# get hardware nic <INTERFACE_NAME> Beispiel: # get hardware nic port1 Description :FortiASIC NP6 Adapter Driver Name :FortiASIC Unified NPU Driver Name :np6_0 PCI Slot :0000:01:00.0 irq :16 Board :FGT300d SN :FGT************ Major ID :5 Minor ID :0 lif id :0 lif oid :130 netdev oid :130 netdev flags :1303 Current_HWaddr 00:09:0f:09:00:02 Permanent_HWaddr 90:6c:ac:17:b0:ac phy name :port1 bank_id :1 phy_addr :0x00 lane :0 flags :220 sw_port :0 sw_np_port :0 vid_phy[6] :[0x02][0x00][0x00][0x00][0x00][0x00] vid_fwd[6] :[0x00][0x00][0x00][0x00][0x00][0x00] oid_fwd[6] :[0x00][0x00][0x00][0x00][0x00][0x00] ========== Link Status ========== Admin :up netdev status :up autonego_setting:1 link_setting :1 link_speed :1000 link_duplex :0 Speed :1000 Duplex :Full link_status :Up rx_link_status :1 int_phy_link :0 local_fault :0 local_warning :0 remote_fault :0 ============ Counters =========== Rx_CRC_Errors :0 Rx_Frame_Too_Longs:0 rx_undersize :0 Rx Pkts :3130045 Rx Bytes :752876757 Tx Pkts :3430304 Tx Bytes :2363052814 Host Rx Pkts :3130032 Host Rx Bytes :691819956 Host Rx dropped :0 Host Tx Pkts :3430304 Host Tx Bytes :2348345744 Host Tx dropped :0 |
| Konfiguration über die CLI:
|
# fnsysctl ifconfig <INTERFACE_NAME> Beispiel: # fnsysctl ifconfig port1
port1 Link encap:Ethernet HWaddr 00:09:0F:09:00:02
inet addr:198.18.0.1 Bcast:198.18.0.31 Mask:255.255.255.224
UP BROADCAST RUNNING PROMISC ALLMULTI MULTICAST MTU:1500 Metric:1
RX packets:3131156 errors:0 dropped:0 overruns:0 frame:0
TX packets:3431342 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:753144031 (718.3 MB) TX bytes:2363678516 (2.2 GB)
|
Wie konfiguriere ich ein VLAN-Interface auf der FortiGate?
Ein VLAN-Interface kann auf der FortiGate relativ einfach konfiguriert werden.
| Konfiguration über das WebGui:
|
|
Über das Menu Network -> Interfaces ->
Die VLAN Interfaces sieht man beim physikalischen Interface wenn man auf das + klickt. |
| Konfiguration über die CLI:
|
config system interface
edit "vl_1500_userlan"
set vdom "root"
set ip 172.16.18.2 255.255.255.0
set alias "vl1500-ulan_frontend"
set device-identification enable
set role lan
set interface "internal7"
set vlanid 1500
next
end
|
Wie kann ich auf einem VLAN Interface eine sekundäre IP Adresse konfigurieren?
Bei einem VLAN Interface kann die sekundäre IP Adresse nicht einfach mit dem Befehl config secondaryip konfiguriert werden. Bevor man diesen Befehl nutzen kann, muss noch das entsprechende Feature auf dem Interface aktiviert werden. Dies wird mit dem Befehl secondary-IP {enable | disable} erreicht.
| Konfiguration über die CLI:
|
config system interface edit int_vl1200 set secondary-IP enable set interface "internal" set vlanid 1200 config secondaryip edit 1 set ip 172.16.17.1 255.255.255.0 next end next end |
| Konfiguration über das WebGui:
|
|
Um auf dem WebGui die sekundäre IP zu konfigurieren muss einmal das Feature aktiviert worden sein. Danach ist es möglich auf allen Interfaces diese Option über das WebGui zu benutzen.
|
Wie kann ich den MTU Wert auf einem Interface anpassen?
]]
Der Maximum Transmission Unit (MTU) Wert definiert die grösste, hardwareabhängige Paketgrösse gemessen in Byte, welche ein Netzwerk übertragen kann. Wenn ein Paket grösser als der MTU Wert ist, werden die Pakete vom Sender aus in kleinere Pakete aufgeteilt. Der Standard MTU Wert auf einem FortiGate Interface ist 1500. Es kann vorkommen, dass man diesen Wert auf dem Interface anpassen muss, weil gewisse Paket Grössen nicht mehr durch kommen. Dieses Phänomen tritt häufig bei DSL Verbindungen auf, über welche noch ein IPSec VPN Tunnel gehen. Dies zeigt sich dann anhand des Phänomens, dass der Tunnel up ist, die ICMP Pakete durch gehen (ich kriege eine Antwort über den PING vom Remote System), aber die Daten selber nicht durch den Tunnel gehen.
Die MTU-Grösse der von der FortiGate übertragenen Pakete kann angepasst werden um die Netzwerkleistung zu verbessern. Idealerweise sollte die MTU der Pakete mit der kleinsten MTU aller Netzwerke zwischen der FortiGate und dem Ziel identisch sein. Falls die von der FortiGate gesendeten Pakete grösser sind als die kleinste MTU, werden diese zerlegt / fragmentiert, was die Übertragung verlangsamt. Man kann leicht experimentieren, indem die MTU verringert wird um eine MTU Grösse für eine optimale Netzwerkleistung zu finden.
- 68 bis 1500 Bytes für den statischen Modus
- 576 bis 1500 Bytes für den DHCP-Modus
- 576 bis 1492 Bytes für den PPPoE-Modus
Grössere Frame-Grössen (falls vom FortiGate-Modell unterstützt), bis zu 9216 Byte für NP2-, NP4- und NP6-beschleunigte Interfaces sind möglich. Diese Option ist nur für physische Interfaces verfügbar. Virtuelle Interface (vlan) welche einem physischen Interface zugeordnet sind, erben die MTU-Grösse des physischen Interfaces.
Die Interfaces gewisser FortiGate-Modelle unterstützen Frames, welche grösser als die herkömmlichen 1500 Byte sind. Jumbo-Frames werden bei FortiGate-Modellen, welche ab SOC2 (oder höher) oder NP4lite (ausser die FortiGate 30D) und bei Modellen der FortiGate 100D-Serie unterstützt. Wenn grössere Frames über eine Route gesendet werden, müssen alle Netzwerk-Devices auf diesem Weg die Framegrösse unterstützen. Falls dies nicht der Fall ist, werden die grösseren Frames nicht erkannt und dann verworfen.
Wenn man Datentraffic mit der Standardgrösse und grösseren Frames auf demselben Interfaces hat, kann das Routing allein diese nicht auf verschiedene Wege routen, die nur auf der Frame-Grösse basieren. Man kann jedoch VLANs verwenden, um sicherzustellen, dass der Datenverkehr mit grösseren Frames über Netzwerkgeräte geroutet wird, welche die grössere Grösse unterstütz. VLANs erben die MTU-Grösse von dem übergeordneten Interface. Das VLAN muss so konfiguriert werden, dass es beide Enden des Pfads, sowie alle Switches und Router entlang des Weges umfasst.
Die MTU-Paketgrösse kann konfiguriert werden. Wenn man eine MTU-Grösse wählt, welche grösser ist als jene die vom FortiGate-Modell unterstützt wird, kommt eine Fehlermeldung ("Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt"). In dieser Situation soll man versuchen eine kleinere MTU-Grösse zu konfigureren, bis der Wert unterstützt wird und die Pakete nicht mehr fragmentiert werden müssen.
|
|
Eine Änderung des MTU-Wertes kann den Internetzugang für eine kurze Zeit beeinträchtigen, da nach der Anpassung des Wertes ein Reboot der Hardware vorgenommen werden muss. Es wird empfohlen die MTU-Änderung in einem Wartungsfenster vorzunehmen oder den Kunden zu informieren, dass es zu einem Unterbruch kommt! |
MTU Standardwerte: DHCP-Verbindung: 1500 PPPoE-Verbindung: 1492 Wird eine eigene VPN-Verbindung (via IPSec) aufgebaut, so muss nach dem ermitteln der "optimalen" MTU noch -100 gerechnet werden um den für das VPN korrekte MTU-Wert zu erlangen.
Die optimale MTU kann via CLI mit folgendem Befehl ermittelt werden: ping <<Zielhost>> -f -l 1492
Erscheint die Fehlermeldung "Paket müsste fragmentiert werden", ist der Wert noch zu hoch und muss weiter reduziert werden bis der Ping ohne Fehlermeldung durch geht.
Folgendermassen kann ich auf den Interfaces die MTU Werte anpassen:
| Konfiguration über die CLI:
|
config system interface
edit [INTERFACE]
set mtu-override [enable|disable]
set mtu [MTU_WERT]
end
end
Beispiel: config system interface
edit internal1
set mtu-ovveride enable
set mtu 1492
end
end
|
|
|
Wenn die FortiGate im transparent Modus ist muss noch folgendes beachtet werden: |
Auch interessant:
- Mehr Informationen über die MTU: https://www.msxfaq.de/netzwerk/grundlagen/mtu.htm
- VPN Interface : Wie kann ich auf einem VPN Interface die MTU Werte anpassen?
Wie kann ich auf der FortiGate ein Interface deaktivieren/aktivieren?
Es empfiehlt sich, jene Interfaces, welche auf der FortiGate nicht verwendet werden, administrativ herunter zu fahren und diese zu deaktivieren.
Dies kann via WebGui oder über die CLI vorgenommen werden. Am besten schreibt man einen Kommentar, wann und von wem das Interface deaktiviert wurde um die Transparenz zu erhöhen.
Im WebGui werden Interfaces, welche deaktiviert wurden grau dargestellt.
| Konfiguration über das WebGui:
|
|
Über das Menu Network --> Interfaces --> [Interface auswählen] in die Interface Konfiguration navigieren. Ganz nach unten scrollen, dann kann man im Menupunkt Miscellaneos unter Status die Aktion anwählen:
Im "Comments"-Feld kann ein Kommentar eingefügt werden. In der Gesamtübersicht der Interfaces erkennt man die deaktivierten Interfaces anhand dessen dass diese hellgrau geschrieben sind: |
| Konfiguration über die CLI:
|
config system interface
edit [INTERFACE_NAME]
set status [up|down]
set description "[BESCHREIBUNG]"
next
end
Beispiel: config system interface
edit internal7
set status [up|down]
set description "Administrativ down 26.05.2020 - mru"
next
end
Den Interface Status kann ich folgendermassen überprüfen: config system interface
edit internal7
(internal7) # get | grep status
cli-conn-status : 0
status : down <-- Interface Status
|
Switch Mode
Sniffer Mode / CTAP
Switch Controller
Administrator
Wie richte ich auf der FortiGate ein SSH Login mittels privatem Schlüssel ein?
]]
Damit ich mich als Administrator auf der FortiGate nicht immer mit dem Passwort authentifizieren muss, ist es möglich mich mittels einem privaten Schlüssel zu authentifizieren.
Dafür müssen zwei Schlüssel generiert werden. Zum Einen ein privater, und zum Andern ein öffentlicher Schlüssel. Ein gutes Tool um so ein Schlüsselpaar zu generieren ist der Putty Key Generator. Dieser ist unter folgendem Link abrufbar: https://www.puttygen.com/
Wenn der Puttygenerator gestartet wurde, kann das Paar ganz einfach generiert werden:
| Konfiguration im PuTTy Key Generator:
|
|
Nun muss der Public Key auf die FortiGate impotiert werden.
| Konfiguration über die CLI:
|
# config system admin # edit [Administrator] # set ssh-public-key1 "ssh-rsa [PublicKey Term]" # end nach SSH-RSA muss der öffentliche Schlüssel in einer Linie hereinkopiert werden. ---- BEGIN SSH2 PUBLIC KEY ---- Comment: "rsa-key-20200327" ---- END SSH2 PUBLIC KEY ---- Achtet darauf, dass der Public Key in einer Zeile, welche mit Anführungs-Zeichen beginnt und mit dem Schlusszeichen endet: "ssh-rsa PublicKey in einer Linie" Beispiel: # config system admin # edit admin # set ssh-public-key1 "ssh-rsa AAAAB3NzaC....E2MSyQ==" # end |
Nun muss noch der SSH Client mit dem privaten Key konfiguriert werden. Wir empfehlen hierzu das Tool "PuTTy" (https://www.putty.org/) zu verwenden.
| Konfiguration im PuTTy:
|
Ergebniss: |
| Konfiguration für Linux oder Mac OS X:
|
|
Schlüsselpaar generieren: ssh-keygen -t rsa -b 4096 Unter Linux oder Mac OS X kann man sich folgendermassen auf die FortiGate über SSH verbinden: ssh -i .ssh/key_rsa username@host .ssh/key_rsa' bezieht sich auf den Pfad in welchem der private Schlüssel gespeichert wurde. Beispiel: ssh -i .ssh/key_rsa admin@10.60.60.2 |
Wie kann ich für den Administrator "admin" das Passwort zurücksetzen wenn ich dieses vergessen habe?
Um ein Passwort des standard Administrators "admin" neu zu setzen wenn dies nicht mehr bekannt ist, gelten folgende Voraussetzungen:
- Seriennummer des Devices muss bekannt sein (Rückseite des Gerätes) zBsp FGT60E4613015338
- Das FortiGate Device muss neu gestartet werden (Strom aus/ein)
- Der Zugriff muss lokal über den Konsolen-Port erfolgen (RS-232)
| Konfiguration über die CLI:
|
|
Um das Passwort für den standard Administrator "admin" zurück zu setzen muss ein Zugriff via einen seriellen Console-Port (RS-232) sicher gestellt werden: 8 bits no parity 1 stop bit 9600 baud Flow Control = none |
|
Nach dem man mit der FortiGate über den Konsolen-Port verbunden ist, muss die FortiGate neu gestartet werden. Dies muss über einen Hardware-Reboot (Strom ausschalten, Strom einschalten) geschehen. Wenn auf der CLI die Loging Aufforderung kommt muss man sich relativ schnell mit dem User ‘’’maintainer’’’ und dem Passwort bcpb[Serie Nummer der FortiGate] identifizieren. Es ist darauf zu achten, dass die Serienummer in GROSSBUCHSTABEN geschrieben wird. Tipp: bcpb[SERIENUMMER] in ein Textfile schreiben und kopieren, damit das Passwort mittels copy/ paste eigegeben werden kann. User = maintainer Password = bcpbFGT60E4613015338 Welcome! |
|
Nun kann das Passwort des standard Administrators "admin" neu konfiguriert werden: # config system admin # edit admin # set password [neues Passwort] # end |
Dieser Vorgang wird nach 2 Minuten deaktiviert. Dies bedeutet dass nach einem "power on" innerhalb 2 Minuten eingeloggt werden muss da das Login anhand des Users "maintainer" nach 2 Minuten deaktiviert wird. Dieser Vorgang wird auf jedem Fortinet Device benutzt um das Passwort des standard Administrators "admin" wiederherzustellen. Es gibt keine andere Möglichkeit dieses Passwort via Remote Zugriff, zBsp SSH, wiederherzustellen! Diese Funktion für den User "maintainer" resp. dessen Login kann unter der globalen Konfiguration im FortiOS deaktiviert werden. Wird dies durchgeführt gibt es keine Möglichkeit mehr das Passwort des standard Administrators zurück zu setzen:
Es ist möglich den Maintainer Zugriff für das Gerät zu deaktivieren:
| Konfiguration über die CLI:
|
# config system global # set admin-maintainer [enable | disable] # end |
|
|
Wenn der admin-maintainer deaktiviert wird, gibt es keine Möglichkeit mehr, dass Passwort zu resetten. Auch der technische Support von Fortinet hat keine Möglichkeit mehr, dass Passwort zurückzusetzen! |
Wie kann ich einen Login Disclaimer auf der FortiGate konfigurieren?
Der Loging Disclaimer ist standartmässig auf der FortiGate nicht aktiv. Möchte ich, dass beim einloggen auf die FortiGate eine Warnmeldung erscheint, muss ich dies über die CLI konfigurieren.
Es gibt zwei Varianten:
1. Eine Warnmeldung bevor das Loging-Prompt erscheint (WebGui oder CLI):
| Konfiguration über die CLI:
|
config system global set pre-login-banner [enable | disable] --> enable für einschalten. end Bevor ich jetzt auf das Anmeldefenster komme wird die vordefinierte Warnmeldung angezeigt: Der User muss akzeptieren, dass er auf das Anmeldefenster kommt. |
2. Eine Warnmeldung nachdem ich mich auf die FortiGate eingeloggt habe:
| Konfiguration über die CLI:
|
config system global set post-login-banner [enable | disable] --> enable für einschalten. end Nach dem Einloggen wird dem User eine Warnmeldung angezeigt, bei welcher der User bestätigen muss. |
Die Templates können auch nach eigenen Wünschen angepasst werden:
| Konfiguration über das WebGui:
|
|
|
User / Gruppe
Wie konfiguriere ich eine Usergruppe?
| Konfiguration über das WebGui:
|
|
|
| Konfiguration über die CLI:
|
|
Die User können mit folgendem Syntax der Gruppe "USER" "NEXT-USER" .... "END-USER" hinzugefügt werden. config user group
edit "gr-Wartung"
set member "user1" "user2"
next
end
Bei einer Firewall Policy wird die Usergruppe mittels folgendem Befehl config firewall policy
edit <POLICY_ID>
set name "O_Wartung->Internet"
set srcintf "internal"
set dstintf "wan1"
set srcaddr "net-192.168.1.0-24"
set dstaddr "net-0.0.0.0-00"
set action accept
set schedule "always"
set service "HTTP" "HTTPS"
set logtraffic all
set groups "gr-Wartung"
set nat enable
next
end
|
Im Monitor können authentifizierte User angeschaut werden:
| Konfiguration über das WebGui:
|
|
Über den Menupunkt Monitor -> Firewall User Monitor können die momentan eingeloggten User eingesehen werden: Um einen User zu deauthorizieren, muss der entsprechende User mittels Rechtsklick angewählt werden und dann der Button Deauthenticate selektiert werden. |
Wie eröffne ich einen User für die Zweifaktor Authentifizierung über SMS?
Damit es eine optimale Sicherheit bei der User-Authentifizierung gibt, ist die Möglichkeit einen Token anzubinden eine sehr gute Lösung. Dabei gibt der User sein Passwort ein und bekommt noch einen zweiten Faktor zugesendet. Es gibt dabei die Variante, welche dem User eine Textnachricht auf sein Mobile Gerät sendet. Der User muss diesen Zusatz mit eingeben um eine erfolgreiche Authentifizierung zu erlangen. Auf der FortiGate wird die SMS Authentifizierung beim User konfiguriert. Wir haben die Möglichkeit den kostenpflichtigen FortiGuard SMS Dienst von Fortinet zu nutzen.
| Konfiguration über das WebGui:
| ||
Hinweis: Der Parameter set two-factor sms muss über die CLI konfiguriert werden.
Jetzt muss der User bei der entsprechenden Regel in die Source eingefügt werden.
| ||
| Konfiguration über die CLI:
| ||
|
Den User konfigurieren: config user local
edit "user1"
set type Password
set two-factor sms
set sms-phone "41791234567"
set password "password"
next
end
Bei der Policy muss der User in der Source angegeben werden, damit die Authentifizierung gezogen wird. In dieser Regel sind "ANY Services" konfiguriert. Für einen produktiven und sicheren Betrieb empfiehlt sich nur die Services freizuschalten, welche auch benötigt werden. Weiter empfiehlt es sich das entsprechende UTM Features zu aktivieren um sich optimal abzusichern. config firewall policy
edit <POLICY-ID>
set name "O_UserAuthent->Internet"
set srcintf "internal"
set dstintf "wan1"
set srcaddr "net-192.168.1.0-24"
set dstaddr "net-0.0.0.0-00"
set action accept
set schedule "always"
set service "ALL"
set logtraffic all
set users "user1"
set nat enable
next
end
|
| Resultat:
|
|
Wenn wir jetzt eine Anfrage über den Webbrowser in das Internet vornehmen wird ein Loging Fenster im Browser erscheinen: Nachdem sich der user1 mit seinem Passwort authentifiziert hat, kommt noch die SMS abfrage. Der User hat jetzt 60 Sekunden Zeit den SMS-Code einzutippen. Nach dieser Zeit ist der ausgelieferte Code erneut ungültig. |
Firewall Regeln
Was ist eine Local-In Policy?
Policies steuern den Traffic durch die FortiGate. Die FortiGate stellt auch die Möglichkeit, den internen Traffic (Management-Traffic) zu kontrollieren.
Jedes Interface enthält eine Konfiguration für den erlaubten Zugriff, um den Managementzugriff für bestimmte Protokolle zu ermöglichen. Lokale Firewall Regeln werden automatisch eingerichtet, um den Zugriff für alle Benutzer zu ermöglichen. Lokale Firewall-Regeln gehen noch einen Schritt weiter, indem sie den Benutzerzugriff aktivieren oder einschränken.
Man kann lokale Firewall-Regeln für den administrativen Zugriff, das Routing, die zentrale Verwaltung durch den FortiManager, oder weitere Zwecke benutzen:
- SNMP
- Syslog
- Alert Email
- FortiManager Remote IP
- FortiGuard Services
- FortiAnalyzer Logtransfer
- NTP
- DNS
- AutorisierungS Anfragen wie RADIUS
- FSSO
| Konfiguration über das WebGui:
|
|
Local-In-Firewall Regeln können nur in der CLI erstellt oder bearbeitet werden. Die vorhandenen Local-In-Policies werden im WebGui angezeigt. Damit man die automatisch angelegten LocalIn Firewallregeln sieht muss man das Feature freischalten:
|
| Konfiguration über die CLI: |
# config system settings # set gui-local-in-policy enable # end |
Um das ganze zu veranschaulichen ein kleines Beispiel:
| Konfiguration über das WebGui:
|
|
Wir konfigurieren auf dem Interface (internal) die Services PING(icmp 8), HTTPS (tcp443), SSH(tcp22) und FMG-Access(tcp541). Sobald wir diese Management Methoden konfiguriert haben und die Interface Konfiguration verlassen, sehen wir, dass in den LocalIn auf dem Interface internal die entsprechenden Ports geöffnet sind: Der HTTPS wird als TCP4443 (Admin Port) im Tap Authentication angezeigt und ist auf diesem Screenshot nicht ersichtlich! |
|
|
Die manuell konfigurierten Local-In Firewall Regeln werden im WebGui nicht angezeigt! |
Wie kann ich eine manuelle Local-In Policy konfigurieren?
Manuell angelegte Local In Policy sind von der Hyrarchie her prioritär der automatisch angelegten Local In Policies. Es ist jedoch nicht möglich, die automatischen Local In Policies zu manipulieren. Durch eine manuelle Local In Policy kann sie aber übersteuert werden.
Manuelle Local In Policies können nur über die CLI konfiguriert werden. Dies funktioniert wie folgt:
| Konfiguration über die CLI:
|
# config firewall [local-in-policy | local-in-policy6] # edit [Policy ID definieren] # set intf [Source Interface] # set srcaddr [Source IP Adresse] # set dstaddr [Destinations IP Adresse] # set action [accept | deny] # set service [Service Name] # set schedule [Gültigkeit der Policy] # set comments "[Fakultativer Kommentar]" # end Falls ich das HA-Management Interface als dediziertes Management Interface benutzen will, muss ich dies in der entsprechenden Local-In Policy mit dem Befehl |
Es ist darauf zu achten, dass die Objekte welche benutzt werden, im Vorfeld konfiguriert worden sind (Beispiel Source und Destinations Netze / Host)
In diesem Beispiel soll der SMB Traffic vom Interface internal7 mit dem Source Netz 10.10.250.0/24 auf sämtliche Netze blockiert werden:
| Konfiguration über die CLI:
|
# config firewall local-in-policy # edit 1 # set intf internal7 # set srcaddr net-10.10.250.0-24 # set dstaddr all # set action deny # set service SMB # set schedule alsways # set comments "Block SMB from internal 7" # end |
Um die Local In Policy zu deaktivieren, oder wieder zu aktivieren muss dies in der Policy selber konfiguriert werden:
Die Local-In Policy aktiviert man mit: set status enable
Die Local-In Policy deaktiviert man mit:set status disable
| Konfiguration über die CLI:
|
# config firewall local-in-Policy # edit [Policy_ID] # set status [enable | disable] -> aktivieren oder deaktivieren # end |
|
|
Die manuell konfigurierten Local-In Firewall Regeln werden im WebGui nicht angezeigt! |
Policy Rule
Session
Was für Informationen werden in der Session Liste angezeigt?
Mit dem Befehl diagnose sys session list werden auf der FortiGate alle Session, inklusive den dazugehörigen Informationen angezeigt.
Im "output" ist jede einzelne aktive "Session" mit deren Details aufgeführt. Als Beispiel nachfolgender Output einer Session:
Im Output wird jede aktive Session mit den dazugehörigen Details angezeigt.
Beispiel:
session info: proto=6 proto_state=02 duration=11 expire=21 timeout=3600 flags=00000000 sockflag=00000000 sockport=0 av_idx=0 use=3 origin-shaper= reply-shaper= per_ip_shaper= ha_id=0 policy_dir=0 tunnel=/ state=local nds statistic(bytes/packets/allow_err): org=120/2/0 reply=176/2/1 tuples=2 orgin->sink: org out->post, reply pre->in dev=0->7/7->0 gwy=0.0.0.0/0.0.0.0 hook=out dir=org act=noop 198.18.0.1:21164->198.18.0.90:514(0.0.0.0:0) hook=in dir=reply act=noop 198.18.0.90:514->198.18.0.1:21164(0.0.0.0:0) pos/(before,after) 0/(0,0), 0/(0,0) misc=0 policy_id=0 auth_info=0 chk_client_info=0 vd=0 serial=002606e7 tos=ff/ff ips_view=0 app_list=0 app=0 dd_type=0 dd_mode=0 npu_state=00000000
Die Bedeutung der vielen Positionen wird in der folgenden Tabelle erklärt:
|
Parameter |
Beschreibung | ||||||||||||||||||||||||||
|
proto=6 |
Gibt an um welches Protokoll es sich handelt, zBsp 6 = TCP. Weitere Informationen zu den Protokoll-Nummern siehe auch nachfolgender Artikel: | ||||||||||||||||||||||||||
|
proto_state=02 |
Die erste Stelle des "proto_state" gibt an ob diese Session Clientseitig eine "proxy_based" Inspection ist. Wenn es sich um keine "proxy_based" Inspection handelt wird eine "0" gesetzt. Unterschied Proxy und Flow Inspektion Die zweite Stelle gibt Server Seitig den "state" an. (in unserem Beispiel "2")
Proto_state Feld für TCP Weil eine FortiGate eine "stateful firewall" ist überwacht das FortiOS ebenfalls die "reply session". Aus diesem Grund verfügt der "proto_state=OR" dh. Orginal "direction" und Reply "direction":
Proto_state Feld für SCTP Ab FortiOS 4.2 unterstützt ein FortiGate Device resp. FortiOS ebenfalls "stateful firewalling" für SCTP:
Proto_state Feld für UDP Obwohl UDP ein "sessionless" Protokoll darstellt überwacht ein FortiOS für UDP 2 Stati: State Value UDP Reply not seen 0 UDP Reply seen 1 Proto_state Feld für ICMP (proto 1) Für ICMP existiert kein Status und ein FortiOS zeigt für ICMP immer "proto_state=00" | ||||||||||||||||||||||||||
|
expire=21 |
Diese Position gibt an wie lange die Session noch gültig ist bis diese gelöscht wird, resp. abgelaufen ist (TTL = time to live). | ||||||||||||||||||||||||||
|
origin-shaper= |
Gibt an ob ein Traffic Shaper benutzt wird. Wenn ein Traffic Shaper benutzt wird werden Informationen zur Priorität und Bandbreite ausgegeben. Beispiel: origin-shaper=OutShapper prio=2 guarantee 12800Bps max 128000Bps traffic 92Bps reply-shaper=InShaper prio=4 guarantee 2560Bps max 25600Bps traffic 125Bps per_ip_shaper=PerIPShaper | ||||||||||||||||||||||||||
|
state=may dirty none app ntf |
Der "state" indiziert die "session flags". Dazu nachfolgende Liste der meistgebrauchten "session flags":
Grundsätzlich wird jedes "erste" Packet über die Firewall Policy kontrolliert. Wenn dieses Packet über die Firewall Policy die "Erlaubnis" erhält wird eine "session" erstellt, welche als "may_dirty" (flag)bezeichnet wird. Wenn eine Änderung in der Firewall Policy durchgeführt wird, so werden "alle" existierenden "sessions" von "may_dirty" auf "dirty" gesetzt. Dadurch werden sämtliche Packete ab diesem Zeitpunkt nicht mehr über den NPU gesendet sondern zum CPU. Der CPU kontrolliert abermals das Packet in der Firewall Policy und wenn dieses zugelassen wird, werden diese "sessions" auf "may_dirty" gesetzt. Wenn dieses Packet in der Firewall Policy nicht erlaubt wird werden diese Packete verworfen und mit einem Flag "block" versehen. Danach verbleibt die "session" im Memory bis diese den TTL resp. "expire" erreicht. So kann die FortiGate über die "flags" "dirty" und/oder "may_dirty" erkennen/evaluieren ob nach einer Modifikation der Firewall Policy diese weiterhin erlaubt werden (may_dirty) resp. die entsprechende "session" geblockt werden (block). | ||||||||||||||||||||||||||
|
policy_id=0 |
Gibt an welche Firewall Policy-ID benutzt wurde. Die Firewall Policy-ID 0 indiziert eine "Local-In Policy". | ||||||||||||||||||||||||||
|
statistic |
Steht für den Packet Counter welcher auch über die Firewall Policy der FortiGate ersichtlich ist. statistic (bytes/packets/err): org=3408/38/0 reply=3888/31/0 tuples=2 | ||||||||||||||||||||||||||
|
hook=out dir=org |
Gibt an wie die Packete für "out" und "in" verarbeiet werden dh., wenn zBsp NAT (Network Address Translation) benutzt wird, so werden die Positionen "act=snat" sowie "act=dnat" aufgeführt. Aus den nachfolgenden Informationen kann eruiert werden wie NAT durchgeführt wurde. Nachfolgend ein Beispiel mit NAT: hook=post dir=org act=snat 100.1.10:50194 -> 216.58.216.110:80(10.200.1.1:50194) hook=pre dir=reply act=dnat 216.58.216.110:80 -> 10.200.1.1:50194(10.0.1.10:50194) | ||||||||||||||||||||||||||
|
npu_state=00000000 |
Zeigt ob eine Session über "hardware acceleration" beschleunigt wurde. Wenn dies der Fall ist resp. möglich wäre, wird "npu info:" aufgeführt mit den entsprechenden "counters" für die "hardware acceleration" aus denen man entnehmen kann ob die Session über die Hardware-Beschleunigung abgearbeitet wurde. Beispiel: npu info: flag=0x00/0x00, offload=0/0, ips_offload=0/0, epid=0/0, ipid=0/0, vlan=0/0 | ||||||||||||||||||||||||||
|
no_ofld_reason |
Zeigt den Grund wieso eine Session nicht über "hardware acceleration" beschleunigt wird. Beispiel: no_ofld_reason: redir-to-av redir-to-ips non-npu-intf | ||||||||||||||||||||||||||
|
user= |
Wenn eine Session für eine Verbindung im Zusammenhang mit Authentifizierung erstellt wird, so wird der "user=" erstellt und in der Gruppenzugehörigkeit "group=" das "authed" Flag gesetzt |
Referenz: http://kb.fortinet.com/kb/documentLink.do?externalID=FD30042
Was bedeutet das Flag dirty in der Session Liste?
Wenn die FortiGate das erste Paket für eine neue Session (Beispielsweise ein SYN-Paket) empfängt, bewertet das Gerät, ob der Datentraffic auf der Grundlage der Firewalregeln zugelassen oder nicht zugelassen werden soll. Solange es keine Änderungen an den Firewalregeln und andere Bedingungen gibt, wird diese Bewertung nur für das erste Paket der Session durchgeführt.
Wenn der Verkehr durch eine Firewallregel zugelassen wird, erstellt die FortiGate eine Session und kennzeichnet diese als may_dirty. Wird nachher eine Firewalregeln oder eine Bedingung geändert welche eine Zustandsänderung auslöst, werden alle bestehenden Sessionen mit dem may_dirty-Flag als dirty gekennzeichnet.
Dies signalisiert der FortiGate, dass das nächste Paket der Session neu bewertet werden muss. Wenn die Session immer noch erlaubt/gültig ist und der zu erlaubenden Firewallregel entspricht, wird das Dirty-Flag entfernt und das Flag may_dirty beibehalten.
Wenn die Session blockiert wird, wird sie als blockiert gekennzeichnet und verbleibt in der Sessionstabelle, bis diese Session abläuft. Jedes Paket, das einer Session mit dem Block-Flag entspricht, wird gelöscht.
Nachfolgend sind die Bedingungen aufgeführt, die dazu führen, daß eine Session als 'dirty' markiert wird, wenn:
- Jegliche Änderungen an einer Firewallregel.
- Änderungen am Routing.
- Sämtliche netzwerkbezogenen Konfigurationsänderungen.
Wie kann ich die Session Timer auf der FortiGate anpassen um System Ressourcen einzusparen?
Jeder Traffic, welcher durch die FortiGate fliesst wird einer Firewall Session zugeordnet. Diese Session wird auf der FortiGate erstellt und gepflegt. Je weniger Sessions die FortiGate verwalten muss, desto weniger CPU Ressourcen werden für die Behandlung der Sessions benötigt. Es gibt verschiedene Möglichkeiten die Anzahl an gleichzeitigen Sessions zu reduzieren:
Wenn der Trafficflow gestoppt wird, bleibt die dazugehörige Session in der FortiGate bis ein bestimmter Timer abläuft. Dieses Verhalten gilt für TCP und UDP Sessions (es sind verschiedene Timer daran beteiligt). Die Reduzierung des Timers würde helfen, die Session früher wieder loszuwerden. TCP gebundene Session im half-open, half-close, oder in etablierte Sessions können also früher wieder freigegeben werden.
Dies kann man global wie folgt konfigurieren:
| Konfiguration über die CLI:
|
config system global set tcp-halfclose-timer 30 [ default 120 s ] set tcp-halfopen-timer 30 [ default 60 s ] set tcp-timewait-timer 0 [ default 120 s ] set udp-idle-timer 60 [ default 120 s ] end config system session-ttl set default 300 [ default 5000 ] end |
Es gibt Protokolle welche eher viele Session generieren, da sie auf kurzen Transaktionen basieren. Zum Beispiel DNS ist ein solches Protokoll. In diesem Fall wird empfohlen den Timer für das Protokoll auf einen geeigneten, aber kurzen Wert zu ändern.
| Konfiguration über die CLI:
|
config port edit 0 set protocol 17 set timeout 10 set end-port 53 set start-port 53 end end |
Inspection Modes
Was genau bedeuten die beiden Inspektionsmodi auf der FortiGate? (Proxy vs. Flow)
Jede Fortigate Firewall hat zwei mögliche Betriebsmodi, mit welchen der Datenverkehr inspiziert werden kann:
| Flow-Based | Proxy-Based | |
| Beschreibung |
Prüft den Datenverkehr on-the-flow. Hier wird hauptsächlich Flow-Based-Pattern-Matching verwendet, um Sicherheitsbedrohungen innerhalb des Datenflusses zu identifizieren. Es besteht eine Session |
Puffert den Datenverkehr und überprüft diesen anhand der Informationen aus den vollständigen Paketen. Die Entscheidung über das weitere Vorgehen mit einem Datenstrom wird somit immer anhand der vollständigen Datenpakete vorgenommen. In diesem Betriebsmodus schreibt die Firewall die Paketheader vor dem weiterleiten neu. Es gibt zwei Session:
|
| Schema |
|
|
| Vor/Nachteile |
+ Der Datenverkehr wird ohne Verzögerung ausgeliefert |
+ Entscheidungen im Proxy-Mode fallen detaillierter aus |
Eine bewusste Konfikguration zwischen Flow- und Proxy-Modus ist hilfreich, wenn sichergestellt werden soll, dass ausschliesslich der Flow-Inspektionsmodus verwendet werden soll. Die konkreten Funktionsunterschiede zwischen dem Proxy- und Flowbased Inspectionmode können der Fortinet-Hilfe entnommen werden:
Wie kann der Inspection Mode einer FortiGate bis FortiOS 6.0 geändert werden?
Ab FortiOS 6.0 wird der Inspection Mode pro Firewall oder auf einer mit VDOMs konfigurierten Firewall pro VDOM global angepasst.
Im GUI ist diese Konfiguration unter System > Settings > Inspection Mode zu finden.
In der CLI kann dieser Konfigurationspunkt wie folgt angepasst werden:
fg-lab # config system settings fg-lab (settings) # show config system settings set inspection-mode flow ...
Das Überschreiben dieser globalen Einstellung von Flow nach Proxy führt dazu, dass in jedem Security Profile auf der gesamten Appliance/VDOM der Inspection Mode ebenfalls auf die hier ausgeführte Einstellung umgestellt wird. Das überschreiben dieser Option von Proxy nach Flow führt jedoch nicht dazu, dass diese Einstellung in jedem Security Profil überschrieben wird.
Wie kann der Inspection Mode einer FortiGate ab FortiOS 6.2 geändert werden?
]]
Im Gegensatz zu den Versionen 5.4 - 6.0 wird der Inspektionsmodus nicht mehr als globaler Parameter definiert, sondern über die Policy gesteuert. Die FortiGate wird in der Version 6.2 immer im Flow-Modus sein. Soll mit der proxybasierten Inspektion gearbeitet werden, so muss diese in der jeweiligen Policy konfiguriert werden.
Proxymodus
| Konfiguration über das WebGui:
|
|
In die entsprechende Policy gehen und dann den Inspektions-Modus auf Proxy einstellen.
|
| Konfiguration über die CLI:
|
config firewall policy edit [Policy-ID] --> Policy ID eingeben zBsp edit 2 set inspection-mode proxy next end |
Flow Modus
| Konfiguration über das WebGui:
|
|
Defaultmässig ist in der Policy der Flow Inspektionsmodus aktiviert. Falls man von Proxy auf Flow zurückstellen will kann dies in der entsprechenden Policy vorgenommen werden.
|
| Konfiguration über die CLI:
|
config firewall policy edit [Policy-ID] --> Policy ID eingeben zBsp edit 2 set inspection-mode flow next end |
Flow Modus - NGFW
Was hingegen noch immer global eingestellt wird ist der NGFW Modus. Standartmässig ist dieser auf Profile-based eingestellt. Dies bedeutet, dass UTM Profile erstellt werden und diese auf den Policies angewendet werden. Der Policy-based Modus bedeutet, dass Applikation und Webfilter direkt in der Policy definiert werden. Dies erfordert dass ein einzelnes SSL/SSH Inspektionsprofil auf allen Policies angewendet wird. Antivirus ist immer Profil basierend, unabhängig welcher NGFW Modus konfiguriert ist.
| Konfiguration über das WebGui:
|
|
Im Menu "Settings" kann der NGFW Modus definiert werden. |
| Konfiguration über die CLI:
|
config system settings set ngfw-mode [profile-based | policy-based] end |
Wie wird auf einer FortiGate ein Datenpaket abgearbeitet (Life of a packet) ?
Dieser Abschnitt beschreibt die Schritte, die ein Paket durchläuft, ab Eintritt auf die FortiGate, bis dies die FortiGate wieder verlässt. Dieses Szenario zeigt alle Schritte, die ein Paket durchläuft, wenn ein FortiGate keine Netzwerkprozessoren (wie zBsp den NP6) enthält.
|
|
Den Hinweis "ingress" sowie "engress" ist folgendermassen zu verstehen: "ingress" umschreibt den Vorgang was mit einem Packet durchgeführt wird wenn es über ein Interface dem FortiOS übermittelt wird (TCP/IP Stack). "Engress" umschreibt was mit einem Packet durchgeführt wird wenn ein Packet durch das FortiOS über ein Interface versendet wird! |
Nach dem ersten Paket überspringen die nachfolgenden Pakete in einer ausgelagerten Routing-Sitzung die UTM/NGFW und Kernel-Prozessoren und werden einfach durch den NP6-Prozessor auf die Egress-Schnittstelle weitergeleitet. Auch Sicherheitsmaßnahmen wie DoS-Richtlinien, ACL etc. werden durch den NP6-Prozessor beschleunigt.
Die vorhergehenden Übersichten zeigen innerhalb "UTM/NGFW" keine Details betreffend "inspection" Mode, resp. wie ein Packet im "proxy-mode" oder im "flow-mode" abgearbeitet wird. Dabei ist zu berücksichtigen, dass nicht jedes UTM Feature zB "Web Application Firewall" im "flow-mode" benutzt werden kann sondern nur im "proxy-mode". Weitere Informationen welches Feature von welchem Inspection Mode unterstützt zeigt nachfolgende Aufstellung:
Nachfolgend eine Uebersicht was innerhalb der "UTM/NGFW" Funktion betreffend dieser zwei zur Verfügung stehenden "inspection" Mode durchgeführt wird:
NAT
Wie funktioniert das Destinations NAT auf einer FortiGate?
VIPs sind DNAT-Objekte. Bei jeder Session, welche mit einem VIP übereinstimmt wird die Destination IP Adresse übersetzt (genattet). Üblicherweise wird eine öffentliche IP Adresse auf eine private IP Adresse zu einem Serverdienst übersetzt. Ein VIP-Objekt wird in der Policy im Destinationsobjekt Feld ausgewählt.
Standardmässig ist der VIP auf statisches NAT konfiguriert. Dies bedeutet, dass für ein- und ausgehende Verbindungen ein one-to-one Mapping gilt. Wenn also eine Policy für ausgehenden Traffic konfiguriert wird, und das VIP-Objekt dann auf dem ausgehenden Interface ausgewählt wird, so wird die IP Adresse genattet. Dieses verhalten kann aber durch die IP-Pool Konfiguration übersteuert werden.
VIPs sollten auf dem externen Facing (Ingress) Interface routfähig sein. Das FortiOS reagiert auf ARP-Anfragen von VIP und IP-Pool Objekten. Dies bedeutet, wenn beim VIP-Objekt das Interface ANY konfiguriert wird, wird entsprechend auf jedem Interface für das VIP-Objekt ein ARP Eintrag angelegt. Dies wiederum kann unter gewissen umständen zu asynchronen Routings führen.
Beispiel
Der User initiert einen Request auf die IP Adresse 198.18.1.2. Auf der FortiGate ist ein VIP-Objekt konfiguriert, welches die Anfragen, welche auf die Adresse 198.18.1.2 kommen auf die IP Adresse 172.16.1.100 nattet. Der Request wird also von der FortiGate auf den Server in der DMZ (172.16.1.100) weitergeleitet. Über die Policies kann noch geregelt werden, welchen Services der Zugriff auf den Zielserver gewährt werden soll (172.16.1.100). Ich empfehle jeweils nur die benötigten Services im VIP-Objekt zu konfigurieren. Der Grund ist, dass gemäss Flow Diagramm zuerst das Destinations-NAT vollzogen wird und erst dann die Firewall Policies abgehandelt werden. Dies bedeutet, wenn ich alle Services im VIP-Objekt konfiguriere, diese potentiell auf das Zielsystem bereits durchgeschalten sind. Wenn man sich bei den Policies "verkonfiguriert" generiert man sozusagen einen "Bypass".
Flow Diagramm:
Wie richte ich ein Destinations NAT mit einem VIP Objekt ein?
| Konfiguration über das WebGui:
|
|
Über das Menu Policy & Objects -> Virtual IPs -> |
|
Wir konfigurieren ein VIP Objekt welches den smtp Port auf die IP Adresse 172.16.1.100 in der DMZ weiterleitet. Dabei wird der Client die IP Adresse 198.18.0.2 ansprechen und wird dann über das VIP Objekt auf 172.16.1.100 genattet.
|
|
Um eine neue Regel zu erstellen geht man über Policy & Objects -> IPv4 Policy ->
|
| Konfiguration über die CLI:
|
|
Konfigurieren des VIP Objektes: # config firewall vip # edit "dnat-198.18.0.2-tcp25" # set comment "Destinations Nat 198.18.0.2-172.16.1.100 TCP25" # set extip 198.18.0.2 # set extintf "wan1" # set portforward enable # set color 21 # set mappedip "172.16.1.100" # set extport 25 # set mappedport 25 # next # end Konfigurieren des IP Adress-Objekt für 0.0.0.0/0: # config firewall address # edit net-all-0.0.0.0-0 # set comment "alle Netze 0.0.0.0" # set color 0 # next # end Konfigurieren der Policy über die CLI: # config firewall policy # edit 1 # set name "I_internet->MailSrv-tcp25" # set srcintf "wan1" # set dstintf "dmz" # set srcaddr "net-all-0.0.0.0-0" # set dstaddr "dnat-198.18.0.2-tcp25" # set action accept # set schedule "always" # set service "SMTP" # set logtraffic all # end |
Wie wird ein DNAT konfiguriert, wenn die Central NAT Table verwendet wird ?
Wenn die Central NAT Table eingesetzt wird, so werden sämtliche NAT Funktionalitäten aus der Firewall Policy verbannt. Somit können in der Firewall Policy auch nicht mehr die üblichen VIP Objekte verwendet werden. Im Falle der aktiven Central NAT Table, wird das NAT über folgende zwei Menüpunkte gesteuert:
- Im Fall von DNAT: Policy & Objects > DNAT & Virtual IPs
- Im Fall von SNAT: Policy & Objects > Central SNAT
Für ein funktionierendes DNAT, kann unter DNAT & Virtual IPs ein gewöhnliches Objekt, analog zu einem VIP Objekt konfiguriert werden. In untenstehendem Beispiel möchten wir gerne den Port 80 TCP vom Internet an einen internen Webserver weiterrouten.
Dieses NAT wird sofort nach seiner Erstellung aktiv. Da auf der Firewall jedoch noch eine Firewallregel fehlt, welche den Traffic hierfür erlauben würde, funktioniert mit lediglich einem NAT noch nichts. Im zweiten Schritt erstellen wir nun die Firewall Regel. Da hier kein VIP Objekt mehr angewählt werden kann, wird als Destination Host die interne IP gewählt. Die DNAT-Konfiguration vom vorherigen Schritt sorgt in diesem Fall für die Transformation der IP - unabhängig von der Firewallregel.
Wieso soll ich ein VIP Objekt auf ein Interface konfigurieren?
Auf der FortiGate Firewall können Adressobjekte und virtuelle IPs (VIPs) mit einem Interface eingerichtet werden. Für Adressobjekte hat dies keine technische Relevanz - die Adressobjekte erscheinen einfach nur dann in der Policy, wenn das entsprechende Interface ausgewählt ist. Bei virtuellen IPs hat diese Einstellung jedoch eine Relevanz dafür, wie Verbindungen genattet werden. Das kann problematisch sein.
In allgemeinen Situationen hat man nur eine ISP-Verbindung, auf der ein Ziel NAT (DNAT) für eingehende Verbindungen eingerichtet werden soll. Das ist kein Problem, man kann das untrust Interface im virtuellen IP-Objekt auswählen. Wenn man zwei ISP-Verbindungen hat, zBsp eine gute (ISP1) und eine günstigere (ISP2), MÜSSEN die Interfaces im virtuellen IP-Objekt ausgewählt werden, wenn man auf eine fix IP-Adresse von ISP1 verweisst. Andernfalls wird diese auf allen ausgehenden Verbindungen verwendet, die dann mit dem ISP2 nicht funktionieren würden.
Fall 1:
Fall 2:
Das folgende Beispiel zeigt ein virtuelles IP-Objekt mit einer statischen IP-Adresse von 80.154.108.233 und einem falsch konfigurierten Interface von "Any". Bei ausgehenden Verbindungen zu ISP1 gibt es keine Probleme (Label 1 auf dem Screenshot). Aber nachdem eine Policyroute eingerichtet wurde, um den http-Verkehr an ISP2 weiterzuleiten, wird die gleiche Source-NAT-IP verwendet, die offensichtlich nicht funktioniert hat (Label 2). Nachdem das Interface im virtuellen IP-Objekt auf "wan1" gesetzt wurde, werden ausgehende Verbindungen zu ISP2 korrekt an das ausgehende Interface genattet, während ausgehende Verbindungen zu ISP1 weiterhin an die virtuelle IP-Adresse genattet werden (Label 3).
Wie kann ich die ARP Antwort auf einer virtuellen IP (VIP) deaktivieren?
Im Normallfall werden auf einer FortiGate erstellte VIP-Objekte auf ARP Anfragen antworten, damit angeschlossene Layer 2 Geräte die MAC-Adresse des Interface mit der virtuellen IP mitgeteilt werden.
| Konfiguration über die CLI:
|
config firewall vip edit [VIP-OBJEKT-NAME] set arp-reply disable end Beispiel: config firewall vip edit dst-nat_198.18.250.2-10.10.20.2-http set arp-reply disable end |
Cluster Mode
Radius
Active Directory / LDAP
Virtual Servers
Wie kann ich herausfinden, welche Cipher Suite die FortiGate unterstützt?
Folgendermassen kann herausgefunden werden, welche Cipher die FortiGate unterstützt:
| Konfiguration über die CLI:
|
# config firewall vip # edit <vip-name> # set type server-load-balance # set server-type https # set ssl-algorithm custom # config ssl-cipher-suites # edit 1 # set cipher ? Es erscheint eine Liste: (hier gekürzt, ganze Liste in der Tabelle unten) # TLS-ECDHE-RSA-WITH-CHACHA20-POLY1305-SHA256 Cipher suite TLS-ECDHE-RSA-WITH-CHACHA20-POLY1305-SHA256. . . . # TLS-RSA-WITH-DES-CBC-SHA Cipher suite TLS-RSA-WITH-DES-CBC-SHA. |
Folgende Cipher sind in der FortiOS Version 6.0.3 unterstützt:
| Cipher | Cipher Suite |
|---|---|
| TLS-ECDHE-RSA-WITH-CHACHA20-POLY1305-SHA256 | Cipher suite TLS-ECDHE-RSA-WITH-CHACHA20-POLY1305-SHA256. |
| TLS-ECDHE-ECDSA-WITH-CHACHA20-POLY1305-SHA256 | Cipher suite TLS-ECDHE-ECDSA-WITH-CHACHA20-POLY1305-SHA256. |
| TLS-DHE-RSA-WITH-CHACHA20-POLY1305-SHA256 | Cipher suite TLS-DHE-RSA-WITH-CHACHA20-POLY1305-SHA256. |
| TLS-DHE-RSA-WITH-AES-128-CBC-SHA | Cipher suite TLS-DHE-RSA-WITH-AES-128-CBC-SHA. |
| TLS-DHE-RSA-WITH-AES-256-CBC-SHA | Cipher suite TLS-DHE-RSA-WITH-AES-256-CBC-SHA. |
| TLS-DHE-RSA-WITH-AES-128-CBC-SHA256 | Cipher suite TLS-DHE-RSA-WITH-AES-128-CBC-SHA256. |
| TLS-DHE-RSA-WITH-AES-128-GCM-SHA256 | Cipher suite TLS-DHE-RSA-WITH-AES-128-GCM-SHA256. |
| TLS-DHE-RSA-WITH-AES-256-CBC-SHA256 | Cipher suite TLS-DHE-RSA-WITH-AES-256-CBC-SHA256. |
| TLS-DHE-RSA-WITH-AES-256-GCM-SHA384 | Cipher suite TLS-DHE-RSA-WITH-AES-256-GCM-SHA384. |
| TLS-DHE-DSS-WITH-AES-128-CBC-SHA | Cipher suite TLS-DHE-DSS-WITH-AES-128-CBC-SHA. |
| TLS-DHE-DSS-WITH-AES-256-CBC-SHA | Cipher suite TLS-DHE-DSS-WITH-AES-256-CBC-SHA. |
| TLS-DHE-DSS-WITH-AES-128-CBC-SHA256 | Cipher suite TLS-DHE-DSS-WITH-AES-128-CBC-SHA256. |
| TLS-DHE-DSS-WITH-AES-128-GCM-SHA256 | Cipher suite TLS-DHE-DSS-WITH-AES-128-GCM-SHA256. |
| TLS-DHE-DSS-WITH-AES-256-CBC-SHA256 | Cipher suite TLS-DHE-DSS-WITH-AES-256-CBC-SHA256. |
| TLS-DHE-DSS-WITH-AES-256-GCM-SHA384 | Cipher suite TLS-DHE-DSS-WITH-AES-256-GCM-SHA384. |
| TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA | Cipher suite TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA. |
| TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA256 | Cipher suite TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA256. |
| TLS-ECDHE-RSA-WITH-AES-128-GCM-SHA256 | Cipher suite TLS-ECDHE-RSA-WITH-AES-128-GCM-SHA256. |
| TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA | Cipher suite TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA. |
| TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA384 | Cipher suite TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA384. |
| TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384 | Cipher suite TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384. |
| TLS-ECDHE-ECDSA-WITH-AES-128-CBC-SHA | Cipher suite TLS-ECDHE-ECDSA-WITH-AES-128-CBC-SHA. |
| TLS-ECDHE-ECDSA-WITH-AES-128-CBC-SHA256 | Cipher suite TLS-ECDHE-ECDSA-WITH-AES-128-CBC-SHA256. |
| TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256 | Cipher suite TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256. |
| TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA384 | Cipher suite TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA384. |
| TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 | Cipher suite TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384. |
| TLS-RSA-WITH-AES-128-CBC-SHA | Cipher suite TLS-RSA-WITH-AES-128-CBC-SHA. |
| TLS-RSA-WITH-AES-256-CBC-SHA | Cipher suite TLS-RSA-WITH-AES-256-CBC-SHA. |
| TLS-RSA-WITH-AES-128-CBC-SHA256 | Cipher suite TLS-RSA-WITH-AES-128-CBC-SHA256. |
| TLS-RSA-WITH-AES-128-GCM-SHA256 | Cipher suite TLS-RSA-WITH-AES-128-GCM-SHA256. |
| TLS-RSA-WITH-AES-256-CBC-SHA256 | Cipher suite TLS-RSA-WITH-AES-256-CBC-SHA256. |
| TLS-RSA-WITH-AES-256-GCM-SHA384 | Cipher suite TLS-RSA-WITH-AES-256-GCM-SHA384. |
| TLS-RSA-WITH-CAMELLIA-128-CBC-SHA | Cipher suite TLS-RSA-WITH-CAMELLIA-128-CBC-SHA. |
| TLS-RSA-WITH-CAMELLIA-256-CBC-SHA | Cipher suite TLS-RSA-WITH-CAMELLIA-256-CBC-SHA. |
| TLS-RSA-WITH-CAMELLIA-128-CBC-SHA256 | Cipher suite TLS-RSA-WITH-CAMELLIA-128-CBC-SHA256. |
| TLS-RSA-WITH-CAMELLIA-256-CBC-SHA256 | Cipher suite TLS-RSA-WITH-CAMELLIA-256-CBC-SHA256. |
| TLS-DHE-RSA-WITH-3DES-EDE-CBC-SHA | Cipher suite TLS-DHE-RSA-WITH-3DES-EDE-CBC-SHA. |
| TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA | Cipher suite TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA. |
| TLS-DHE-DSS-WITH-CAMELLIA-128-CBC-SHA | Cipher suite TLS-DSS-RSA-WITH-CAMELLIA-128-CBC-SHA. |
| TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA | Cipher suite TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA. |
| TLS-DHE-DSS-WITH-CAMELLIA-256-CBC-SHA | Cipher suite TLS-DHE-DSS-WITH-CAMELLIA-256-CBC-SHA. |
| TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA256 | Cipher suite TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA256. |
| TLS-DHE-DSS-WITH-CAMELLIA-128-CBC-SHA256 | Cipher suite TLS-DHE-DSS-WITH-CAMELLIA-128-CBC-SHA256. |
| TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA256 | Cipher suite TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA256. |
| TLS-DHE-DSS-WITH-CAMELLIA-256-CBC-SHA256 | Cipher suite TLS-DHE-DSS-WITH-CAMELLIA-256-CBC-SHA256. |
| TLS-DHE-RSA-WITH-SEED-CBC-SHA | Cipher suite TLS-DHE-RSA-WITH-SEED-CBC-SHA. |
| TLS-DHE-DSS-WITH-SEED-CBC-SHA | Cipher suite TLS-DHE-DSS-WITH-SEED-CBC-SHA. |
| TLS-DHE-RSA-WITH-ARIA-128-CBC-SHA256 | Cipher suite TLS-DHE-RSA-WITH-ARIA-128-CBC-SHA256. |
| TLS-DHE-RSA-WITH-ARIA-256-CBC-SHA384 | Cipher suite TLS-DHE-RSA-WITH-ARIA-256-CBC-SHA384. |
| TLS-DHE-DSS-WITH-ARIA-128-CBC-SHA256 | Cipher suite TLS-DHE-DSS-WITH-ARIA-128-CBC-SHA256. |
| TLS-DHE-DSS-WITH-ARIA-256-CBC-SHA384 | Cipher suite TLS-DHE-DSS-WITH-ARIA-256-CBC-SHA384. |
| TLS-RSA-WITH-SEED-CBC-SHA | Cipher suite TLS-RSA-WITH-SEED-CBC-SHA. |
| TLS-RSA-WITH-ARIA-128-CBC-SHA256 | Cipher suite TLS-RSA-WITH-ARIA-128-CBC-SHA256. |
| TLS-RSA-WITH-ARIA-256-CBC-SHA384 | Cipher suite TLS-RSA-WITH-ARIA-256-CBC-SHA384. |
| TLS-ECDHE-RSA-WITH-ARIA-128-CBC-SHA256 | Cipher suite TLS-ECDHE-RSA-WITH-ARIA-128-CBC-SHA256. |
| TLS-ECDHE-RSA-WITH-ARIA-256-CBC-SHA384 | Cipher suite TLS-ECDHE-RSA-WITH-ARIA-256-CBC-SHA384. |
| TLS-ECDHE-ECDSA-WITH-ARIA-128-CBC-SHA256 | Cipher suite TLS-ECDHE-ECDSA-WITH-ARIA-128-CBC_SHA256. |
| TLS-ECDHE-ECDSA-WITH-ARIA-256-CBC-SHA384 | Cipher suite TLS-ECDHE-ECDSA-WITH-ARIA-256-CBC_SHA384. |
| TLS-ECDHE-RSA-WITH-RC4-128-SHA | Cipher suite TLS-ECDHE-RSA-WITH-RC4-128-SHA. |
| TLS-ECDHE-RSA-WITH-3DES-EDE-CBC-SHA | Cipher suite TLS-ECDHE-RSA-WITH-3DES-EDE-CBC-SHA. |
| TLS-DHE-DSS-WITH-3DES-EDE-CBC-SHA | Cipher suite TLS-DHE-DSS-WITH-3DES-EDE-CBC-SHA. |
| TLS-RSA-WITH-3DES-EDE-CBC-SHA | Cipher suite TLS-RSA-WITH-3DES-EDE-CBC-SHA. |
| TLS-RSA-WITH-RC4-128-MD5 | Cipher suite TLS-RSA-WITH-RC4-128-MD5. |
| TLS-RSA-WITH-RC4-128-SHA | Cipher suite TLS-RSA-WITH-RC4-128-SHA. |
| TLS-DHE-RSA-WITH-DES-CBC-SHA | Cipher suite TLS-DHE-RSA-WITH-DES-CBC-SHA. |
| TLS-DHE-DSS-WITH-DES-CBC-SHA | Cipher suite TLS-DHE-DSS-WITH-DES-CBC-SHA. |
| TLS-RSA-WITH-DES-CBC-SHA | Cipher suite TLS-RSA-WITH-DES-CBC-SHA. |
Load Balancing
SSL-VPN
Was versteht man beim SSL-VPN unter einem Split-Tunnel?
Über die Option Split-Tunneling kann auf dem Client gesteuert werden, wie der Traffic ausserhalb des lokalen Netzwerkes gesteuert wird. Einfach gesagt, wohin geht der Internet-Traffic und der Traffic der Remote-Seite, welche ich erreichen will.
Wenn die Split-Tunnel Option nicht aktiviert ist, bedeutet dies, dass sämtlicher Traffic, welcher nicht im lokalen Netzwerk ist, über den VPN-Tunnel zur FortiGate geht. Dies gewährleistet, dass wenn man mit dem Office verbunden ist, sämtlicher Traffic analysiert und entsprechend verarbeitet werden kann. Der Firewall-Regel können UTM Features hinzugefügt werden, um eine höhere Sicherheit des gesamten Traffics zu gewährleisten. Damit auf dem Client das Internet funktioniert, muss zwingend auf der FortiGate eine Policy für das Internet erstellt werden. Schematisch sieht das so aus:
| Split-Tunnel deaktiviert: |
|
|
Wenn die Split-Tunnel Option eingeschalten ist, wird nur jener Traffic in den VPN-Tunnel gesendet, welcher geroutet wird. So wird der Internet Traffic über die Leitung des Clients direkt abgehandelt und die Netze, welche auf der Remote-Seite sind, werden über den VPN-Tunnel erreicht. Schematisch sieht dies so aus:
| Split-Tunnel aktiviert: |
|
|
Wie kann ich beim SSL-VPN ein Bookmarker konfigurieren, welcher ein Verzeichnis mit dem Username enthält?
Es kann sein, dass ich einen Bookmaker im SSL-VPN zur Verfügung stellen möchte, welcher zum Beispiel auf ein persönliches Laufwerk des Users referenziert. Dies ist möglich, sofern das Verzeichnis gleich heisst wie der Username. Damit dies funktioniert muss ich eine Variable benutzen. Folgendermassen kann ich ein SMB/CIFS Laufwerk erreichen, welches einen Folder besitzt der auf den Username referenziert:
Bookmaker : <IP-Destination>/<verzeichnis>
| Konfiguration über das WebGui:
|
|
|
| Konfiguration über die CLI:
|
# config vpn ssl web portal # edit "full-access" # config bookmark-group # edit "gui-bookmarks" # config bookmarks # edit "%username% mit VPN SSO" # set apptype smb # set folder "192.168.1.2/data/users/%username%" # set sso auto # end # end # end |
|
|
Es ist darauf zu achten, dass die Variable %username% in Kleinbuchstaben geschrieben wird. Weiter ist es wichtig, dass für die Trennung der Verzeichnisse Slash / und nicht Backslash \ verwendet werden. |
Ergebnis:
Vielen Dank an Andi von Fortinet Schweiz für das testen
Wie kann ich beim SSL-VPN ein Bookmarker konfigurieren, dass dieser ein Zielsystem im Internet erreicht?
Wenn ich beim SSL-VPN Webportal Bookmarker konfiguriere, habe ich dich Möglichkeit, ein System in meinem Netz verfügbar zu machen. Jetzt möchte ich ein System über das Portal im Internet erreichen. Wie muss ich da vorgehen?
Damit ich das System im Internet erreiche, brauche ich eine neue Firewall Regel:
Wie muss SSL-VPN Bookmark konfiguriert werden, wenn der Zielserver nur über einen IPSec-Tunnel verfügbar ist?
Vorbemerkungen:
Ziel dieser Anleitung ist, eine Intranet Webseite, welche nur über einen IPSec Tunnel erreichbar sein soll, via ein Bookmark auf einem SSL-VPN Portal auf der Fortigate abzubilden.
Ausgangslage:
| Zielarchitektur | Verwendete Geräte |
|
|
|
Annahmen:
Die folgende Anleitung basiert auf folgenden Voraussetzungen:
- Die Fortigate Firewall ist vollständig konfiguriert, hat Zugriff aufs Internet, LAN -> WAN Kommunikation ist bereits etabliert.
- Der IPSec Tunnel zwischen der Fortigate und dem Drittprodukt, hinter welchem sich der zu publizierende Webserver (in diesem Fall 172.16.1.10) befindet, wurde bereits erfolgreich etabliert, so dass eine Kommunikation zwischen den lokalen Clients (192.168.10.0/24) und den Remote Clients (172.16.1.0/24) möglich ist.
1. Erstellung SSL VPN Portal
Um das SSL VPN Portal zu erstellen, gehe auf der Weboberfläche unter VPN -> SSL-VPN Portals und erstelle mit Create New ein neues SSL VPN Portal:
|
|
Mit einem Klick auf Ok wird dieses Portal abgespeichert. |
2. Konfiguration der SSL VPN Einstellungen
Im nächsten Schritt wird definiert auf welchem Interface und auf welchem Port das User Portal überhaupt erreichbar sein sollen. Wir definieren welche Gruppen und Benutzer auf das Portal Zugriff haben sollen, und wir verknüpfen das in Schritt 1 erstellte Portal mit dem Default Portal. Wähle dazu den Menüpunkt VPN -> SSL-VPN Settings:
|
|
Mit einem Apply werden die gewählten Einstellungen gespeichert. |
Somit haben wir die nötigen Einstellungen für das SSL VPN Portal vorgenommen.
3. Erstellung des IP Pools
Damit nun das SSL VPN Portal in der Lage ist, mit diesem Webserver zu kommunizieren benötigt es eine Firewall Regel, welche dies der Firewall erlaubt. Für diese Firewallregel benötigen wir einen IP Pool, damit die Source IP des Requests der Firewall dementsprechend angepasst wird. Diesen IP-Pool erstellen wir unter Policies & Objects -> IP Pools -> Create new
|
|
Mittels Apply wird abgespeichert. |
4. Firewall Regel
Zum Schluss wird noch die Firewall Regel erstellt, welche benötigt wird, damit eine Kommunikation zwischen dem Portal und dem Webserver erlaubt wird: Policy & Objects -> IPv4 Policy -> Create new
|
|
Mittels OK wird die Firewall Regel gespeichert. |
Ergebnis
Ein Berechtigter Benutzer ist nun in der Lage über die externe IP der Firewall auf das Userportal zuzugreifen. Auf diesem User Portal hat er ein Bookmark, welches wiederum auf einen Webserver zeigt, der nur via IPSec zugänglich ist. Mit einem Klick auf das Bookmark kann der User nun auf diesen Webserver zugreifen:
Wieso wird beim SSL-VPN im Webmodus viel Memory und CPU Leistung verbraucht?
Wir schauen uns an wieso im SSL-VPN Webmodus viele CPU Zyklen oder eine hohe Memory-Auslastung anfällt:
Bei der Verwendung von SSL-VPN im Web-Modus wird erwartet, dass viele CPU- und Speicherressourcen zugeteilt werden. Der SSL-VPN-Webmodus wurde als kurzfristige Ausweichlösung für den Fall konzipiert, dass der SSL-VPN-Tunnelmodus nicht verwendet werden kann.
Eine hohe Ressourcenzuweisung erfolgt aufgrund des "guacd"-Prozesses, welcher die konfigurierten Protokolle (zum Beispiel RDP oder HTTPS) in einen HTML5-Stream parsen muss, um sie dem Client zu präsentieren. Dieser Prozess der Konvertierung anderer Protokolle in Bilder ist sehr ressourcenintensiv in Bezug auf CPU und Memory.
Die Leistung des guacd-Prozesses kann man mit verschiedenen Befehlen beobachten:
diagnose sys topdiagnose sys top-summary
Mit diesen Befehlen, welche eine Auflistung aktiver Prozesse zeigen, erkennt man, dass die guacd-Prozesse sehr viel CPU oder Memory verbrauchen.
Schauen wir uns dass in einem Beispiel an:
| Konfiguration über die CLI:
|
|
Beispiel basiert auf einer FortiGate-300E FortiOS v6.2.3, build1066,191218 (GA) Wenn wir den folgenden Output anschauen, können wir sehen, dass der gesammte Speicherverbrauch zum Zeitpunkt der Datenerfassung bei etwa 85% liegt: Memory: 8172056k total, 7010740k used (85.8%), 950196k free (11.6%), 211120k freeable (2.6%) Der Speicher an dieser Stelle ist hauptsächlich für den aktiven Prozess reserviert (5,4 von 8 GB). # diagnose hardware sysinfo Memory MemTotal: 8172056 kB MemFree: 951164 kB Buffers: 2204 kB Cached: 594892 kB SwapCached: 0 kB Active: 5561348 kB MemTotal: 8172056 kB 7980 MB MemFree: 949948 kB 927 MB Cached: 594636 kB 580 MB Active: 5564144 kB 5433 MB <--- guacd Prozess und andere Userland Prozesse wie UTM Features Inactive: 273572 kB 267 MB Shmem: 337036 kB 329 MB Slab: 423044 kB 413 MB Wenn wir uns die aktiven Prozesse ansehen, wird der meiste Speicher durch die Menge der laufenden guacd-Prozesse verbraucht. # diagnose sys top
Run Time: 23 days, 21 hours and 51 minutes
28U, 0N, 20S, 36I, 0WA, 0HI, 16SI, 0ST; 7980T, 881F
sslvpnd 23061 R 93.0 5.3
guacd 30982 R 47.0 0.9
guacd 30909 R 45.0 1.1
sslvpnd 23060 R 28.0 5.3
sslvpnd 23062 R 21.0 5.3
ipsengine 16797 S < 5.0 2.1
ipsengine 16795 S < 4.0 2.2
ipsengine 16796 S < 3.0 2.1
guacd 30006 S 1.0 1.1
guacd 30139 S 1.0 1.1
miglogd 245 S 1.0 0.5
guacd 30884 S 1.0 0.4
httpsd 30908 S 1.0 0.3
authd 255 S 1.0 0.2
ipshelper 16794 S < 0.0 3.0
guacd 30315 S 0.0 1.1
guacd 30127 S 0.0 1.1
guacd 30115 S 0.0 1.1
updated 204 S 0.0 1.1
guacd 30023 S 0.0 1.1
guacd 30724 S 0.0 1.1
guacd 30078 S 0.0 1.1
guacd 30298 S 0.0 1.1
guacd 30260 S 0.0 1.1
guacd 30672 S 0.0 1.1
guacd 30218 S 0.0 1.1
guacd 30179 S 0.0 1.1
guacd 30039 S 0.0 1.1
guacd 30568 S 0.0 1.1
guacd 30177 S 0.0 1.1
guacd 30351 S 0.0 1.1
guacd 30380 S 0.0 1.1
guacd 30355 S 0.0 1.1
guacd 30331 S 0.0 1.1
guacd 30128 S 0.0 1.0
guacd 30259 S 0.0 1.0
guacd 30300 S 0.0 1.0
guacd 30229 S 0.0 1.0
guacd 30040 S 0.0 1.0
guacd 30936 S 0.0 1.0
guacd 30545 S 0.0 1.0
guacd 30053 S 0.0 1.0
guacd 30444 S 0.0 1.0
guacd 30592 S 0.0 1.0
guacd 30940 S 0.0 1.0
...
Wenn man sich diese guacd-Prozesse genauer ansieht, stellt man fest, dass jeder einzelne Prozess etwa 30 - 120 MB zur Verfügung stellt. Die obere Ausgabe zeigt, dass jeder Prozess ca. 1 % zuweist, so dass dies etwa 80 MB beträgt. Die Anzahl von maximalen SSL-VPN Benutzer kann abhängig von der gesamten Memory Kapazität von der Fortigate variieren. Mann kann in etwa folgendes berechnen: Wenn jeder Kunde nur minimale Ressourcen von 50MB verwenden würde, und das System würde keinen weiteren Speicher zuweisen, dann gibt es immer noch eine Begrenzung der Gesammtzahl der SSL-VPN-Clients auf der FortiGate mit insgesamt 8000 MB Memory. |
|
|
Wichtig zu wissen: |
Der SSL-VPN-Webmodus wurde als Ausweichlösung für den Fall konzipiert, wenn man den Tunnelmodus nicht verwenden kann (z.Bsp Zugang von einem öffentlichen WiFi oder Hotels usw.)
Aufgrund der erforderlichen Ressourcen sollte er nicht in grossem Umfang eingesetzt werden, sondern eher dazu dienen, Clients kurzfristig schnell zum laufen zu bringen. Auf lange Sicht sollten diese SSL-Clients so konfiguriert werden, dass sie den SSL-VPN-Tunnelmodus verwenden. Man kann den WebModus zum Beispiel dafür benutzen, dass der FortiClient über den SSL-VPN-Webmodus heruntergeladen wird:
Lösungen zur Vermeidung einer hohen CPU- oder Memoryauslastung:
- Tunnel Modus verwenden
- Im Webmodus Anzahl User so weit wie möglich begrenzen!
Aufgrund der erforderlichen Ressourcen wird diese Funktion nicht in grossem Umfang oder langfristig genutzt. Langfristig sind diese SSL-Clients so konfiguriert, dass sie den SSL-VPN-Tunnelmodus verwenden. Beispielsweise können Remote-Benutzer den FortiClient über den SSL-VPN-Webmodus herunterladen und sich dann über den SSL-VPN-Tunnelmodus verbinden.
|
|
Hinweis: |
IPSec VPN
Wie konfiguriere ich eine Site-to-Site IPSec VPN Verbindung von Grundauf?
ARTIKEL NOCH IN BEARBEITUNG und nicht VOLLSTÄNDIG
Ausgangslage
Wir wollen ein Site to Site VPN aufbauen von der Seite A zur Seite B. Nachfolgenden der Netzplan und die Parameter um den VPN Tunnel zu bilden:
| Seite A | Seite B | |
|---|---|---|
|
Netzplan |
| |
| Lokal Netzwerk | 192.168.2.0/24 | 172.16.16.0/24 |
| Public IP | 198.18.0.4 | 198.18.0.5 |
|
Authentication |
Pre-shared Key definieren | |
|
Phase 1 Proposal |
Alogrithms: AES256-SHA256 DH-Group 14 | |
|
Phase 2 Proposal |
Alogrithms: AES256-SHA512 / PFS-DH-Group 14 | |
Schritt 1 - IPSec Tunnel konfigurieren
| Konfiguration über das WebGui:
|
Network:
Authentication
Phase 1 Proposal
Phase 2 konfigurieren
Phase 2 konfigurieren
|
Schritt 2 - Routen konfigurieren
| Konfiguration über das WebGui:
|
|
Damit die FortiGate die Remote Netze für den VPN Tunnel kennt, muss eine Route auf das Tunnel Interface eingerichtet werden. Die Route kann folgendermassen konfiguriert werden:
Jetzt muss noch die Blackhole Route eingerichtet werden. Was eine Blackhole Route ist, kann hier entnommen werden:
Nun sollten beide Routen in der Übersicht ersichtlich sein. |
Schritt 3 - Policy Einrichten
| Konfiguration über das WebGui:
|
|
Damit der Traffic durch den VPN Tunnel fliesst, muss mindestens in eine Richtung eine Firewall Regel konfiguriert werden. Dabei wird das Tunnel Interface und das Interface für den Lokalen Traffic untereinander freigeschalten:
Damit der Traffic von beiden Seiten her funktioniert, muss ich noch eine zweite Policy einrichten. Diese kann analog der ersten Policy eingerichtet werden, einfach die Source und Destinations Interfaces und Adressobjekte tauschen. Alternativ kann auch die neu eingerichtete Policy mit rechtsklick angeklickt werden und im Dropdown Menu Clone Reverse gewählt werden. In der Policy muss jetzt dennoch was kleines konfiguriert werden:
Es wird empfohlen die Policies für Site to Site VPN im Regelwerk oben anzuordnen. |
IPSEC Phase 2 - Was bedeutet die Option Auto-Negotiate?
Ausgangslage:
Ein IPSec-VPN erzeugt eine verschlüsselte Sicherheitsassoziation (SA) zwischen zwei Peers.
Dies geschieht in zwei Phasen. Standardmässig wird die SA der Phase 2 erst dann ausgehandelt,
wenn ein Peer versucht Daten zu senden.
Funktion:
Wenn die auto-negotiate Funktion aktiviert ist, wird die Verhandlung der SA der Phase 2 automatisch eingeleitet. Dabei wird dieser Vorgang alle fünf Sekunden wiederholt, bis die SA eingerichtet ist.
Die Auto-Negotiate-Funktion erkennt, ob der Tunnel jemals abreisst und versucht die SA wieder herzustellen.
Die Keepalive-Funktion ist jedoch eine bessere Möglichkeit den VPN aufrechtzuerhalten.
Wann soll ich die Auto-Negotiate Funktion verwenden?
Man kann die auto-negotiate Funktion aktivieren, wenn auf einer Seite des VPN ein Einwahl-Peer ist. In dieser Konfiguration kann nur der Einwahl-Peer den Tunnel aufbauen, da der andere Peer die Gateway-Adresse der Einwahl-Peer nicht kennen kann.
Die Aktivierung von Auto-Negotiate beim Einwahl-Peer stellt sicher, dass der VPN-Tunnel für Benutzer hinter dem anderen Peer zur Einleitung von Datentraffic verfügbar ist.
So konfiguriere ich die Auto-Negotiate Funktion:
| Konfiguration über CLI: |
# config vpn ipsec phase2 # edit [PHASE2_NAME] # set auto-negotiate enable # end |
IPSEC Phase 2 - Was bedeutet die Option Keepalive?
Ausgangslage:
Die Sicherheitsassoziation (SA) der Phase 2 hat eine fixe Dauer. Wenn im VPN Traffic stattfindet, während die SA kurz vor dem Ablauf steht, wird eine neue SA ausgehandelt. So wechselt das VPN ohne Unterbruch zu einer neuen SA.
Wenn es kein Traffic gibt, läuft die SA aus, und der VPN-Tunnel wird unterbrochen.
Funktion:
Die Keepalive-Option stellt sicher, dass eine neue SA ausgehandelt wird, auch wenn kein Datentraffic vorhanden ist, so dass der VPN-Tunnel aufrecht erhalten bleibt.
So konfiguriere ich die Keepalive Option in der Phase 2:
| Konfiguration über CLI: |
# config vpn ipsec phase2 # edit [PHASE2_NAME] # set keepalive enable # end |
Kann ich sowohl Auto-Negotiate als auch Keepalive verwenden?
Ja. Auto-Negotiate und Keepalive funktionieren sehr gut zusammen. Auto-Negotiate startet das VPN und Keepalive sorgt dafür dass der VPN-Tunnel aufrecht erhalten bleibt.
Wie kann eine L2TP over IPSec Verbindung erstellt werden?
In den meisten Fällen ist eine Client2Side Verbindung mit anderen Technologien, wie beispielsweise dem FortiClient oder dem Cisco VPN Client, aus Performance- und Sicherheitsgründen zu bevorzugen. Bei einer C2S Verbindung via SSL oder IPSec besteht ausserdem die Möglichkeit, Split Tunneling zu konfigurieren. Bei einem L2TP VPN muss immer der gesamte Datenverkehr über den Tunnel gelenkt werden. Der Aufbau einer C2S Verbindung mit einer Fortigate ist jedoch dann sinnvoll, wenn es sich bei den Clientbetriebssystemen um ein Windows Betriebssystem handelt, auf welchem zwingend keine Software von Drittherstellern installiert werden darf. Eine L2TP IPSec Verbindung kann unter Windows nämlich mit den Ressourcen hergestellt werden.
Unter FortiOS 6.0 kann ein L2TP over IPSec Client2Side Tunnel nur teilweise im GUI konfiguriert werden. Da gewisse Konfigurationsschritte in der CLI vorgenommen werden müssen, basiert die folgende Anleitung vollumfänglich auf CLI-Befehlen.
L2TP over IPSec basiert immer auf einer Benutzerauthentifizierung. Aus diesem Grund benötigen wir einen lokalen oder einen Remotebenutzer, welchem wir die entsprechenden Rechte zuweisen können.
config user local edit "mytestuser" set type password set email-to "mytestuser@test.com" set passwd meinpasswort next
Dieser Benutzer wiederum wird einer Gruppe zugewiesen, welche später für den L2TP Zugriff berechtigt wird.
config user group edit "l2tpgroup" set member "mytestuser" next end
Nun benötigt es einige L2TP-spezifische Einstellungen (nicht im GUI konfigurierbar). Mit SIP und EIP definieren wir den IP-Range der IP Adressen, welche für die L2TP Clients zur Verfügung stehen sollen. Ausserdem definieren wir hier die Benutzergruppe, welcher Zugriff via L2TP gewährt werden soll.
config vpn l2tp set sip 10.20.100.1 set eip 10.20.100.254 set status enable set usrgrp "l2tpgroup" end
Da wir später in der Firewallpolicy mit diesen Source IP Adressen eine Firewallregel erstellen müssen, kreieren wir als nächstes gerade ein entsprechendes Adressobjekt.
config firewall address edit "net_vpn_10.20.100.0/24" set subnet 10.20.100.0 255.255.255.0 next end
Nun kann die Phase1 des IPSec Tunnels erstellt werden. Wichtig ist hier, dass diese vom Typ "dynamic" ist, als Peertype jede IP Adresse zulässt und die Proposals mit denen aus dem Beispiel übereinstimmen.
config vpn ipsec phase1 edit "l2tp-p1" set type dynamic set interface "wan1" set peertype any set proposal 3des-sha1 aes256-md5 set dhgrp 2 set psksecret meinepsk set dpd-retryinterval 60 next end
Auf dieser Phase1 kann anschliessend die Konfiguration für Phase2 aufgebaut werden. Als Quickmode Selector kann 0.0.0.0/0 gewählt werden (in der CLI per Default so). Auch hier muss darauf geachtet werden, dass PFS deaktiviert wird, und dass als Encapsulation Mode der "Tunnel Mode" gewählt wird.
config vpn ipsec phase2 edit "l2tp-p2" set phase1name "l2tp-p1" set proposal 3des-sha1 aes192-sha1 aes256-md5 set pfs disable set encapsulation transport-mode set keylifeseconds 86400 next end
Bei einem L2TP over IPSec Tunnel handelt es sich um einen policybasierten IPSec Tunnel. Diese Art von Tunnel bedarf etwas spezielle Firewallregel je für ein- und ausgehenden Traffic. Die ausgehende Firewallregel hat wie unten veranschaulicht auszusehen. Wichtig hierbei ist, dass die Action auf "ipsec" gestellt wird, und anschliessend das entsprechende IPSEC Tunnel Interface gewählt wird.
config firewall policy edit 3 set name "2l2tp" set srcintf "lan1" set dstintf "wan1" set srcaddr "net_int_192.168.2.0/24" set dstaddr "net_vpn_10.20.100.0/24" set action ipsec set schedule "always" set service "ALL" set inbound enable set vpntunnel "l2tp-p1" next edit 6 set name "l2tpincoming" set srcintf "wan1" set dstintf "lan1" set srcaddr "net_vpn_10.20.100.0/24" set dstaddr "net_int_192.168.2.0/24" set action accept set schedule "always" set service "ALL" next end
Somit wurde auf Seiten der Fortigate die Konfiguration für das L2TP over IPSec VPN fertiggestellt.
Ein Windows-10 Client wird wie folgt konfiguriert, damit er eine Verbindung via L2TP aufbauen kann:
Wie konfiguriere ich ein SSL-VPN Portal, welches über ein Site-to-Site VPN ein ServerLAN auf der Remote Seite erreichen soll?
Problemstellung:
Es besteht eine Site to Site VPN Verbindung zwischen der Site 1 zur Site 2. Wir haben auf der Site 2 einen Server mit der IP Adresse 172.16.16.20. Nun soll es möglich sein, über eine SSL-VPN Verbindung auf der Site 1 auch auf den Server 172.16.16.20 zuzugreiffen. Das heisst, wir müssen auf der Site 1 ein SSL-VPN konfigurieren und danach dafür sorgen, dass der Traffic weiter, durch den bestehenden S2S Tunnel auf den Server 172.16.16.20 geroutet wird. Das unten dokumentierte Szenario basiert auf dem Umstand, dass auf der Site 1 und Site 2 jeweils eine Fortigate Firewall im Einsatz ist. Ein Teil der untenstehenden Anleitung kann jedoch auch dann übernommen werden, wenn auf Site 2 eine Firewall eines Drittherstellers zum Einsatz kommt, oder wenn sich Site 2 in einer Public Cloud wie Azure oder AWS befindet. Die generischen, herstellerneutralen Schritte, um ein solches Szenario zu konfigurieren sind immer wie folgt:
- Firewall Site 2: Ändern sie die IPs des SSL-VPN-Pool auf einen IP-Range, damit der IP-Pool der Site 2 nicht mit dem Pool von Site 1 kollidiert.
- Firewall Site 1: Konfigurieren Sie in der SSL VPN Client2Site Konfiguration die Split Networks so, dass das entsprechende Netz von Site 2 (172.16.16.0/24) über den SSL VPN Tunnel geroutet wird.
- Firewall Site 1 und Site 2: Konfigurieren Sie die IPSec Einstellung des entsprechenden Tunnels so, dass sich das SSL-VPN-Client2Site Netz von Site 1 (10.10.10.1/24)) auf beiden Seiten entweder in der Local oder in den Remote Networks befindet. Somit werden diese IPs über den IPSec Tunnel überhaupt erst zugelassen.
- Firewall Site 2: Erstellen Sie eine statische Route damit das SSL VPN C2S Netz von Site 1 via IPSec Tunnel an Site 1 übermittelt wird.
- Firewall Site 1 + 2: Passen Sie die entsprechenden Firewallregeln an, damit eine Kommunikation möglich ist.
Lösungsansatz:
Die untenstehende Anleitung basiert auf folgedem Netzwerkschema:
| Netzwerkplan: |
|
Violett: Bestehende Konfiguration |
Konfiguration über das WebGui: Die Konfiguration basiert auf dem FortiOS 6.0.2:
| Konfiguration auf der Seite 1 |
|
Als Erstes die User anlegen. Diese können als lokale User eingerichtet werden (in unserem Beispiel machen wir dies so). Es ist auch möglich Radius oder LDAP User zu konfigurieren. # config user local # edit "user1" -> Username definieren # set type password # set passwd "user1" -> Passwort definieren # end Die User einer Usergruppe zuweisen. Diese Usergruppe wird beim SSL-VPN Portal dann genutzt. # config user group # edit "gr-user-ssl-vpn" # set member "user1" # end Für die Konfiguration des SSL-VPN Portals brauchen wir noch einen IP Pool. Dieser IP Pool wird den Clients zugewiesen. Es muss darauf geachtet werden, dass der definierte IP-Pool auf der Remote Seite (Site 2) nicht benutzt wird. Der Pool fängt mit der IP Adresse 10.10.10.2 an. # config firewall address # edit "ippool-ssl-vpn-10.10.10.2-10.10.10.254" # set type iprange # set color 18 # set start-ip 10.10.10.2 # set end-ip 10.10.10.254 # end Es muss ein Dummy SSL-VPN Portal eingerichtet werden, um das Handling abdecken zu können wenn kein gültiger User kommt. Wir stellen ein Portal her in welchem es möglich ist nur den FortiClient herunterzuladen. Menu SSL-VPN Portals -> Create New -> konfigurieren wie im Screenshot abgebildet. (Tunnel Mode: off, Enable Web Mode: off, Enable FortiClient Download: on) # config vpn ssl web portal # edit "dummy-portal" # end # end Jetzt wird das eigentliche SSL-VPN Portal konfiguriert. HIerzu wird der Tunnel-Mode gewählt. Das bedeutet, dass nur mit dem FortiClient die Verbindung aufgebaut werden kann. SSL-VPN-Portals -> tunnel-access editieren oder ein neues Portal definieren (Create New).
# config firewall address # edit "net-vpn-172.16.16.0-24" # set color 10 # set allow-routing enable # set subnet 172.16.16.0 255.255.255.0 # end SSL VPN Settings konfigurieren # config vpn ssl settings # set tunnel-ip-pools "ippool-ssl-vpn-10.10.10.2-10.10.10.254" # set port 443 # set source-interface "wan1" # set source-address "all" # set default-portal "dummy-portal" # config authentication-rule # edit 1 # set groups "gr-user-ssl-vpn" # set portal "tunnel-access" # next # end # end SSL-VPN Settings
Im Site to Site IPSEC Tunnel muss noch eine zweite Encryption Domäne hinzugefügt werden. Wir wollen das Netz 10.10.10.0/24 auch durch den Tunnel routen:
Adressen Objekt definieren für Splittunnel: # config vpn ipsec phase2-interface # edit "Site1_to_Site2" -> Name des Tunnels # edit "site1-sslvpn-site2" -> Name des Selektors definieren # set phase1name "Site1_to_Site2" # set proposal aes256-sha256 aes128gcm aes256gcm chacha20poly1305 -> Gewünschte Verschlüsslungsalgorithmen konfigurieren # set dhgrp 14 # set src-subnet 10.10.10.0 255.255.255.0 -> Source Netzwerk: SSL-VPN IP-Pool # set dst-subnet 172.16.16.0 255.255.255.0 -> Destinations Netzwerk (DMZ ServerLan) # end Konfiguration der Policy für den Zugriff vom Client auf das SSL-VPN weiter zur Remote Seite des IPSEC Tunnels: Policy & Objects -> IPv4Policy -> Create New
Die Zerfikatsmeldung kann ignoriert werden. Übersicht des Policysets (es ist darauf zu achten, dass die VPN Regeln oberhalb der regulären Regeln sind): |
| Konfiguration auf der Seite 2 |
|
Im bestehenden IPSEC Tunnel zur Site 1 muss noch ein zweiter Phase 2 Selektor für das SSL-VPN Netz erstellt werden. IPsec Tunnels -> den entsprechenden Tunnel editieren
# config vpn ipsec phase2-interface # edit "site2-site1-sslvpn" -> Name des Tunnels # set phase1name "site2-site1" -> Name des Selektors definieren # set proposal aes256-sha256 aes128gcm aes256gcm chacha20poly1305 -> Gewünschte Verschlüsslungsalgorithmen konfigurieren # set dhgrp 14 # set src-subnet 172.16.16.0 255.255.255.0 -> Source Netzwerk (DMZ ServerLan) # set dst-subnet 10.10.10.0 255.255.255.0 -> SSL-VPN IP-Pool # next # end Jetzt muss das SSL-VPN Netz noch zurück in den Tunnel geroutet werden. Network -> Static Routes -> Create New
# config router static # edit [intiger] # set dst 10.10.10.0 255.255.255.0 -> SSL-VPN IP-Pool Netz eintragen # set device "site2-site1" -> IPSEC Interface vom Tunnel Site 1 <-> Site 2 eintragen # set comment "sslvpn site1" # end Die Blackhole-Route nicht vergessen einzurichten: Network -> Static Routes -> Create New
# config router static # edit [intiger] # set dst 10.10.10.0 255.255.255.0 -> SSL-VPN IP-Pool Netz eintragen # set distance 254 -> Distanz muss hier höher sein, als in der regulären Route! # set comment "Blackhole Route" # set blackhole enable # end Wenn die Routen konfiguriert sind, können diese kontrolliert werden. Bitte noch einmal prüfen ob die Distance der Blackhole Route höher als die reguläre Route ist: Jetzt kann der zweite Selektor des IPSEC Tunnels hochgefahren werden. Monitor -> IPsec Monitor -> auf dem entsprechenden Tunnel in der Phase 2 des Selectors mit Rechtsklick auf Bring Up klicken Wenn alles grün ist, ist der Tunnel up and running Damit der Traffic an den Server weitergeleitet wird, muss noch eine Policy eingerichtet werden: Policy & Objects -> IPv4 Policy -> Create New
Adressobjekte: # config firewall address # edit "net-172.16.16.0-24" # set color 2 # set subnet 172.16.16.0 255.255.255.0 # next # edit "vpn-remote-10.10.10.0-24" # set color 10 # set subnet 10.10.10.0 255.255.255.0 # end Policy konfigurieren: # config firewall policy # edit [intiger] # set name "I_sslVPN-Site1_Site2" # set srcintf "site2-site1" -> Source Interface ist das IPSEC-VPN Interface # set dstintf "internal1" -> Destinations Interface ist das DMZ ServerLan Interface # set srcaddr "vpn-remote-10.10.10.0-24" -> Source IP: SSL-VPN IP-Pool # set dstaddr "net-172.16.16.0-24" -> Destination IP: Netzwerk des DMZ ServerLan # set action accept # set status enable # set schedule "always" # set service "ALL" # set logtraffic all # end Die VPN Regeln zusammen bündeln: |
| Konfiguration vom FortiClient |
|
Eine neue Verbindung im FortiClient einrichten: Reiter SSL-VPN anwählen
Zum Verbinden den entsprechenden Tunnel anwählen und die Benutzer Daten (Username und Passwort) eingeben. Mit verbinden baut man den Tunnel auf. Wenn die Anmeldung erfolgreich durchgeführt werden konnte, wird der Tunnel aufgebaut. Wir sehen die IP Adresse, welche von der Site 1 dem Client zugewiesen wurde (10.10.10.2)
Auf der Site 2 können wir jetzt sehen, dass der Traffic von der IP Adresse 10.10.10.1 auf 172.16.16.20 mit der Policy ID 3 gematcht hat. Wir sehen die Adresse 10.10.10.2 welche aus dem SSL-VPN IP-Pool zugewiesen wurde |
Welche Faktoren sind bei einer VPN Geschwindigkeitsmessung relevant?
Wenn zwischen zwei Standorten ein IPSec Tunnel erstellt wird, so ist der Datendurchsatz zwischen den zwei Standorten von unterschiedlichen Faktoren abhängig. Häufig anzutreffen ist inzwischen der Umstand, dass an beiden Standorten eine synchrone Gigabit Internetverbindung vorhanden ist, und dass nun die Erwartungshaltung besteht, dass zwischen diesen beiden Standorten eine VPN-Verbindung mit annähernd Gigabit Geschwindigkeit möglich sein wird. In diesem Szenario spielt es jedoch auch eine grosse Rolle, ob der Provider (oder die mehreren Provider) dieses Gigabit auch durch seinen Backbone gewährleistet, was meistens nicht der Fall ist.
Der folgende Artikel hilft, den maximal technisch möglichen Durchsatz zwischen zwei Standorten zu ermitteln.
Folgende Faktoren sind relevant um zu bestimmen, welcher Durchsatz maximal überhaupt möglich ist:
| Seite A | Seite B |
|---|---|
|
1. Firewall |
1. Firewall |
|
3. Parameter zwischen den Standorten | |
* Die Durchsätze können den Datenblättern entnommen werden:
1. Datenblatt Fortinet Verwende den Wert IPsec VPN Throughput
2. Datenblatt Sophos Verwende den Durchsatz VPN AES Realworld (Mbps) multiple tunnels/cores
# Gemessener Durchsatz zwischen den zwei Standorten
Eine gültige Messung zwischen den Standorten hilft festzustellen welcher Durchsatz der Provider durch seinen Backbone gewährleistet. Dieser Durchsatzwert kann natürlich je nach Tageszeit und allgemeiner Netzbelastung erheblich variieren. Eine Messung zu dessen Erhebung kann wie folgt vorgenommen werden:
1. Laden Sie auf https://speed.hetzner.de/ eines der zur verfügungstehenden Testfiles herunter.
2. Kopieren Sie dieses Testfile auf einen Webserver an einem der beiden Standorte
3. Publizieren Sie diesen Webserver via DNAT über die Firewall ins Internet (Anleitung hierzu: Sophos, Fortinet)
4. Laden Sie die Datei vom gegenüberliegenden Standort über das Internet (und nicht über den IPSec Tunnel) herunter, und messen sie den erreichten Durchsatz.
Maximal zu erwartender Durchsatz insgesamt:
- Der maximale, technisch mögliche Durchsatz durch einen VPN Tunnel ergibt sich aus dem kleinsten Wert der oben erhobenen Durchsatzwerte in den Punkten 1.2, 2.2, 2.3 und 3.1.
- Die erhobenen Messwerte in den Punkten 3.2 und 3.3 haben keinen direkten Einfluss auf den maximal möglichen Durchsatz, sind jedoch relevant wenn es um Messgrössen wie Delay oder Jitter geht.
Wie kann ich eine gültige VPN Performancemessung erstellen?
Nachdem im Artikel Welche Faktoren sind bei einer VPN Geschwindigkeitsmessung relevant der maximal erreichbare technische Durchsatz ermittelt wurde, möchte man nun dazu übergehen zu messen, ob dieser Durchsatz in der Praxis auch erreicht werden kann. Dabei gibt es ein paar Richtlinien zu beachten. Das altbekannte Sprichwort Wer misst, misst Mist! ist in diesem Fall leider oftmals allgegenwärtig.
Tools, welche beispielsweise via SMB eine Datei auf einen Fileshare kopieren, und dann den erreichten Durchsatz messen, messen nicht unbedingt den VPN Durchsatz, sondern unter Umständen viel eher:
- Die Festplattengeschwindigkeit des Zielsystems
- Die Geschwindigkeit des SMB Protokolls
- Die Geschwindigkeit der onRead Antivirenüberprüfung des Zielsystems
- Die Geschwindigkeit des DNS-Resolvers
Um solche Messfehler zu vermeiden, müssen folgende Richtlinien bei einer Messung unbedingt beachtet werden:
- Eine Messung findet zwischen zwei Messsystemen statt, auf welchen zum Zeitpunkt der Messung kein anderer Traffic und keine anderen Tasks verarbeitet wird.
- Der gesammte VPN Tunnel wird zum Zeitpunkt der Messung nicht von irgendwelchen anderen Systemen in Anspruch genommen.
- Die beiden Internetleitungen werden zum Zeitpunkt der Messung nicht von irgendwelchen anderen Systemen belegt.
- Die beiden Messsysteme befinden sich auf beiden Seiten direkt hinter der Firewall.
- Als Messtool wird IPerf3 eingesetzt. Das Tool kann von der Iperf Projektseite inklusive Bedienungsanleitung heruntergeladen werden.
| Datei: | Beschreibung: |
|
IPerf Anleitung | |
| Datei:Tools-iperf.zip | IPerf Tool |
Messaufbau
Wie konfiguriere ich ein VPN zwischen einer FortiGate und einer Sophos UTM Firewall?
Ausgangslage:
In diesem Artikel wird beschrieben, wie ein Site-to-Site VPN zwischen einer FortiGate und einer Sophos UTM Firewall konfiguriert werden kann. Dieses Setup wurde unter folgenden Bedingungen aufgebaut und durchgetestet:
| Seite FortiGate | Seite Sophos UTM | |
|---|---|---|
|
Netzplan |
| |
| Hardware | FortiGate 300D | Sophos UTM/SG |
| Software | 6.4.2 build1723 | V9.703-3 |
| Lokal Netzwerk | 198.18.0.0/24 | 192.168.111.0/24 |
| Public IP | 146.XX.XX.66 | 194.XX.XX.111 |
|
Authentication |
Pre-shared Key definieren | |
|
IKE Version |
Version 1 (UTM unterstützt IKE Version 2 nicht) | |
|
Phase 1 Proposal |
Alogrithms: AES256-SHA256 DH-Group 5 | |
|
Phase 1 Key Lifetime |
86400 Sekunden | |
|
Phase 2 Proposal |
Alogrithms: AES256-SHA512 / PFS-DH-Group 5 | |
|
Phase 2 Key Lifetime |
43200 Sekunden | |
Konfiguration FortiGate 300D:
| Konfiguration über das WebGUI:
|
|
Konfigurieren des VPN-Tunnels: Netzwerkeinstellungen:
Authentication konfigurieren:
Phase 1 Parameter konfigurieren:
Phase 2 Selektoren konfigurieren: Auf der Sophos wird der Term 0.0.0.0/0 nicht unterstützt.
|
|
Konfigurieren der Routen: Die Routen werden wie folgt konfiguriert:
Menu: Network -> static Routes -> |
|
Konfigurieren der Policies: Menu : Policy & Objects -> IPv4 Policy -> |
| Konfiguration über die CLI:
|
|
VPN Phase 1 konfigurieren: config vpn ipsec phase1-interface
edit "[VPN_NAME]"
set interface "[WAN-INTERFACE]"
set peertype any
set net-device disable
set proposal aes256-sha256
set comments "VPN zu Sophos UTM"
set dhgrp 5
set nattraversal disable
set remote-gw [PUBLIC_IP_SOPHOS-UTM]
set psksecret [PRESHARED-KEY]
next
end
VPN Phase 2 konfigurieren: config vpn ipsec phase2-interface
edit "p2_[VPN_NAME]"
set phase1name "[VPN_NAME]"
set proposal aes256-sha256
set dhgrp 5
set keepalive enable
set src-subnet [MEIN_LOKALES_NETZWERK NETZMASKE]
set dst-subnet [REMOTE NETZWERK NETZMASKE]
next
end
Routen konfigurieren: config router static
edit 2
set dst [REMOTE NETZWERK NETZMASKE]
set device "[VPN_NAME]"
set comment "Route Remote Netz ALSO DE - UTM Sophos "
next
edit 3
set dst [REMOTE NETZWERK NETZMASKE]
set comment "Blackhole [REMOTE NETZWERK NETZMASKE]"
set distance 254
set blackhole enable
next
end
Adress Objekte für Policies konfigurieren: config firewall address
edit "[NAME_ADRESSOBJEKT_REMOTE_NETZWERK]"
set color 10
set subnet [NETZWERK_ADRESSE] [SUBNETZMASKE]
next
edit "[NAME_ADRESSOBJEKT_INTERNES_NETZWERK]"
set color 10
set subnet [NETZWERK_ADRESSE] [SUBNETZMASKE]
next
end
Policy konfigurieren: config firewall policy
edit 1
set name "O_vpn-sophosUTM"
set srcintf "[INTERNES_INTERFACE]"
set dstintf "[VPN_NAME]"
set srcaddr "[NAME_ADRESSOBJEKT_INTERNES_NETZWERK]"
set dstaddr "[NAME_ADRESSOBJEKT_REMOTE_NETZWERK]"
set action accept
set schedule "always"
set service "ALL"
set logtraffic all
next
edit 2
set name "I__vpn-sophosUTM"
set srcintf "[VPN_NAME]"
set dstintf "[INTERNES_INTERFACE]"
set srcaddr "[NAME_ADRESSOBJEKT_REMOTE_NETZWERK]"
set dstaddr "[NAME_ADRESSOBJEKT_INTERNES_NETZWERK]"
set action accept
set schedule "always"
set service "ALL"
set logtraffic all
next
end
|
Konfiguration auf der Sophos UTM:
| Konfiguration über das WebGUI:
|
|
Auf der Sophos UTM Firewall wird ein VPN wie folgt aufgebaut:
|
|
Neuen Tunnel erstellen:
|
|
Remote Gateway:
|
|
Policy:
|
|
Connections:
|
kann ein neues Remote Netzwerk erstellt werden.
Erfolgskontrolle:
| VPN-Monitore:
|
|
VPN Monitor - FortiGate: VPN Monitor - Sophos UTM: |
Anleitung als PDF:
Wie konfiguriere ich ein VPN zwischen einer FortiGate und einer Sophos XG Firewall?
Artikel noch im Aufbau , bitte um Geduld
Ausgangslage:
| Seite FortiGate | Seite Sophos XG | |
|---|---|---|
|
Netzplan |
| |
| Hardware | FortiGate 300D | Sophos XG 210 |
| Software | 6.4.2 build1723 | V18.0.1 MR1 |
| Lokal Netzwerk | 198.18.0.0/24 | 192.168.111.0/24 |
| Public IP | 146.XX.XX.66 | 194.XX.XX.111 |
|
Authentication |
Pre-shared Key definieren | |
|
IKE Version |
Version 2 | |
|
Phase 1 Proposal |
Algorithmus: AES256-SHA256 DH-Group 5 | |
|
Phase 1 Key Lifetime |
86400 Sekunden | |
|
Phase 2 Proposal |
Algorithmus: AES256-SHA512 / PFS-DH-Group 5 | |
|
Phase 2 Key Lifetime |
43200 Sekunden | |
Konfiguration FortiGate
| Konfiguration über das WebGui:
|
|
Konfigurieren des VPN Tunnels: Netzwerkeinstellungen:
Authentication konfigurieren:
Phase 1 Parameter konfigurieren:
Phase 2 Selektoren konfigurieren: Auf der Sophos wird der Term 0.0.0.0/0 nicht unterstützt.
|
|
Konfigurieren der Routen: Die Routen werden folgendermassen konfiguriert:
Menu: Network -> Static Routes -> |
|
Konfigurieren der Policies: Menu : Policy & Objects -> IPv4 Policy -> |
| Konfiguration über die CLI:
|
|
VPN Phase 1 konfigurieren: config vpn ipsec phase1-interface
edit "[VPN_NAME]"
set interface "[WAN-INTERFACE]"
set peertype any
set net-device disable
set proposal aes256-sha256
set comments "VPN zu Sophos XG"
set dhgrp 5
set nattraversal disable
set remote-gw [PUBLIC_IP_SOPHOS-XG]
set psksecret [PRESHARED-KEY]
next
end
VPN Phase 2 konfigurieren: config vpn ipsec phase2-interface
edit "p2_[VPN_NAME]"
set phase1name "[VPN_NAME]"
set proposal aes256-sha256
set dhgrp 5
set keepalive enable
set src-subnet [MEIN_LOKALES_NETZWERK NETZMASKE]
set dst-subnet [REMOTE NETZWERK NETZMASKE]
next
end
Routen konfigurieren: config router static
edit 2
set dst [REMOTE NETZWERK NETZMASKE]
set device "[VPN_NAME]"
set comment "Route Remote Netz ALSO DE - XG Sophos "
next
edit 3
set dst [REMOTE NETZWERK NETZMASKE]
set comment "Blackhole [REMOTE NETZWERK NETZMASKE]"
set distance 254
set blackhole enable
next
end
Adress Objekte für Policies konfigurieren: config firewall address
edit "[NAME_ADRESSOBJEKT_REMOTE_NETZWERK]"
set color 10
set subnet [NETZWERK_ADRESSE] [SUBNETZMASKE]
next
edit "[NAME_ADRESSOBJEKT_INTERNES_NETZWERK]"
set color 10
set subnet [NETZWERK_ADRESSE] [SUBNETZMASKE]
next
end
Policy konfigurieren: config firewall policy
edit 1
set name "O_vpn-sophosXG-DE"
set srcintf "[INTERNES_INTERFACE]"
set dstintf "[VPN_NAME]"
set srcaddr "[NAME_ADRESSOBJEKT_INTERNES_NETZWERK]"
set dstaddr "[NAME_ADRESSOBJEKT_REMOTE_NETZWERK]"
set action accept
set schedule "always"
set service "ALL"
set logtraffic all
next
edit 2
set name "I__vpn-sophosXG-DE"
set srcintf "[VPN_NAME]"
set dstintf "[INTERNES_INTERFACE]"
set srcaddr "[NAME_ADRESSOBJEKT_REMOTE_NETZWERK]"
set dstaddr "[NAME_ADRESSOBJEKT_INTERNES_NETZWERK]"
set action accept
set schedule "always"
set service "ALL"
set logtraffic all
next
end
|
Konfiguration Sophos XG
| Konfiguration über das WebGui:
|
|
Ein neuer VPN wird im Menu Configure-> VPN -> IPsec connections erstellt. Authentication konfigurieren: |
|
Netzwerkeinstellungen:
Local gateway: (Netzwerk Optionen Sophos XG Firewall)
Remote gateway (Netzwerk Optionen der FortiGate- Remoteseite)
|
|
Phase 1 Parameter konfigurieren:
|
|
Phase 2 Selektoren konfigurieren:
|
Wie konfiguriere ich ein VPN zwischen einer FortiGate und einer Checkpoint Firewall?
Ausgangslage:
| Seite FortiGate | Seite Checkpoint | |
|---|---|---|
|
Netzplan |
| |
| Hardware | FortiGate 60F | Checkpoint 1550 |
| Software | 6.4.2 build1723 | R80.20.05 (992001134) |
| Lokal Netzwerk | 10.10.161.0/24 | 10.10.151/24 |
| Public IP | 198.18.0.161 | 198.18.0.151 |
|
Authentication |
Pre-shared Key definieren | |
|
IKE Version |
Version 2 | |
|
Phase 1 Proposal |
Alogrithms: AES256-SHA256 DH-Group 15 | |
|
Phase 1 Key Lifetime |
86400 Sekunden | |
|
Phase 2 Proposal |
Alogrithms: AES256-SHA512 / PFS-DH-Group 15 | |
|
Phase 2 Key Lifetime |
3600 Sekunden | |
Konfiguration FortiGate 60F:
| Konfiguration über das WebGUI:
|
|
Konfigurieren des VPN-Tunnels: Netzwerkeinstellungen:
Authentication konfigurieren:
Phase 1 Parameter konfigurieren:
Phase 2 Selektoren konfigurieren: In diesem Beispiel zeigen wir, wie man den Selektor für 10.10.161.0/24 zu 10.10.151.0/24 konfiguriert:
|
|
Konfigurieren der Routen: Die Routen werden wie folgt konfiguriert:
Menu: Network -> Static Routes -> Blackhole Route mit Distanz 254: |
|
Konfigurieren der Policies: Menu : Policy & Objects -> IPv4 Policy -> Die ganze Policy noch bei bedarf gegengleich konfigurieren (Source Interface / Netz und Destinations Interface / Netz) Dabei kann die Clone Reverse Funktion benutzt werden. Komplettes Regelsetup: |
| Konfiguration via CLI:
|
|
VPN Phase 1 konfigurieren: config vpn ipsec phase1-interface
edit "vpn_to_CP_151"
set interface "wan1"
set ike-version 2
set peertype any
set net-device disable
set proposal aes256-sha256
set dhgrp 14
set remote-gw 198.18.0.151
set psksecret "Hier_einen_komplexen_Key_eingeben"
next
end
VPN Phase 2 konfigurieren: config vpn ipsec phase2-interface
edit "p2-vpn_to_lab-0062-10.10.162.0-24"
set phase1name "vpn_to_lab-0062"
set proposal aes256-sha256
set dhgrp 14
set auto-negotiate enable
set src-subnet 10.10.161.0 255.255.255.0
set dst-subnet 10.10.162.0 255.255.255.0
next
end
Routen konfigurieren: config router static
edit 2
set dst 10.10.151.0 255.255.255.0
set device "vpn_to_CP_151"
next
edit 3
set dst 10.10.151.0 255.255.255.0
set distance 254
set comment "blackhole Route - CP Remote Netz"
set blackhole enable
next
end
Adress Objekte für Policies konfigurieren: config firewall address
edit "net_remoteVPN-10.10.151.0-24"
set comment "Remote Netz -VPN Checkpoint"
set color 10
set subnet 10.10.151.0 255.255.255.0
next
edit "net_ul-10.10.161.0-24"
set color 3
set subnet 10.10.161.0 255.255.255.0
next
end
Policy konfigurieren: config firewall policy
edit 5
set name "I_vpn_CP_151->10.0.161.0-24"
set srcintf "vpn_to_CP_151"
set dstintf "internal2"
set srcaddr "net_remoteVPN-10.10.151.0-24"
set dstaddr "net_ul-10.10.161.0-24"
set action accept
set schedule "always"
set service "ALL"
set logtraffic all
next
edit 6
set name "O_vpn_10.10.161.0-24->CP_151"
set srcintf "internal2"
set dstintf "vpn_to_CP_151"
set srcaddr "net_ul-10.10.161.0-24"
set dstaddr "net_remoteVPN-10.10.151.0-24"
set action accept
set schedule "always"
set service "ALL"
set logtraffic all
next
end
|
Konfiguration Checkpoint 1550
| Konfiguration über das WebGUI:
|
|
Konfigurieren des VPN-Tunnels: VPN -> VPN Sites -> Netzwerk-Parameter:
Remote Site Encryption Domain konfigurieren
Mit Encryption für Phase 1 und Phase 2 konfigurieren:
Advanced Optionen konfigurieren:
|
|
Konfigurieren eines Netzwerk Objektes:
Im Editor-Fenster folgendes konfigurieren:
Konfigurieren der Policy:
|
das Objekt erstellen
kann das Adress-Objekt zu der Encryption Domain hinzugefügt werden.
Erfolgskontrolle
FortiGate Monitor:
Checkpoint Monitor:
Traffic generieren und im Debug auf den beiden Geräten prüfen:
Ping von der FortiGate aus generiert:
- mit dem Befehl
execute ping-option source 10.10.161.2können wir der FortiGate angeben, mit welcher Adresse diese den Ping ausführen soll - mit dem Befehl
execute ping 10.10.151.2können wir die IP Adresse auf der Checkpoint vom LAN Interface anpingen
Im Flow sieht das so aus:
# diag debug flow filter clear
# diag debug flow filter sadd 10.10.161.2
# diag debug flow filter dadd 10.10.151.2
# diag debug flow trace start 9000
# diag debug enable
# id=20085 trace_id=6 func=print_pkt_detail line=5639 msg="vd-root:0 received a packet(proto=1, 10.10.161.2:3584->10.10.151.2:2048) from local. type=8, code=0, id=3584, seq=0."
id=20085 trace_id=6 func=init_ip_session_common line=5810 msg="allocate a new session-00087e78"
id=20085 trace_id=6 func=ipd_post_route_handler line=439 msg="out vpn_to_CP_151 vwl_zone_id 0, state2 0x0, quality 0.
"
id=20085 trace_id=6 func=ipsecdev_hard_start_xmit line=789 msg="enter IPsec interface-vpn_to_CP_151"
id=20085 trace_id=6 func=_ipsecdev_hard_start_xmit line=666 msg="IPsec tunnel-vpn_to_CP_151"
id=20085 trace_id=6 func=esp_output4 line=907 msg="IPsec encrypt/auth"
id=20085 trace_id=6 func=ipsec_output_finish line=622 msg="send to 198.18.0.151 via intf-wan1"
id=20085 trace_id=7 func=print_pkt_detail line=5639 msg="vd-root:0 received a packet(proto=1, 10.10.161.2:3584->10.10.151.2:2048) from local. type=8, code=0, id=3584, seq=1."
id=20085 trace_id=7 func=resolve_ip_tuple_fast line=5720 msg="Find an existing session, id-00087e78, original direction"
id=20085 trace_id=7 func=ipd_post_route_handler line=439 msg="out vpn_to_CP_151 vwl_zone_id 0, state2 0x0, quality 0.
# diag debug reset
# diag debug disable
fw monitor auf der Checkpoint:
fwalem-lab-0151> expert in den Expert Modus wechseln Enter expert password: You are in expert mode now. FW Monitor: [Expert@fwalem-lab-0151]# fw monitor -e 'accept host(10.10.161.2);' fw: getting filter (from command line) fw: compiling monitorfilter: Compiled OK. fw: loading fw: monitoring (control-C to stop) [vs_0][fw_2] WAN:id[84]: 10.10.161.2 -> 10.10.151.2 (ICMP) len=84 id=53344 ICMP: type=8 code=0 echo request id=3840 seq=1 [vs_0][fw_2] WAN:ID[84]: 10.10.161.2 -> 10.10.151.2 (ICMP) len=84 id=53344 ICMP: type=8 code=0 echo request id=3840 seq=1 [vs_0][fw_2] WAN:o[84]: 10.10.151.2 -> 10.10.161.2 (ICMP) len=84 id=7498 ICMP: type=0 code=0 echo reply id=3840 seq=1 [vs_0][fw_2] WAN:O[84]: 10.10.151.2 -> 10.10.161.2 (ICMP) len=84 id=7498 ICMP: type=0 code=0 echo reply id=3840 seq=1 [vs_0][fw_2] WAN:O[84]: 10.10.151.2 -> 10.10.161.2 (ICMP) len=84 id=7498 ICMP: type=0 code=0 echo reply id=3840 seq=1 [vs_0][fw_2] WAN:id[84]: 10.10.161.2 -> 10.10.151.2 (ICMP) len=84 id=53345 ICMP: type=8 code=0 echo request id=3840 seq=2 [vs_0][fw_2] WAN:ID[84]: 10.10.161.2 -> 10.10.151.2 (ICMP) len=84 id=53345 ICMP: type=8 code=0 echo request id=3840 seq=2 [vs_0][fw_2] WAN:o[84]: 10.10.151.2 -> 10.10.161.2 (ICMP) len=84 id=7720 ICMP: type=0 code=0 echo reply id=3840 seq=2 [vs_0][fw_2] WAN:O[84]: 10.10.151.2 -> 10.10.161.2 (ICMP) len=84 id=7720 ICMP: type=0 code=0 echo reply id=3840 seq=2 [vs_0][fw_2] WAN:O[84]: 10.10.151.2 -> 10.10.161.2 (ICMP) len=84 id=7720 …… Mit ctrl+c kann der Output abgebrochen werden
Guide als PDF Herunterladen:
Wie kann ich auf einem VPN Interface die MTU Werte anpassen?
Im Normalfall wird der MTU Wert von einem Tunnel Interface von der FortiGate aus automatisch berechnet. Falls man jetzt aber Probleme hat gewisse Datenmengen durch den Tunnel zu bringen, kann es erforderlich sein diese manuell zu setzen.
MTU auf VPN Interface ab FortiOS 6.4.0 konfigurieren:
| Konfiguration über die CLI:
|
# config system interface # edit [TUNNEL_INTERFACE] # set mtu-override [enable|disable] # set mtu [MTU_WERT] # end # end Beispiel: # config system interface # edit remote-vpn1 # set mtu-ovveride enable # set mtu 1372 # end # end |
|
|
Vor der Version FortiOS 6.4.0 kann die MTU nicht auf dem VPN Interface konfiguriert werden. |
edit 04.09.2020
FortiClient
Wie kann ich ohne den EMS Server ein vordefiniertes Softwarepaket für den VPN Client erstellen?
Seit FortiOS 5.4 gibt es von Fortinet das FortiClient Configuration Tool. Mit diesem Tool können benutzerdefinierte Softwarepakete erstellt werden. So kann beispielsweise eine komplette Konfiguration im XML Format mitgegeben, einzelne Komponenten der Installation entfernt werden oder den Installer als paketierfähiges *.MSI Paket in den Varianten 32 oder 64Bit heruntergeladen werden. Ausserdem ist es möglich, den FortiClient einem Rebranding zu unterziehen (Austausch der Logos und Grafiken).
Die aktuellste Version des FortiClient Configuration Tool kann jeweils über das Fortinet Developer Portal heruntergeladen werden. Das Configuration Tool ist als Standalone Software lauffähig, existiert für Windows und Mac und muss auf Windows nicht installiert werden.
Weitere Informationen:
- Datei:FortiClientConfigurationTool 5.6.6.zip
- Datei:FortiClientConfigurationTool 6.0.0.zip
- Datei:Forticlient-5.6.0-configurator-tool.pdf
- Datei:FortiClient-5.6.0-XML-Reference.pdf
Wieviele Remote VPN User kann ich auf der FortiGate nutzen?
Die Anzahl der Remote VPN Verbindungen, welche pro FortiGate Gerät unterstützt wird, kann im Datenblatt des jeweiligen Modells entnommen werden.
Hier ein Beispiel der FortiGate 60E.
- Für die maximale Anzahl IPsec User muss der Punkt Client-to-Gateway IPsec VPN Tunnels beachtet werden.
- Für SSL-VPN User gibt es einen empfohlenen Wert für den Tunnel-Modus im Punkt: Concurrent SSL-VPN Users (Recommended Maximum Tunnel Mode)
Die Datenblätter findet man in unserem Wiki: Fortinet:ProduktInfo#FortiGate
Was für Remote VPN User natürlich auch massgebend ist, ist die Internetleitung der FortiGate auf welche die User sich verbinden. Wenn sich 200 User auf einer 2MB Leitung einloggen, wird die gesammt Performance auf die 200 User aufgeteilt. Nicht vergessen darf man natürlich auch den restlichen Traffic welcher über die FortiGate weiterhin verarbeitet wird.
Im FortiOS 6.0 sieht man im Widget eine Limitation wieviele User sich auf der FortiGate über den FortiClient anmelden können. Standartmässig sind hier zehn User verfügbar (0/10). Dies bedeutet, dass der FortiClient sich auf der FortiGate über die Telemetrie registriert. Will man den FortiClient nur als VPN-Client (IPSEC oder SSL-VPN) nutzen, ist es nicht notwendig, dass sich der Client über die Telemetrie auf der FortiGate registriert. Wenn man den VPN Remote Wizard benutzt, muss darauf geachtet werden, dass die Option Allow Endpoint Registration deaktiviert wird. (Default mässig ist diese aktiviert)
| Konfiguration über das WebGui:
|
|
Wizard wird gestartet über VPN->IPsec Wizard Template type Remote Access |
Was wenn ich vergessen haben die Option zu deaktivieren? Dies kann nicht mehr im Wizard deaktiviert werden. Dafür muss ich auf das Interface gehen und mir dort die Telemetrie Option deaktivieren.
Weitere Informationen finde ich im folgenden Wiki Artikel: Wie kann ich einen Registrierten User von der FortiGate wieder deregistrieren?
Wie kann ich die Registration eines Users rückgängig machen?
Wenn man die Endpoint Registration über den VPN Wizard nicht deaktiviert hat, wird jeder VPN Remote User auf der FortiGate registriert. Wenn man dies nicht will, kann man die User wieder von der FortiGate deregistrieren:
Um zu sehen welche User registriert sind kann folgender Befehl eingegeben werden:
| Konfiguration über die CLI:
|
# diag endpoint registration list FortiClient #1 (0): UID = B209297BF1F44F88BC7CD8CBF62AD2F9 vdom = root status = registered compliance = yes registering time = Fri Mar 20 13:12:50 2020 registration expiry time = Fri Mar 27 13:12:50 2020 source IP = 10.60.60.140 source MAC = b8:31:xx:xx:xx:f0 user = anonym host OS = Microsoft Windows 10 Professional Edition, 64-bit (build 18362) restored registration = no remote registration = no registration FGT = FGT30Exxxxxxx FortiClient #2 (1): UID = A71EC83EA0354B51858C69B6882C0BFD vdom = root status = registered compliance = yes registering time = Fri Mar 20 13:17:36 2020 registration expiry time = Fri Mar 27 13:17:36 2020 source IP = 10.60.60.134 source MAC = 58:82:xx:xx:xx:19 user = anonym host OS = Microsoft Windows 10 Professional Edition, 64-bit (build 18362) restored registration = no remote registration = no registration FGT = FGT30Exxxxxxx |
Um einen bestimmten User von der FortiGate aus zu deregistrieren kann das mit dem folgenden Befehl erreicht werden:
| Konfiguration über die CLI:
|
# diag endpoint registration deregister <FortiClient UID> Zum Beispiel: # diag endpoint registration deregister B209297BF1F44F88BC7CD8CBF62AD2F9 Um alle User in einem zu deregistrieren: # diag endpoint registration deregister all |
Um die ganze Endpoint Registration zu lösen muss die Telemetrie auf dem entsprechenden VPN Interface deaktiviert werden:
| Konfiguration über die CLI:
|
# config system interface # edit <tunnel.interface> # set fortiheartbeat disable # end |
Wie konfiguriere ich einen Remoteaccess von einem FortiExtender 4G zu einer FortiGate?
Der FortiExtender kann nicht nur für ein zweites Standbein zum Internet verwendet werden, sondern auch als eigenständiges Gerät welches ermöglicht, dass FortiGate mit einem IPSEC-Tunnel über 4G zu erreichen.
Lokal angeschlossene Geräte hinter dem FortiExtender können dann auf interne Ressourcen hinter einer FortiGate zugreifen.
| Prinzip Schema: |
|
|
Der FortiExtender muss lokal oder über die FortiExtender-Cloud administriert werden. Er kann nicht direkt über die FortiGate konfiguriert werden.
Auf dem LAN Interfaces des FortiExtenders empfiehlt es sich ein DHCP Server zu konfigurieren:
| Konfiguration über die CLI:
|
|
Konfiguration DHCP Server auf dem LAN Interface im FortiExtender:' # config system dhcpserver # edit 1 # set status enable # set lease-time 86400 # set dns-service specify # set dns-server1 [DNS-Server1_IP] # set dns-server2 [DNS-Server2_IP] # set-ntp-service specify # set ntp-server1 [ntp-server1_IP] # set default-gateway [IP_Default Gateway] -> 192.168.46.1 # set netmask [Subnetzmaske] -> 255.255.255.0 # set interface [Interface_dhcpServer] -> lan # set start-ip [IP-Range-Start] -> 192.168.46.10 # set end-ip [IP-Range Pool Ende] -> 192.168.46.100 # set mtu 1500 [MTU Werte anpassen – default 1500] # end |
Konfigurieren des IPSEC Tunnels auf dem FortiExtender:
| Konfiguration über das WebGui:
| ||
Konfigurieren der Phase 1:
Konfigurieren der Phase 2:
Es ist darauf zu achten, dass alle Phase2-Parameter auf der FortiGate genau gleich konfiguriert werden. Policy Route konfigurieren:
Diese Route ist nichts Anderes als eine Standardroute, die auf den IPSEC-Tunnel (target.Home) zeigt. Policy konfigurieren:
Wenn man von den Netzen hinter der FortiGate auf das lokale Netz vom Extender zugreiffen will, muss noch eine Bi-Direktionale Policy konfiguriert werden. |
Konfigurieren des Tunnels auf der FortiGate:
Auf der FortiGate wird ein Site-to-Site VPN konfiguriert. Wir benutzen aber als Remote Gateway einen Dial-up User und erkennen mittels der ID die Remote-Seite.
| Konfiguration über das WebGui:
|
Netzwerk Einstellungen konfigurieren:
Authentifikation konfigurieren:
Phase 1 Parameter konfigurieren:
Phase 2 Parameter konfigurieren:
Konfiguration der Routen:
Die Blackhole-Route wird wie folgt konfiguriert:
Wer mehr über Blackhole-Route wissen möchte, kann dies im folgenden Artikel nachlesen: Konfigurieren der Firewall Regeln Die erste Regel steuert die Kommunikation vom Remote Netzwerk (192.168.46.0/24) auf die lokalen Ressourcen in unserem Netz. Unser Netz hat in diesem Beispiel den Wert 10.60.60.0/24. In dieser Regel wird die NAT Option deaktiviert (wir wollen kein Source NAT durchführen). Danach braucht es noch eine zweite Regel für den Internet Zugang: Source ist das Remote Netzwerk (192.168.46.0/24), die Destination ist das Internet Interface (meistens wan1) und das Adressobjekt all. Danach können die gewünschten Services angewählt werden. Hier müssen wir die NAT Option aktivieren. Es empfiehlt sich auch UTM-Features zu konfigurieren, um einen optimalen Schutz zu gewährleisten. Regelwerk auf der FortiGate: Wenn man ein Netzwerk hinter dem FortiExtender erreichen will, muss eine entsprechende Policy in die Gegenrichtung konfiguriert werden. Falls man einen lokalen DNS erreichen will, muss man dafür auch noch eine Regel konfigurieren! |
| Konfiguration über die CLI:
|
|
Konfiguration in der CLI mit folgenden Annahmen: Netzwerk Lan FortiGate : 10.60.60.0/24 Netzwerk Lan Extender : 192.168.46.0/24 Local ID Extender : KRIZ-SE Konfiguration VPN-Tunnel: config vpn ipsec phase1-interface
edit "VPN_extender"
set type dynamic
set interface "wan1"
set mode aggressive
set peertype one
set net-device disable
set proposal aes256-sha256
set dpd on-idle
set comments "VPN-Verbindung zu Außenstelle mit FortiExtender"
set dhgrp 14
set peerid "KRIZ-SE"
set psksecret [Pre-Shared-Key eingeben]
set dpd-retryinterval 60
next
end
config vpn ipsec phase2-interface
edit "Phase2-VPN-to_Extender"
set phase1name "VPN_extender"
set proposal aes256-sha256
set dhgrp 14
set keylifeseconds 43200
set src-subnet 0.0.0.0 0.0.0.0
set dst-subnet 192.168.46.0 255.255.255.0
next
end
Konfiguration Routen: config router static
edit 1
set dst 192.168.46.0 255.255.255.0
set device "VPN_extender"
set comment "Remote Netz VPN Extender"
next
edit 2
set dst 192.168.46.0 255.255.255.0
set distance 254
set comment "Blackhole Route - VPN Extender"
set blackhole enable
next
end
Konfiguration Adressen Objekte: config firewall address
edit "net-remote-vpn-192.168.46.0-24"
set comment "Remote VPN Netz - Extender"
set color 10
set subnet 192.168.46.0 255.255.255.0
next
edit "net-internal-10.60.60.0-24"
set comment "internal Network Ruesch"
set color 3
set subnet 10.60.60.0 255.255.255.0
next
end
Konfiguration Firewall Regeln: config firewall policy
edit 1
set name "I_VPN-extender->LAN"
set srcintf "VPN_extender"
set dstintf "internal"
set srcaddr "net-remote-vpn-192.168.46.0-24"
set dstaddr "net-internal-10.60.60.0-24"
set action accept
set schedule "always"
set service "ALL"
set logtraffic all
next
edit 2
set name "I_VPN-extender->INTERNET"
set srcintf "VPN_extender"
set dstintf "wan1"
set srcaddr "net-remote-vpn-192.168.46.0-24"
set dstaddr "all"
set action accept
set schedule "always"
set service "ALL"
set utm-status enable
set ssl-ssh-profile "certificate-inspection"
set av-profile "default"
set webfilter-profile "default"
set logtraffic all
set nat enable
next
end
|
vielen Dank an Robert Kříž von Fortinet Schweiz
High Availability
Wie wird ein HA-Failover Cluster erstellt?
Dieser Artikel beschreibt, wie ein HA Failover Cluster mit Fortigate Firewalls unter FortiOS 6.01 erstellt werden kann. Ziel ist untenstehendes Szenario:
Vorbedingungen:
Eine HA Konfiguration setzt einige Vorbedingungen für beide Geräte voraus. Ein HA-Cluster kann nur erstellt werden wenn folgende Eigenschaften bei beiden Maschinen identisch sind:
- Gerätetyp (z.b: 2x Fortigate 200D)
- Revision
- Firmware
- FortiGuard Lizenzen
- Operating Mode (Transparent oder NAT)
- Festplattenkapazität
Wenn eines der beiden Geräte einen tieferen Lizenzstatus hat (weniger Funktionen lizenziert, oder kürzere Laufzeit) dann wird der gesamte Cluster automatisch auf diesen tieferen Lizenzstatus heruntergesetzt.
1. Konfiguration des Hostnamen auf dem Master
|
|
Bitte konfiguriere den Devicenamen auf dem Gerät, welches später die Rolle des Masters übernehmen soll. Diese Einstellung ist zu finden unter System -> Settings -> Hostname |
2. Aktivieren der HA Funktion auf dem Master
|
|
Anschliessend kann die HA-Funktion auf dem Master unter System -> HA aktiviert werden.
|
3. Aktivieren der HA Funktion auf dem Slave
|
|
Nun kann die HA-Funktion auf dem Slave ebenfalls System -> HA aktiviert werden.
|
Sobald sich die beiden Clustermember nun über ein Heartbeat Interfaces sehen, beginnen sie den Cluster zu bilden. Der Slave wird neu gestartet und allenfalls mit der Konfiguration des Masters überschrieben. Nach einem Reboot sollte unter System -> HA eine Übersicht über den Clusterstatus zu sehen sein:
Auch auf der Konsole kann der Status angeschaut werden:
| Konfiguration über die CLI:
|
fgt200-master # get system ha status HA Health Status: OK Model: FortiGate-200D Mode: HA A-P Group: 0 Debug: 0 Cluster Uptime: 0 days 00:07:01 Cluster state change time: 2018-07-17 16:34:31 Master selected using: <2018/07/17 16:34:31> FG200D3916811639 is selected as the master because it has the largest value of override priority. <2018/07/17 16:28:53> FG200D3916811639 is selected as the master because it's the only member in the cluster. ses_pickup: enable, ses_pickup_delay=disable override: enable Configuration Status: FG200D3916811639(updated 1 seconds ago): in-sync FG200D3916811425(updated 1 seconds ago): in-sync System Usage stats: FG200D3916811639(updated 1 seconds ago): sessions=22, average-cpu-user/nice/system/idle=0%/0%/0%/100%, memory=13% FG200D3916811425(updated 1 seconds ago): sessions=19, average-cpu-user/nice/system/idle=0%/0%/0%/100%, memory=12% HBDEV stats: FG200D3916811639(updated 1 seconds ago): port15: physical/1000auto, up, rx-bytes/packets/dropped/errors=1551614/2217/0/0, tx=1647198/2222/0/0 port16: physical/1000auto, up, rx-bytes/packets/dropped/errors=1524874/2093/0/0, tx=1536540/2054/0/0 FG200D3916811425(updated 1 seconds ago): port15: physical/1000auto, up, rx-bytes/packets/dropped/errors=1649104/2225/0/0, tx=1561984/2232/0/0 port16: physical/1000auto, up, rx-bytes/packets/dropped/errors=1537302/2055/0/0, tx=1532880/2104/0/0 MONDEV stats: FG200D3916811639(updated 1 seconds ago): port1: physical/1000auto, up, rx-bytes/packets/dropped/errors=266700/1415/0/0, tx=1429610/1381/0/0 wan1: physical/1000auto, up, rx-bytes/packets/dropped/errors=108967/614/0/0, tx=50166/420/0/0 FG200D3916811425(updated 1 seconds ago): port1: physical/1000auto, up, rx-bytes/packets/dropped/errors=356552/1565/0/0, tx=1684592/1618/0/0 wan1: physical/1000auto, up, rx-bytes/packets/dropped/errors=122941/623/0/0, tx=37058/345/0/0 Master: fgt200-master , FG200D3916811639, cluster index = 0 Slave : fgt200-slave , FG200D3916811425, cluster index = 1 number of vcluster: 1 vcluster 1: work 169.254.0.1 Master: FG200D3916811639, operating cluster index = 0 Slave : FG200D3916811425, operating cluster index = 1 |
Achtung hierbei:
Status: OK
heisst nicht zwingend, dass der Cluster wirklich OK ist. Eine genauere Analyse des Outputs ist erforderlich. So kann der Clustermember auch Status: OK haben, wenn nur ein Clustermember online ist. Dies würde beispielsweise mit folgendem Output vermerkt:
Master selected using: <2018/07/17 16:12:40> FG200D3916811639 is selected as the master because it's the only member in the cluster.
Anpassen des Failover Verhaltens
Wird obenstehendes Szenario realisiert, so wird nach der Bildung des Clusters der Member mit der Priorität=128 zum Master erkoren. Fällt der Master aus, übernimmt der Slave. Nachdem der ursprüngliche Master wieder verfügbar wird, wird jedoch der Master-Status nicht wieder an die Unit mit der Prio 128 zurückgegeben. Dieses Verhalten kann jedoch forciert werden, indem in der ha-Konfig im CLI override eingeschaltet wird:
| Konfiguration über die CLI:
|
fg20-master# config system ha fg20-master (ha) # set override enable fg20-master (ha) # end |
Führen des HA-Links über eine öffentliche Infrastruktur
Der HA-Traffic wird standardmässig nicht verschlüsselt. Muss der HA-Traffic über eine öffentliche Infrastruktur geführt werden, so empfiehlt es sich, die Authentifizierung sowie die Verschlüsselung dieses Traffics einzuschalten. Dies muss auf dem Master sowie auch auf dem Slave konfiguriert werden.
| Konfiguration über die CLI:
|
fg20-master# config system ha fg20-master (ha) # set authentication enable fg20-master (ha) # set encryption enable fg20-master (ha) # end |
| Konfiguration über die CLI:
|
fg20-slave # config system ha fg20-slave (ha) # set authentication enable fg20-slave (ha) # set encryption enable fg20-slave (ha) # end |
Anschliessend empiehlt es sich, beide Clustermember neu zustarten, damit die HA Verbindung neu ausgehandelt wird.
Handling der Management Interfaces
Bei grösseren Umgebungen existiert gemäss Best-Practices oftmals ein Management Netzwerk. Es empfiehlt sich, beide Cluster Nodes mit einem Management Port in diesem Management Netzwerk zu platzieren. Somit kann im Notfall auch via dieses Netzwerk auf beide Cluster Nodes zugegriffen werden. Damit dies funktioniert, muss zuerst auf dem Master in der HA Konfiguration definiert werden, welches Interface als Management Interface gewählt wird. Hierbei kann nicht das auf gewissen Appliances zur Verfügung stehende MGMT Interface gewählt werden. Diesem Management Interface kann ausserdem ein dedizierter, anderer DefaultGateway mitgegeben werden:
| Konfiguration über die CLI:
|
fgt200-master (ha) # show
config system ha
set ha-mgmt-status enable
config ha-mgmt-interfaces
edit 1
set interface "port14"
set gateway 192.168.11.1
next
end
end
|
Anschliessend kann der gewählte Port auf beiden Units unterschiedlich konfiguriert werden.
Auf dem Master:
| Konfiguration über die CLI:
|
config system interface
edit "port14"
set ip 192.168.11.10 255.255.255.0
set allowaccess https ssh snmp fgfm ftm
next
end
|
Auf dem Slave:
| Konfiguration über die CLI:
|
config system interface
edit "port14"
set ip 192.168.11.11 255.255.255.0
set allowaccess https ssh snmp fgfm ftm
next
end
|
Wie kann ich im Cluster mich von der aktiven auf die passive Fortigate verbinden?
Falls man den Clustermembers keine dedizierte Management IP Adresse vergibt, kann man immer nur den aktiven Member per IP Adresse managen. Es gibt die Möglichkeit über die CLI den passiven Member anzusprechen. Dafür muss man die Device ID des passiven Members ermitteln. Dies funktioniert folgendermassen:
| Konfiguration über die CLI:
|
fw-master # execute ha manage ? fw-master # <id> please input peer box index. fw-master # <0> Susidary unit FGT60Exxxxxxxxxxd |
In diesem Fall ist dies die ID des passiven Devices 0
Nun kann man sich mit dem selben Befehl auf den passiven Member verbinden:
| Konfiguration über die CLI:
|
fw-master # execute ha manage <HA_device_index> fw-master # execute ha manage 0 fw-slave login: admin Password: ******** Welcome! fw-slave $ |
Es wird der Hostname des Slavey angezeigt, gefolgt von einem Dollar ($) Zeichen.
Um den Slave wieder zu verlassen kann der Befehl exit benutzt werden:
| Konfiguration über die CLI:
|
fw-slave $ exit fw-master # |
Was bedeutet die Meldung "slave and master have different hdisk status" in der CLI?
Beim Konfigurieren eines FortiGate HA-Clusters kann auf der Konsole auf dem passiven/Sekundären Gerät die folgende Meldung angezeigt werden:
slave and master have different hdisk status. Cannot work with HA master. Shutdown the box! The system is halted."
Mögliche Ursachen für diese Fehlermeldungen sind:
Möglichkeit 1 - Keine Disk im Device
Bei einem der FortiGate Devices handelt es sich um ein Modell bei welchem keine Harddisk vorhanden ist.
Dies kann über die CLI folgendermassen überprüft werden:
| Konfiguration über die CLI:
|
# get system status
Version: FortiGate-300D v6.4.1,build1637,200604 (GA)
Virus-DB: 78.00196(2020-06-15 22:20)
Extended DB: 78.00196(2020-06-15 22:20)
Extreme DB: 1.00000(2018-04-09 18:07)
IPS-DB: 15.00864(2020-06-15 02:16)
IPS-ETDB: 6.00741(2015-12-01 02:30)
APP-DB: 15.00864(2020-06-15 02:16)
INDUSTRIAL-DB: 6.00741(2015-12-01 02:30)
Serial-Number: FGT3HDxxxxxxxxx
IPS Malicious URL Database: 2.00675(2020-06-15 05:04)
BIOS version: 05000002
System Part-Number: P14814-04
Log hard disk: Not available <--- Information über die Disk
Hostname: alsochlu-sg0e1
Operation Mode: NAT
Current virtual domain: root
Max number of virtual domains: 10
Virtual domains status: 5 in NAT mode, 1 in TP mode
Virtual domain configuration: multiple
FIPS-CC mode: disable
Current HA mode: a-p, master
Cluster uptime: 914 days, 2 hours, 50 minutes, 7 seconds
Cluster state change time: 2020-06-10 13:38:01
Branch point: 1637
Release Version Information: GA
FortiOS x86-64: Yes
Wenn keine Disk vorhanden ist, wird man folgenden Output sehen: Wenn eine Disk vorhanden ist: |
Möglichkeit 2 - Beide FortiGate haben eine Disk aber eine der Disk ist nicht formatiert:
Eine weitere möglichkeit ist, dass eine der Disk auf der FortiGate nicht formatiert ist und daher auch nicht genutzt werden kann.
| Konfiguration über die CLI:
|
Möglichkeit 3 - Eine Disk ist defekt
Eines der FortiGate-Geräte hat einen Festplattenfehler. Es muss ein HQIP-Test durchgeführt werden. Wie man einen HQIP Test durchführt kann demfolgenden Artikel entnommen werden:
Danach mit dem Resultat ein Support RMA Case über https://support.fortinet.com eröffnen um das defekte Gerät austauschen zu lassen.
DoS
Wie kann ich die DoS Policy im FortiOS aktivieren?
Standardmässig sind die DoS Policy im FortiOS unter im Webgui nicht sichtbar. Diese müssen über die Feature-Einstellungen zuerst eingeschalten werden.
Um diese Sichtbar zu machen muss unter dem Menu System -> Feature Visibility der Schalter DoS Policy aktiviert werden.
Über die CLI kann man dies folgendermassen einschalten:
| Konfiguration über die CLI:
|
config system settings set gui-dos-policy enable end |
Wie konfiguriere ich eine DoS Regel auf der FortiGate?
Das Menu um eine DoS Policy zu konfigurieren findet man im Menu Policy & Objects -> IPv4 DoS Policy. Falls das Menu noch nicht vorhanden ist muss man es zuerst aktivieren:
FortiGate:FAQ#Wie_kann_ich_die_DoS_Policy_im_FortiOS_aktivieren.3F
Jetzt über das Menu 
kann eine neue Policy erstellt werden.
Nun kann das eingehende Interface definiert werden, die Source Adressen und die Destination Adressen. Weiter können die Services definiert werden, auf welche die DoS Regel zählen soll.
Für Eingehenden Traffic vom WAN Interface kann man sehr gut als Source ALL auswählen. Die Destination kann auch auf ALL gesetzt werden und die Services auch. Diese Regel wird dann als Implizit Regel konfiguriert, und alle Ausnahme Regeln vor dieser angelegten Implizit Regel.
DoS Regeln sichern in gewissem Sinne das Netzwerk gegen abnormale Verhaltensmuster im Netzwerktraffic ab. Die Vorgeschlagenen Werte von Fortinet sind Richtwerte aber nicht in Stein gemeisselt. Um sein Netzwerk richtig abzusichern empfiehlt es sich, zuerst die Regeln auf Monitoring zu setzen und zu tracken wie der Traffic im Netzwerk normal ist. So kann dann der Schwellwert entsprechend angepasst werden. Man nimmt den gewünschten Schwellwert und rechnet noch eine Toleranz dazu. Zu beachten ist, je kleiner die Toleranz um so sicherer das Netz. Es muss aber auch beachtet werden, wenn die Toleranz zu klein ist, können auch Fehlalarme generiert werden.
Wo immer Vorsicht geboten ist, bei Voip Applikationen. Hier können schnell höhe Werte entstehen. Daher Empfiehlt es sich für den SIP Port (üblicherweise UDP5060) eine Ausnahme Regel zu definieren.
Auch in dem DoS Regelwerk wird die Reihenfolge von oben nach unten durchlaufen. Sobald ein Kriterium übereinstimmt wird die Regel beachtet und der Rest des DoS Regelwerk ignoriert. Daher macht es Sinn sich ein paar Gedanken zu machen.
Die Regeln kann man mit ziehen per Maus einfach an die gewünschte Position schieben.
| Konfiguration über die CLI:
|
config firewall DoS-policy
edit 1
set comments "DoS - implicit wan1"
set interface "wan1"
set srcaddr "all"
set dstaddr "all"
set service "ALL"
config anomaly
edit "tcp_syn_flood"
set log enable
set action block
set threshold 2000
next
edit "tcp_port_scan"
set log enable
set action block
set threshold 1000
next
edit "tcp_src_session"
set log enable
set action block
set threshold 5000
next
edit "tcp_dst_session"
set log enable
set action block
set threshold 5000
next
edit "udp_flood"
set log enable
set action block
set threshold 2000
next
edit "udp_scan"
set log enable
set action block
set threshold 2000
next
edit "udp_src_session"
set log enable
set action block
set threshold 5000
next
edit "udp_dst_session"
set log enable
set action block
set threshold 5000
next
edit "icmp_flood"
set log enable
set action block
set threshold 250
next
edit "icmp_sweep"
set log enable
set action block
set threshold 100
next
edit "icmp_src_session"
set log enable
set action block
set threshold 300
next
edit "icmp_dst_session"
set log enable
set action block
set threshold 1000
next
edit "ip_src_session"
set status enable
set log enable
set action block
set threshold 5000
next
edit "ip_dst_session"
set status enable
set log enable
set action block
set threshold 5000
next
edit "sctp_flood"
set log enable
set action block
set threshold 2000
next
edit "sctp_scan"
set log enable
set action block
set threshold 1000
next
edit "sctp_src_session"
set log enable
set action block
set threshold 5000
next
edit "sctp_dst_session"
set log enable
set action block
set threshold 5000
next
end
next
end
|
Was bedeuten die unterschiedlichen DoS Anomalien?
In der folgenden Tabelle kann entnommen werden, was mit den verschiedenen Anomalien gemeint ist und welche Schwellwerte auf der FortiGate vordefiniert sind:
| L3 Anomalie | Beschreibung | Vordefinierter Schwellwert |
|
ip_src_session |
Wenn die Anzahl der gleichzeitigen IP-Verbindungen von einer Quell-IP-Adresse den konfigurierten Schwellenwert überschreitet, wird die Aktion ausgeführt. |
5000 gleichzeitige Sessions |
|
ip_dst_session |
Wenn die Anzahl der gleichzeitigen IP-Verbindungen zu einer Ziel-IP-Adresse den konfigurierten Schwellenwert überschreitet, wird die Aktion ausgeführt. |
5000 gleichzeitige Sessions |
| L4 Anomalie | Beschreibung | Vordefinierter Schwellwert |
|
tcp_syn_flood |
Wenn die SYN-Paketrate neuer TCP-Verbindungen, einschliesslich der erneuten Übertragung, zu einer Ziel-IP-Adresse den konfigurierten Schwellenwert überschreitet, wird die Aktion ausgeführt. |
2000 Pakete pro Sekunde |
|
tcp_port_scan |
Wenn die SYN-Paketrate neuer TCP-Verbindungen, einschliesslich der erneuten Übertragung, von einer Source-IP-Adresse den konfigurierten Schwellenwert überschreitet, wird die Aktion ausgeführt. |
1000 Pakete pro Sekunde |
|
tcp_src_session |
Wenn die Anzahl der gleichzeitigen TCP-Verbindungen von einer Source-IP-Adresse den konfigurierten Schwellenwert überschreitet, wird die Aktion ausgeführt. |
5000 gleichzeitige Sessions |
|
tcp_dst_session |
Wenn die Anzahl der gleichzeitigen TCP-Verbindungen zu einer Destination-IP-Adresse den konfigurierten Schwellenwert überschreitet, wird die Aktion ausgeführt. |
5000 gleichzeitige Sessions |
|
udp_flood |
Wenn der UDP-Traffic zu einer Destination-IP-Adresse den konfigurierten Schwellenwert überschreitet, wird die Aktion ausgeführt. |
2000 Pakete pro Sekunde |
|
udp_scan |
Wenn die Anzahl der UDP-Session, die von einer Source-IP-Adresse stammen den konfigurierten Schwellenwert überschreitet, wird die Aktion ausgeführt. |
2000 Pakete pro Sekunde |
|
udp_src_session |
Wenn die Anzahl der gleichzeitigen UDP-Verbindungen von einer Source-IP-Adresse den konfigurierten Schwellenwert überschreitet, wird die Aktion ausgeführt. |
5000 gleichzeitige Sessions |
|
udp_dst_session |
Wenn die Anzahl der gleichzeitigen UDP-Verbindungen zu einer Destination-IP-Adresse den konfigurierten Schwellenwert überschreitet, wird die Aktion ausgeführt. |
5000 gleichzeitige Sessions |
|
icmp_flood |
Wenn die Anzahl der an eine Destination-IP-Adresse gesendeten ICMP-Pakete den konfigurierten Schwellenwert überschreitet, wird die Aktion ausgeführt. |
250 Pakete pro Sekunde |
|
icmp_sweep |
Wenn die Anzahl der ICMP-Pakete, die von einer Source-IP-Adresse stammen, den konfigurierten Schwellenwert überschreitet, wird die Aktion ausgeführt. |
100 Pakete pro Sekunde |
|
icmp_src_session |
Wenn die Anzahl der gleichzeitigen ICMP-Verbindungen von einer Source-IP-Adresse den konfigurierten Schwellenwert überschreitet, wird die Aktion ausgeführt. |
300 gleichzeitige Sessions |
|
icmp_dst_session |
Wenn die Anzahl der gleichzeitigen ICMP-Verbindungen zu einer Destination-IP-Adresse den konfigurierten Schwellenwert überschreitet, wird die Aktion ausgeführt. |
1000 gleichzeitige Sessions |
|
sctp_flood |
Wenn die Anzahl der an eine Ziel-IP-Adresse gesendeten SCTP-Pakete den konfigurierten Schwellenwert überschreitet, wird die Aktion ausgeführt. |
2000 Pakete pro Sekunde |
|
sctp_scan |
Wenn die Anzahl der SCTP-Sitzungen, die von einer Source-IP-Adresse stammen, den konfigurierten Schwellenwert überschreitet, wird die Aktion ausgeführt. |
1000 Pakete pro Sekunde |
|
sctp_src_session |
Wenn die Anzahl der gleichzeitigen SCTP-Verbindungen von einer Source-IP-Adresse den konfigurierten Schwellenwert überschreitet, wird die Aktion ausgeführt. |
5000 gleichzeitige Sessions |
|
sctp_dst_session |
Wenn die Anzahl der gleichzeitigen SCTP-Verbindungen zu einer Destination-IP-Adresse den konfigurierten Schwellenwert überschreitet, wird die Aktion ausgeführt. |
5000 gleichzeitige Sessions |
- Informationen über das SCTP Protokoll: https://www.ionos.de/digitalguide/server/knowhow/sctp-stream-control-transmission-protocol/
Wie kann ich für eine DoS Policy weitere Informationen für eine Analyse auflisten?
In der CLI steht für eine DoS Policy folgendes Kommando zur Verfügung:
# diagnose ips anomaly [clear | config | filter | list | status]
Die verschiedenen Optionen für "ips anomaly" haben folgende Bedeutung:
• clear löscht die anomaly meters
• config listet die DOS-sensoren auf
• filter listet den "anomaly" filter auf
• list listet die "anomaly" meters auf
• status listet den "anomaly" status auf
Somit kann zBsp mit folgendem Befehl die konfigurierten DoS Policies aufgelistet werden:
# diagnose ips anomaly config
DoS sensors in kernel vd 0:
DoS id 2 proxy 0
0 tcp_syn_flood status 0 log 0 nac 0 action 0 threshold 2000
1 tcp_port_scan status 0 log 0 nac 0 action 0 threshold 1000
2 tcp_src_session status 1 log 1 nac 1 action 7 threshold 100
3 tcp_dst_session status 0 log 0 nac 0 action 0 threshold 5000
4 udp_flood status 0 log 0 nac 0 action 0 threshold 2000
5 udp_scan status 0 log 0 nac 0 action 0 threshold 2000
6 udp_src_session status 0 log 0 nac 0 action 0 threshold 5000
7 udp_dst_session status 0 log 0 nac 0 action 0 threshold 5000
8 icmp_flood status 0 log 0 nac 0 action 0 threshold 250
9 icmp_sweep status 0 log 0 nac 0 action 0 threshold 100
10 icmp_src_session status 0 log 0 nac 0 action 0 threshold 300
11 icmp_dst_session status 0 log 0 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
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 0 nac 0 action 0 threshold 1000
2 tcp_src_session status 1 log 0 nac 0 action 0 threshold 5000
3 tcp_dst_session status 1 log 0 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 0 nac 0 action 0 threshold 2000
6 udp_src_session status 1 log 0 nac 0 action 0 threshold 5000
7 udp_dst_session status 1 log 0 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 0 nac 0 action 0 threshold 100
10 icmp_src_session status 1 log 0 nac 0 action 0 threshold 300
11 icmp_dst_session status 1 log 0 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
total # DoS sensors: 2.
Nachfolgender Befehl listet alle IPv4 Adressen auf für welche ein "match" der DoS Policy ausgeführt wurde. Diese Liste zeigt nicht zwingend IPv4 Adressen die eine Attacke durchgeführt haben. Die Position "exp" (expiration) zeigt den Wert in Sekunden nachdem ein entsprechender Eintrag entfernt wird sofern kein weiterer "match" betreffend der IPv4 Adresse für diesen DoS Policy Eintrag stattfindet. Die Position "pps" (packet per second) zeigt an wieviele Packete pro Sekunden für die IPv4 Adressen registriert wurde. Die Position "freq" (frequency) zeigt die Frequenz für eine spezifische IPv4 Adresse für die eine DoS anomaly erkannt wurde:
# diagnose ips anomaly list
list nids meter:
id=udp_flood ip=198.41.0.4 dos_id=1 exp=988 pps=1 freq=6
id=udp_dst_session ip=198.41.0.4 dos_id=1 exp=5990 pps=0 freq=0
id=udp_scan ip=193.193.135.65 dos_id=1 exp=988 pps=2 freq=3
id=udp_src_session ip=193.193.135.65 dos_id=1 exp=5990 pps=0 freq=0
id=udp_flood ip=193.193.135.66 dos_id=1 exp=880 pps=3 freq=3
id=udp_flood ip=192.228.79.201 dos_id=1 exp=967 pps=0 freq=1
id=udp_dst_session ip=192.228.79.201 dos_id=1 exp=5969 pps=0 freq=0
total # of nids meters: 7.
Wenn durch "list" eine grosse Liste von Informationen ausgegeben wird kann diese mittels folgendem Befehl gefilter werden:
# diagnose ips anomaly filter
clear Clear anomaly filter.
id Anomaly ID.
ip IP and subnet mask.
pps pps
freq frequency
Der Status des Filters kann mit folgendem Befehl aufgelistet werden:
# diagnose ips anomaly filter
anomaly filter:
id any
ip 0.0.0.0 mask 0.0.0.0
nps 0 - 0
freq 0 - 0
Somit kann zBsp ein anhand eine Policy ID (id) oder zBsp anhand eine IPv4 Adresse (ip) ein Filter gesetzt werden:
# diagnose ips anomaly filter id 1
# diagnose ips anomaly filter
anomaly filter:
id 1
ip 0.0.0.0 mask 0.0.0.0
nps 0 - 0
freq 0 - 0
# diagnose ips anomaly filter ip 198.41.0.4 255.255.255.255
# diagnose ips anomaly filter
anomaly filter:
id 1
ip 198.41.0.4 mask 255.255.255.255
nps 0 - 0
freq 0 - 0
Um den Filter zurück zu setzen führe ein "clear" aus:
# diagnose ips anomaly filter clear
# diagnose ips anomaly filter
anomaly filter:
id 0
ip 0.0.0.0 mask 0.0.0.0
nps 0 - 0
freq 0 - 0
Botnet
Wie schalte ich den Botnet- und CC-Schutz auf der FortiGate ein? (bis FortiOS 6.0)
Im FortiOS 6.0 kann das Feature auf dem ausgehenden Interface Richtung Internet aktiviert werden. Das Interface muss in der Rolle WAN oder undefined sein.
| Konfiguration über das WebGui:
|
|
Wenn man auf botnet packages klickt kann man die Liste aufrufen, aus welcher ersichtlich ist, welche Botnetze und C&C Netze bekannt sind. |
| Konfiguration über die CLI:
|
config system interface
edit wan1
set scan-botnet-connections block
next
end
|
Wie schalte ich den Botnet und CC Schutz auf der FortiGate ein? (ab FortiOS 6.2)
]]
Im Gegensatz zum FortiOS 6.0 wird ab FortiOS 6.2 der Botnet- und C&C-Schutz über ein IPS Profil konfiguriert, welches in einer Firewall Regel aktiviert werden muss.
Hierfür muss eventuell bei den Features die Intrusion Prevention Option eingeschaltet werden:
| Konfiguration über das WebGui:
|
|
Unter dem Menupunkt System -> Feature Visibility muss das Feature IPS Feature aktiviert werden. |
|
Jetzt kann unter den Security Profilen ein neues IPS Profil angelegt werden. |
|
Das IPS Profil muss jetzt an eine Policy gebunden werden: |
| Konfiguration über die CLI:
|
|
IPS Feature einschalten: config system settings
set gui-ips enable
end
IPS Profil anlegen: config ips sensor
edit "Botnet-Sensor"
set scan-botnet-connections block
next
end
IPS Profil in einer Policy aktivieren: config firewall policy
edit 1
set name "O_internal->Internet-all"
set srcintf "internal"
set dstintf "wan1"
set srcaddr "net-192.168.1.0-24"
set dstaddr "net-0.0.0.0-00"
set action accept
set schedule "always"
set service "ALL"
set utm-status enable
set logtraffic all
set ips-sensor "Botnet-Sensor"
set nat enable
next
end
|
Im Log sehen wir die geblockten Events am folgenden Ort:
| Konfiguration über das WebGui:
|
|
Im Menu über Log & Report -> Intrusion Prevention
Wenn der Event angeklickt wird, können noch mehr Details entnommen werden:
|
Antivirus
Wo finde ich auf der FortiGuard Support Seite mehr Informationen betreffend den Antivirus Database Inhalte?
Auf der Website von FortiGuard ist ebenfalls die Option «Antivirus» ausgewiesen (https://www.fortiguard.com/updates/antivirus). Dort wird fortlaufend auf die aktuelle Version (latest version) hingewiesen inkl. den zuletzt erkannten Viren.
Unter Services -> Anti-Virus 
sind weitere Informationen zum Produkt aufgelistet sind. Des Weiteren kann ein "Schnelltest" einer verdächtigen Datei vorgenommen werden.
Erweiterte Produkte-Infos sind unter folgendem Link zu finden:
https://www.fortinet.com/support/support-services/fortiguard-security-subscriptions/antivirus
Wie kann ich die AntiVirus Datenbank auf der FortiGate aktuell halten?
Die Antivirus Datenbank der FortiGate kann mit der Push Methode, der Schedule Methode oder auch mittels Kombination beider Methoden geupdated werden.
Die Schedule Methode (geplannte Methode) ermöglicht es, dass in regelmässigen Abständen ein Update der Datenbank vorgenommen wird. Man kann zwischen stündlich, täglich oder wöchentlich auswählen.
Mit der Push Option werden Push-Aktualisierungen akzeptiert. Das heisst, sobald eine neue Definition in der FortiGuard propagiert wird, bekommt die FortiGate ein Update gepusht. Die Push-Option stellt so sicher, dass die Antivirus Datenbank auf der FortiGate so aktuell wie möglich ist. Diese Option empfiehlt sich besonders in Hochsicherheitsumgebungen.
| Konfiguration über das WebGui:
|
|
Über das Menu System -> FortiGuard nach unten scrollen bis man den folgenden Menu-Abschnitt findet:
|
| Konfiguration über die CLI:
|
config system autoupdate push-update set status [enable|disable] end Autoupdate konfigurieren Syntax: config system autoupdate schedule set status [Enable|disable] --> aktivieren oder deaktivieren set frequency [every|daily|weekly] --> Intervall für Update eingeben (alle n Stunden, täglich, wöchentlich) set time [hh:mm] --> hh:[1-23] Stunden, mm: [0-59] Minuten. Für Zufall innerhalb 1 Stunde mm auf 60 einstellen. end Beispiel Autoupdate alle zwei Stunden konfigurieren: config system autoupdate schedule set status enable set frequency every set time 02:60 end |
Ein Update der verschiedenen UTM Databases kann mittels folgendem Befehl auch manuell ausgeführt werden:
# execute update-now
Desweiteren stehen folgende Befehle zur Verfügung um spezifische Databases auf den neusten Stand zu bringen:
# execute update-av Update AV engine/definitions
# execute update-geo-ip Update IP Geography DB
# execute update-ips Update IPS engine/definitions
# execute update-list Download update server list
# execute update-netscan Update netscan object
# execute update-src-ivs Update src-vis object
|
|
Egal welche Methode gewählt wird, die Virenüberprüfung muss mindestens bei einer Firewall-Policy aktiviert sein. Ist dies nicht der Fall, wird die FortiGate keine Updates herunterladen. |
Die Botnet-IPs und Botnet-Domänen Lizenz ist ab FortiOS 6.0.1 Teil der FortiGuard AntiVirus-Lizenz.
Wie kann ich auf der FortiGate die einzelnen Versionen der UTM Database überprüfen?
Auf einer FortiGate existieren etliche UTM Databases für die verschiedenen Funktionen wie IPS, Antivirus, GeoIP, Certification List usw. Diese werden laufend durch die Funktion "autoupdate" auf dem neusten Stand gehalten. Die aktuelle Konfiguration der Funktion "autoupdate" kann folgendermassen abgerufen werden:
# get system auto-update status
FDN availability: unavailable at Tue Jan 5 18:13:39 2016
Push update: disable
Scheduled update: enable
Update every: 6 hours at 0 minutes after the hour
Virus definitions update: enable
IPS definitions update: enable
Push address override: disable
Web proxy tunneling: disable
Nachdem die UTM Databases auf den neusten Stand gebracht wurden, können die verschiedenen detaillierten Informationen der Databases durch folgende Befehl abgerufen werden:
# get system auto-update version
AV Engine
---------
Version: 5.00227
Contract Expiry Date: n/a
Last Updated using manual update on Tue Dec 8 10:57:00 2015
Last Update Attempt: Tue Jan 5 12:33:50 2016
Result: Updates Installed
Virus Definitions
---------
Version: 16.00560
Contract Expiry Date: n/a
Last Updated using manual update on Fri Oct 19 08:31:00 2012
Last Update Attempt: Tue Jan 5 12:33:50 2016
Result: Updates Installed
Extended set
---------
Version: 1.00000
Contract Expiry Date: n/a
Last Updated using manual update on Wed Oct 17 15:46:00 2012
Last Update Attempt: Tue Jan 5 12:33:50 2016
Result: Updates Installed
Mobile Malware Definitions
---------
Version: 0.00000
Contract Expiry Date: n/a
Last Updated using manual update on Mon Jan 1 00:00:00 2001
Last Update Attempt: Tue Jan 5 12:33:50 2016
Result: Updates Installed
Attack Definitions
---------
Version: 6.00741
Contract Expiry Date: n/a
Last Updated using manual update on Tue Dec 1 02:30:00 2015
Last Update Attempt: Tue Jan 5 12:33:50 2016
Result: Updates Installed
Attack Extended Definitions
---------
Version: 0.00000
Contract Expiry Date: n/a
Last Updated using manual update on Mon Jan 1 00:00:00 2001
Last Update Attempt: Tue Jan 5 12:33:50 2016
Result: Updates Installed
IPS Malicious URL Database
---------
Version: 1.00001
Contract Expiry Date: n/a
Last Updated using manual update on Thu Jan 1 01:01:00 2015
Last Update Attempt: Tue Jan 5 12:33:50 2016
Result: Updates Installed
Flow-based Virus Definitions
---------
Version: 1.00123
Contract Expiry Date: n/a
Last Updated using manual update on Tue Jul 21 14:19:00 2015
Last Update Attempt: Tue Jan 5 12:33:50 2016
Result: Updates Installed
Botnet Definitions
---------
Version: 1.00000
Contract Expiry Date: n/a
Last Updated using manual update on Mon May 28 22:51:00 2012
Last Update Attempt: Tue Jan 5 12:33:50 2016
Result: Updates Installed
IPS Attack Engine
---------
Version: 3.00156
Contract Expiry Date: n/a
Last Updated using manual update on Thu Dec 10 13:40:00 2015
Last Update Attempt: Tue Jan 5 12:33:50 2016
Result: Updates Installed
Internet-service Database Apps
---------
Version: 2.00662
Contract Expiry Date: n/a
Last Updated using manual update on Tue Nov 17 11:56:00 2015
Last Update Attempt: Tue Jan 5 12:33:50 2016
Result: Updates Installed
Internet-service Database Maps
---------
Version: 0.00000
Contract Expiry Date: n/a
Last Updated using manual update on Mon Jan 1 00:00:00 2001
Last Update Attempt: Tue Jan 5 12:33:50 2016
Result: Updates Installed
Botnet Domain Database
---------
Version: 0.00000
Contract Expiry Date: n/a
Last Updated using manual update on Mon Jan 1 00:00:00 2001
Last Update Attempt: Tue Jan 5 12:33:50 2016
Result: Updates Installed
Vulnerability Compliance and Management
---------
Version: 1.00297-L
Contract Expiry Date: n/a
Last Updated using manual update on Fri Dec 4 19:31:00 2015
Last Update Attempt: n/a
Result: Updates Installed
Modem List
---------
Version: 0.000
Device and OS Identification
---------
Version: 1.00040
Contract Expiry Date: n/a
Last Updated using manual update on Tue Jan 5 17:26:00 2016
Last Update Attempt: Tue Jan 5 12:33:50 2016
Result: Updates Installed
IP Geography DB
---------
Version: 1.044
Contract Expiry Date: n/a
Last Update Date: Wed Dec 2 22:57:32 2015
Certificate Bundle
---------
Version: 1.00001
Last Update Date: Wed Nov 4 16:07:00 2015
FDS Address
---------
URL White list
---------
Version: 0.00000
Contract Expiry Date: n/a
Last Updated using manual update on Mon Jan 1 00:00:00 2001
Last Update Attempt: Tue Jan 5 12:33:50 2016
Result: Updates Installed
Des Weiteren steht nachfolgendes Kommando zur Verfügung welches die einzelnen Antivirus Datenbanken, sowie dessen Inhalt / Einträge auflistet:
# diagnose antivirus database-info
Welche AntiVirus Datenbanken gibt es auf der FortiGate?
Es gibt mehrere FortiGuard-Antiviren-Datenbanken, die mit dem CLI-Befehl "config antivirus setting" konfiguriert werden können. Die Unterstützung für die einzelnen Datenbanktypen variiert je nach FortiGate-Modell.
Alle FortiGate-Geräte enthalten die normale Datenbank. Die normale Datenbank enthält Signaturen für Viren, die in den letzten Monaten erkannt wurden und durch das FortiGuard Global Security Research Team ermittelt wurden. Sie ist die kleinste Datenbank und führt daher die schnellsten Überprüfungen durch. Diese Datenbank erkennt jedoch nicht alle bekannten Viren.
Die meisten FortiGate-Modelle unterstützen die erweiterte Datenbank. Die erweiterte Datenbank erkennt auch Viren welche nicht mehr aktiv sind. Viele gängige Plattformen sind immer noch anfällig für diese Viren, oder diese könnten zu einem späteren Zeitpunkt ein Problem darstellen.
Die Extreme-Datenbank ist für den Einsatz in Hochsicherheitsumgebungen vorgesehen. Die Extremdatenbank erkennt alle bekannten Viren, auch solche, welche es auf ältere Betriebssysteme absehen, welche nicht mehr weit verbreitet sind.
FortiGuard Antivirus Datenbanken:
Normal - enthält häufige aktuelle Angriffe und ist für alle Modelle verfügbar. Alle FortiGate-Geräte enthalten die normale Datenbank. Die normale Datenbank enthält Signaturen für Viren, die in den letzten Monaten erkannt wurden und vom FortiGuard Global Security Research Team ermittelt wurden. Sie ist die kleinste Datenbank und führt daher die schnellsten Überprüfungen durch. Diese Datenbank erkennt jedoch nicht alle bekannten Viren.
Extended - umfasst normale und zusätzliche neuere aktuell nicht aktive Viren. Viele gängige Plattformen sind immer noch anfällig für solche Viren, welche später ein Problem darstellen könnten.
Extreme - umfasst "extended" und zusätzlich ruhende Viren. Sie ist für den Einsatz in Hochsicherheitsumgebungen vorgesehen. Die Extremdatenbank erkennt alle bekannten Viren, auch solche, die auf ältere Betriebssysteme abzielen welche nicht mehr weit verbreitet sind.
Ab :
FortiGate verwendet die Erweiterte DB als Standard-AntiVirus-DB.
Die Option "Normale DB" wird nicht mehr unterstützt.
Für FortiGate-Modelle welche die Extreme DB unterstützen, steht die Option zwischen "Extended DB" oder "Extreme DB" zur Auswahl.
Unter "Antiviren-Einstellungen konfigurieren" wurde der Parameter default-db entfernt.
FortiGate-Modelle, die Extreme-Set-Datenbanken unterstützen, haben den neuen Parameter use-extreme-db.
Standardmäßig ist use-extreme-db deaktiviert, so dass die FortiGate die normalen und Extended-Set-Datenbanken verwendet.
Wenn use-extreme-db aktiviert ist, wird von der FortiGate die Extreme-Set-Datenbank verwendet
AntiVirus settings in the CLI.
- On low end models, use-extreme-db is hidden.
This example shows the CLI captured on FortiGate-101E.
(settings) # show full-configuration
# config antivirus settings
set grayware enable
set override-timeout 0
end
- On higher end models, use-extreme-db is available.
This example shows the CLI captured on FortiGate-600D.
(settings) # show full-configuration
# config antivirus settings
set use-extreme-db enable
set grayware enable
set override-timeout 0
end
(settings)set use-extreme-db ?
enable <----- Enable extreme AVDB.
disable <----- Disable extreme AVDB.
Wie kann ich unter auf der FortiGate für die "autoupdate" Funktion der UTM Databases einen explizit Proxy konfigurieren?
Ein FortiOS resp. eine FortiGate benutzt um deren UTM Databases auf den neusten Stand zu bringen die "autoupdate" Funktion. Weitere Informationen zu dieser "autoupdate" Funktion siehe nachfolgender Artikel:
FortiGate-6.0-6.4: AQ#Wie_kann_ich_die_AntiVirus_Datenbank_auf_der_FortiGate_aktuell_halten.3F
Diese "autoupdate" Funktion benützt keine explizit Proxy Konfiguration, sondern ist transparent. Dies bedeutet: Soll die "autoupdate" Funktion über einen explizit Proxy durchgeführt werden, so muss dies über die CLI konfiguriert werden! Bei dieser explizit Proxy Konfiguration für "autoupdate" ist folgendes zu berücksichtigen: Username und Passwort welcher benutzt wird um sich beim explizit Proxy anzumelden ist hier optional. Das FortiOS benutzt den explizit Proxy um sich via HTTP CONNECT Methode gemäss RFC 2616 zu verbinden. Diese Methode wird benutzt um SSL Traffic zu "tunneln". Aus diesem Grund muss auf dem explizit Proxy kontrolliert werden ob dies erlaubt ist, da dieser Vorgang im normal Fall über den explizit Proxy verhindert wird. Es sollte ebenfalls kontrolliert werden welche Ports freigegeben auf dem explizit Proxy um das Internet zu erreichen. Unter normalen Umständen, sofern keine Einschränkungen auf dem explizit Proxy implementiert sind, wären dies die privilegierten Ports 1-1024. Die FortiOS "autoupdate" Funktion benutzt den TCP-Port 8890 was wiederum keinem privilegierter Port entspricht. Aus diesem Grund muss dieser nicht privilegierter Port auf dem explizit Proxy Funktion freigeschaltet werden damit das Fortinet Distribution Network (FDN) erreichbar ist.
# config system autoupdate tunneling
# set status [enable | disable]
# set address [gebe die entsprechende IPv4 Adresse oder FQDN des explizit Proxy an]
# set port [gebe den entsprechenden Proxy Port an zB "8080"]
# set username [optional gebe für die Anmeldung an den explizit Proxy einen Usernamen an]
# set password [gebe für die Anmeldung an den explizit Proxy sofern ein Username definiert wurde ein entsprechendes Passwort an]
# end
Was ist die Option Virus Outbreak Prevention?
Die FortiGuard Virus Outbreak Prevention ist eine zusätzliche Schutzebene, welche das Netzwerk vor neu auftauchender Malware schützt. Schnelle Virenausbrüche können ein Netzwerk infizieren, bevor Signaturen entwickelt werden können, um diese zu stoppen. Die Outbreak Prevention Option stoppt diese Virenausbrüche, bis Signaturen in der FortiGuard verfügbar sind. Die FortiGate muss über eine FortiGuard Virus Outbreak Service (VOS) Lizenz verfügen, bevor sie die Anfrage in Echtzeit an FortiGuard sendet und so einen Zero-Day Virenangriff verhindert.
Die FortiGate nutzt für neue Bedrohungen eine hashbasierte Virenerkennung welche von den AV-Signaturen noch nicht erkannt werden. Wenn die Datei an den Scanunit-Deamon gesendet wird, wird die Datei im Puffer gehasht (optional werden Archivinhalte extrahiert) und eine Anforderung (oder mehrere, je nach Anzahl der Dateien in einem gescannten Archiv) an den URL-Filter-Deamon gesendet. Nach einem Abgleich mit seinem Anforderungscache auf bekannte Signaturen sendet der URL-Filter-Deamon eine Antivirus-Anforderung mit den verbleibenden Signaturen an die FortiGuard. Die FortiGuard gibt eine Bewertung zurück, anhand jener bestimmt wird, ob der Scanunit-Deamon die Datei als schädlich melden soll oder nicht. Aufträge bleiben im Scanunit-Deamon so lange ausgesetzt, bis der Requester eine Antwort erhält oder die Anfrage in ein Time-Out läuft.
| Konfiguration über das WebGui:
|
|
| Konfiguration über die CLI:
|
|
Syntax: config antitvirus profile edit [PROFIL_NAME] config [Protokoll] set options scan set outbreak-prevention [disable|files|full-archive] -> disable = Outbreak Prevention wird in diesem Protokoll nicht angewendet -> files = Files werden gescannt -> full-archive = Files und Archivierte Files (ohne Passwort) werden gescannt end Beispiel für ein AntiVirus Profil scannen auf HTTP mit Outbreak Prevention: config antivirus profile
edit "av_outbreak"
config http
set options scan
set outbreak-prevention full-archive
end
next
end
|
Wir sehen das Outbreak Prevensions Verdikt der Datei also_test.com im scanunit deamon:
| Konfiguration über die CLI:
|
# diagnose debug application scanunit -1 Debug messages will be on for 30 minutes. # diagnose debug enable # su 4739 job 1 open su 4739 req vfid 1 id 1 ep 0 new request, size 313, policy id 1, policy type 0 su 4739 req vfid 1 id 1 ep 0 received; ack 1, data type: 0 su 4739 job 1 request info: su 4739 job 1 client 10.20.0.20:39412 server 198.18.250.15:80 su 4739 job 1 object_name 'also_test.com' su 4739 file-typing NOT WANTED options 0x0 file_filter no su 4739 enable databases 0b (core mmdb extended) su 4739 job 1 begin http scan su 4739 scan file 'also_test.com' bytes 68 su 4739 job 1 outbreak-prevention scan, level 0, filename 'also_test.com' su 4739 scan result 0 su 4739 job 1 end http scan su 4739 job 1 inc pending tasks (1) su 4739 not wanted for analytics: analytics submission is disabled (m 0 r 0) su 4739 job 1 suspend su 4739 outbreak-prevention recv error su 4739 ftgd avquery id 0 status 1 su 4739 job 1 outbreak-prevention infected entryid=0 su 4739 report AVQUERY infection priority 1 su 4739 insert infection AVQUERY SUCCEEDED loc (nil) off 0 sz 0 at index 0 total infections 1 error 0 su 4739 job 1 dec pending tasks 0 su 4739 job 1 send result su 4739 job 1 close su 4739 outbreak-prevention recv error # diagnose debug disable # diagnose debug reset |
WebFilter
DNS Filter
IPS
Wie kann ich die Industrie Signaturen auf der FortiGate aktivieren?
Im FortiOS sind die Industrie Signaturen beim IPS integriert. Diese sind aber defaultmässig deaktiviert und müssen über die CLI aktiviert werden. Mit folgendem Befehl können die Industrie Signaturen aktiviert werden:
| Konfiguration über die CLI:
|
config ips global set exclude-signatures none end |
Um die Signaturen wieder auszuschliessen (exclude) wird folgender Syntax verwendet:
| Konfiguration über die CLI:
|
config ips global set exclude-signatures industrial end |
Traffic Shaper / TOS / DSCP
Wie behebe ich bei kleineren FortiGate Modellen im Trafficshapping das Problem des TCP saw-toothing?
Bei kleineren FortiGate Geräten (Entry Level) kann es bei langsamen Upload-Geschwindigkeiten zu Problemen kommen. Die begrenzte Upload-Geschwindigkeit wird durch TCP Saw-toothing verursacht wenn der Burst-Traffic die Geschwindigkeits-Limmite überschreitet. Grund dafür ist, dass die FortiGate den Traffic nicht ordnungsgemäss in die Queue stellt, und auf dem ausgehenden Interface die Burstcontroll angewendet werden soll.
Dies kann man ab dem FortiOS 6.2.1 wie folgt beheben:
Stellt den gesamten Traffic als 'default-class-id 10' und das wird für den gesamten Traffic verwendet.
Anwendung eines garantierten Prozentsatzes von 80 % und maximal 96 % beim Traffic-Shaping der Interfacebandbreite, welche auf 880 MB konfiguriert ist.
| Konfiguration über die CLI:
|
# config firewall shaping-profile # edit <profile name> # set type queuing # set default-class-id 10 # config shaping-entries # edit 1 # set class-id 10 # set guaranteed-bandwidth-percentage 80 # set maximum-bandwidth-percentage 96 # set burst-in-msec 1000 <range from 0 to 2000> # set cburst-in-msec 1800 <range from 0 to 2000> # end # end |
Anpassen des Grenzwertes: Den Grenzwert sollte man so konfigurieren, dass dieser sich unter dem Wert von cburst befindet, welcher höher ist als der Wert des Burst-Traffics. Der Wert beträgt zwischen 1000ms (50%) bis hin zu 1800ms (90%) der (outgoing Bandbreite) Obergrenze der erreichbaren Höchstgeschwindigkeit. Diese Werte können bei Bedarf niedriger gestellt werden.
Man kann dies mit folgenden Befehlen überprüfen:
| Konfiguration über die CLI:
|
# diagnose netlink intf-class list wan2 # diagnose netlink intf-qdisc list wan2 In der folgenden Konfiguration soll die ausgehende Bandbreite auf 880 MB insgesamt 900 MB angewendet werden: # config system interface # edit wan2 # set outbandwidth 880000 # set egress-shaping-profile <?name of shaping-profile> # end # end |
Wie kann ich eine unbeschränkte Speed-Limite im Traffic-Shaper setzen?
Wenn eine unbeschränkte Bandbreite zugelassen werden möchten, kann dies lediglich via CLI mit dem Wert (null) vorgenommen werden.
Eine Traffic Shaping Policy kann wie folgt erstellt werden:
Zu beachtende Parameter (in / out):
Bei Application Category kann nunVoIp ausgewählt werden und bei Application -> SIP:
Kann ich auf einem FortiGate Device den IP-Paketen DSCP Informationen hinzufügen?
In verschiedenen Situationen werden den IP-Paketen in einem internen Netzwerk ToS/DSCP Informationen hinzugefügt. Damit kann für einen bestimmten Traffic Typ, wie zum Beispiel VoIP, eine bestimmte Bandbreite, respektive eine Priorität verliehen werden. Üblicherweise werden solche Markierungen auf einem Core-Switch durchgeführt.
Wenn jedoch eine Markierung über einen Switch nicht möglich ist, aber die Markierung der IP-Pakete erforderlich ist, dass diese im Backbone Bereich des ISP's priorisiert werden, so ist es möglich dies ebenfalls über das FortiOS durchzuführen. ToS ist in RFC 791 definiert und durch RFC 1349 erweitert. DSCP ist die Ablösung von ToS und wird im RFC 2474 definiert. Nachfolgende Links geben vertieft Auskunft über ToS und DSCP:
- http://bogpeople.com/networking/dscp.shtml
- http://en.wikipedia.org/wiki/Differentiated_Services_Code_Point#Classification_and_marking
- https://de.wikipedia.org/wiki/DiffServ
| DSCP Tabelle: |
|
Damit IP-Pakete markiert werden können, müssen die Informationen des Providers/Services bekannt sein, wie diese Pakete markiert werden sollen.
Wenn nun ein Provider zBsp "AF41" verlangt, wäre dies "Precedence 4" was wiederum "Class Selector 4" entspricht. Nachfolgend eine Tabelle für DSCP wie diese Informationen interpretiert werden: Datei:Fortinet-324.jpg Aus dieser DSCP Tabelle kann entnommen werden, dass zum Bespiel "AF41" der binäre Wert wie folgt bestimmt wird: Class Selector 4 = 100xxx
AF41 = xxx010
Ergibt = '''100010''' (oder Dezimal 34)
|
Mit diesen Informationen kann der entsprechender Traffic-Shaper konfiguriert werden. Damit dieser in der entsprechenden Traffic-Shaper Policy benutzt wird um den Traffic mit DSCP Informationen zu markieren:
| Konfiguration über das WebGui:
|
|
| Konfiguration in der CLI |
|
Über die CLI wird die DSCP Information folgendermassen im Traffic-Shaper Profil konfiguriert: # config firewall shaper traffic-shaper # edit [Name für das Profile] --> zum Beispiel "Citrix-CS4-AF41" # set priority high # set diffserv [enable | disable] # set diffservcode [DSCP Code] --> zum Beispiel "100010"] # end |
Danach muss der neu konfigurierte "Traffic Shaper" in einer "Traffic Shaper Policy" definiert werden. Dabei ist zu beachten, dass die Traffic Shaper Policy so definiert wird, dass diese mit der entsprechenden IPv4 Firewall Policy Rule korrespondiert. Es muss ebenfalls darauf geachtet werden, dass die Policy über eine Übereinstimmung verfügt (matching criteria).
Als Beispiel möchten wir ausgehender VoIP Traffic markieren. Es existieren folgende IPv4 Firewall Regeln:
| Konfiguration über das WebGui:
|
|
Somit ergibt sich folgende Traffic Shaper Policy welche über eine entsprechende Übereinstimmung verfügt (matching criteria): Jetzt ist darauf zu achten, dass in der Traffic Shaper Policy eine entsprechende Übereinstimmung gewährleistet ist (matching criteria):
Durch diese Konfiguration werden nun IP Pakete in der IPv4 Firewall Policy '(ID17) durch den Traffic Shaper, welcher über die entsprechende Traffic Shaper Policy eingebunden wurde, markiert! |
SIP / VoIP
Was im FortiOS als "SIP ALG" zu verstehen und soll ich diese Funktion benutzen?
In den meisten Fällen sollte anstelle des "SIP Session Helpers" der "SIP ALG" (SIP Application Layer Gateway) benutzt werden.
Der "SIP ALG" ist seit FortiOS 5.2 standard. Zusätzlich wird das SIP Protokoll im "SIP ALG" vor Angriffen im SIP-Bereich geschützt. Dies bedeutet zBsp., dass Sessions limitiert, Syntax betreffend SIP, sowie SDP Inhalte usw. der Nachrichten überprüft werden. Zusätzlich wird über den "SIP ALG" ein detailliertes Logging, wie auch Reporting zur Verfügung gestellt. Nachfolgende Darstellung zeigt wie der "SIP ALG" in seinem Grundkonstrukt implementiert ist:
Der SIP ALG unterstützt folgende Funktionen:
- Alle Features implementiert im "Session Helper" sowie NAT, SIP und RTP Pinholes (Real Time Protocol Pinholes)
- Zusätzlich, im Gegensatz zum Session Helper, kann auf dem SIP ALG folgendes durchgeführt werden:
- SIP TCP und UDP Support
- SIP Message Order Überprüfung
- konfigurierbare Header Line Lenght Maximum
- Message Fragment Assembly (TCP)
- Wenn SIP Nachrichten fragmentiert sind (vers. Pakete) fügt der SIP ALG diese wieder zusammen und schickt diese als Ganzes weiter.
- L4 Protocol Translation
- Message Flood Protection
- DoS Protection für "flooding INVITE, REGISTER" und andere Methoden
- SIP message Type Filtering
- SIP Statistik und Logging
- SIP über IPv6
- SIP über SSL/TLS
- Deep SIP Message Syntax Checking (SIP Header Inspection oder SIP Fuzzing Protection
- Hosted NAT Traversal
- SIP High Availability (HA)
- Geographical Redundancy (HA)
- SIP Per Request Method Message Rate Limitation (schützt SIP Server vor SIP-Überlastung und DoS-Attacken)
- RTP Bypass (RTP Pinholing)
- SIP NAT
- IP Topology Hiding
Diese Aufstellung zeigt das hinter "SIP" (VoIP) mehr steckt als man glaubt, und aus diesem Grund komplizierter ist als eine normale TCP/UDP-basierte Anwendung. Aufgrund der Komplexität der Signalisierung und der Protokolle bei "SIP", sowie der Inkonsistenzen die sich ergeben, wenn eine Firewall die Source-Adresse und Source-Port Daten mit NAT ändert, ist es schwierig für "SIP" eine Firewall ungehindert zu überwinden. "SIP" (VoIP) verwendet zwei verschiedene Protokolle: eines für die Signalisierung (zwischen dem Client und dem SIP/VoIP-Server) und eines für die Medien (zwischen den Clients). Die Port-/IP-Adresspaare, welche von den Medienprotokollen (RTP/RTCP) für jede Sitzung verwendet werden, werden von den Signalisierungsprotokollen dynamisch verhandelt. Firewalls müssen diese Informationen dynamisch mitverfolgen, warten und zum entsprechenden Zeitpunkt ausgewählte Ports für die Sitzungen auf sichere Weise öffnen und wieder schließen. Mehrere Medien-Ports werden über die Signalisierungssitzung dynamisch verhandelt; die Verhandlungen über die Medien-Ports sind in der Nutzlast der Signalisierungsprotokolle enthalten (IP-Adress- und Port-Informationen). Firewalls müssen für jedes Packet eine "Deep Inspection" durchführen, um diese Informationen zu erhalten und die Sitzungen dynamisch zu warten; dies erfordert zusätzliche Verarbeitungskapazitäten der Firewall. Die Source- und Destination-IP-Adressen sind in dies SIP/VoIP-Signalisierungspakete eingebettet. Eine Firewall mit NAT-Unterstützung übersetzt IP-Adressen und -Ports auf IP-Header-Ebene für Pakete. Vollsymmetrische NAT-Firewalls passen ihre NAT-Anbindungen häufig neu an und können so zufällig die "Pinholes" schließen, über die eingehende Pakete in das zu schützende Netzwerk gelangen. In diesem Fall kann der Dienstanbieter keine eingehenden Anrufe an den Kunden weiterleiten. Für die erfolgreiche Unterstützung von "SIP" muss mittels NAT-Firewall eine "Deep Packet Inspection" durchführen und die eingebettete IP-Adress- und Portinformationen bei der Weiterleitung via Firewall transformieren können. Genau hier setzt der "SIP ALG" an und übernimmt diese Arbeit in verschiedenen Bereichen. Dies bedeutet, dass er die SIP und SDP Informationen analysiert, passt die Pakete an (zBsp. für NAT), schützt das Protokoll auf DoS sowie IPS Ebene usw. Bei einigen SIP-Implementierungen, welche von Hersteller zu Hersteller verschieden sein können, kann es zu Problemen kommen. Das heisst, dass zBsp. weil über SIP Befehle gesendet wird diese durch den "SIP ALG" nicht erkannt werden. Diese Befehle - da nicht erkannt - werden als "unknown" eingestuft und entsprechend geblockt. Um dies zu verhindern kann diese spezifische Funktion zu Erkennung der Befehle, resp. die SIP Funktion deaktiviert werden damit "unknown" nicht geblockt wird. Wie hier aufgezeigt ist "SIP" resp. "VoIP" eine komplexe Materie und es existieren etliche verschiedenen Provider mit eigenen Implementierungen usw. Security-Technisch gesehen ist/wäre es sinnvoll den "SIP ALG" anhand eines "VoIP Profiles" zu benutzen. Dies ist jedoch höchst anspruchsvoll und komplex. Aus diesem Grund empfehlen wir die Funktion des "SIP Session Helpers" auf einer FortiGate in normaler Umgebungen zu löschen/deaktivieren und die Funktion des "SIP ALG" nicht zu benutzen. Der "SIP Session Helper" gelöscht/ deaktiviert, resp. "SIP ALG" disabled wird, kann hier entnommen werden:
Vorbereitung:
- SIP-Server Konfiguration anpassen (falls NAT verwendet wird)
-> Wenn der SIP-Verkehr beim Durchlaufen der FortiGate genatted ist, muss der SIP-Server so konfiguriert werden, dass seine öffentliche IP-Adresse im Application Header verwendet wird. Alle anderen VoIP-Geräte müssen ebenfalls mit ihrer öffentlichen IP-Adresse auf den SIP-Server verweisen.
- öffnen der Firewall-Regeln auf der FortiGate
-> Firewall-Richtlinien müssen jetzt ausdrücklich zugelassen werden, dass alle UDP-Ports für den Audio-Verkehr geöffnet werden können (und nicht nur die SIP- oder SCCP-Control-Ports).
Session Helper entfernen:
Folgenden Befehl unter system session-helper ausführen:
#config system session-helper
show
Unter den angezeigten Einstellungen befindet sich eine, die dem folgenden Beispiel ähnelt:
#edit 13
set name sip
set protocol 17
set port 5060
next
Hier ist Eintrag 13 welcher auf den SIP-Verkehr verweist und den UDP-Port 5060 für die Signalisierung verwendet.
In diesem Beispiel würden die nächsten Befehle zum entfernen des entsprechenden Eintrags wie folgt lauten:
#delete 13
end
Wichtig: Es ist nicht zwingend erforderlich, dass der SIP-Eintrag 13 ist. Es ist somit zu prüfen welcher Eintrag die SIP-Helper-Einstellungen hat.
Anpassen des default -voip -alg-mode (standardmässig ist dieser auf proxy-based eingestellt):
Folgende Befehle müssen ausgeführt werden (gültig ab OS 6.2.2):
#config system settings
set default-voip-alg-mode kernel-helper-based
set sip-expectation disable
set sip-nat-trace disable
end
Nichts desto trotz nachfolgend einige Hinweise auf was geachtet werden muss wenn zwar der "SIP Session Helper" gelöscht wird, jedoch dennoch der "SIP ALG" anhand eines "VoIP Profiles" benutzt wird:
Deaktiviere "unknown" SIP-Befehle
#config voip profile
#edit [Name des VoIP Profiles]
#config sip
#set block-unknown disable
#end
Deaktiviere NAT-Funktion innerhalb SIP
#config voip profile
#edit [Name des VoIP Profiles]
#config sip
#set nat-trace disable
#end
Aktiviere NAT-Register Funktion innerhalb SIP
#config voip profile
#edit [Name des VoIP Profiles]
#config sip
#set register-contact-trace enable
#end
Nachfolgend eine Liste aller CLI-Befehle welche für VoIP-Profile aufgerufen werden kann:
'''config voip profile'''
Description: Configure VoIP profiles
edit <name>
set comment {var-string}
config sip
Description: SIP.
set status [disable|enable]
set rtp [disable|enable]
set nat-port-range {user}
set open-register-pinhole [disable|enable]
set open-contact-pinhole [disable|enable]
set strict-register [disable|enable]
set register-rate {integer}
set invite-rate {integer}
set max-dialogs {integer}
set max-line-length {integer}
set block-long-lines [disable|enable]
set block-unknown [disable|enable]
set call-keepalive {integer}
set block-ack [disable|enable]
set block-bye [disable|enable]
set block-cancel [disable|enable]
set block-info [disable|enable]
set block-invite [disable|enable]
set block-message [disable|enable]
set block-notify [disable|enable]
set block-options [disable|enable]
set block-prack [disable|enable]
set block-publish [disable|enable]
set block-refer [disable|enable]
set block-register [disable|enable]
set block-subscribe [disable|enable]
set block-update [disable|enable]
set register-contact-trace [disable|enable]
set open-via-pinhole [disable|enable]
set open-record-route-pinhole [disable|enable]
set rfc2543-branch [disable|enable]
set log-violations [disable|enable]
set log-call-summary [disable|enable]
set nat-trace [disable|enable]
set subscribe-rate {integer}
set message-rate {integer}
set notify-rate {integer}
set refer-rate {integer}
set update-rate {integer}
set options-rate {integer}
set ack-rate {integer}
set prack-rate {integer}
set info-rate {integer}
set publish-rate {integer}
set bye-rate {integer}
set cancel-rate {integer}
set preserve-override [disable|enable]
set no-sdp-fixup [disable|enable]
set contact-fixup [disable|enable]
set max-idle-dialogs {integer}
set block-geo-red-options [disable|enable]
set hosted-nat-traversal [disable|enable]
set hnt-restrict-source-ip [disable|enable]
set max-body-length {integer}
set unknown-header [discard|pass|...]
set malformed-request-line [discard|pass|...]
set malformed-header-via [discard|pass|...]
set malformed-header-from [discard|pass|...]
set malformed-header-to [discard|pass|...]
set malformed-header-call-id [discard|pass|...]
set malformed-header-cseq [discard|pass|...]
set malformed-header-rack [discard|pass|...]
set malformed-header-rseq [discard|pass|...]
set malformed-header-contact [discard|pass|...]
set malformed-header-record-route [discard|pass|...]
set malformed-header-route [discard|pass|...]
set malformed-header-expires [discard|pass|...]
set malformed-header-content-type [discard|pass|...]
set malformed-header-content-length [discard|pass|...]
set malformed-header-max-forwards [discard|pass|...]
set malformed-header-allow [discard|pass|...]
set malformed-header-p-asserted-identity [discard|pass|...]
set malformed-header-sdp-v [discard|pass|...]
set malformed-header-sdp-o [discard|pass|...]
set malformed-header-sdp-s [discard|pass|...]
set malformed-header-sdp-i [discard|pass|...]
set malformed-header-sdp-c [discard|pass|...]
set malformed-header-sdp-b [discard|pass|...]
set malformed-header-sdp-z [discard|pass|...]
set malformed-header-sdp-k [discard|pass|...]
set malformed-header-sdp-a [discard|pass|...]
set malformed-header-sdp-t [discard|pass|...]
set malformed-header-sdp-r [discard|pass|...]
set malformed-header-sdp-m [discard|pass|...]
set provisional-invite-expiry-time {integer}
set ips-rtp [disable|enable]
set ssl-mode [off|full]
set ssl-send-empty-frags [enable|disable]
set ssl-client-renegotiation [allow|deny|...]
set ssl-algorithm [high|medium|...]
set ssl-pfs [require|deny|...]
set ssl-min-version [ssl-3.0|tls-1.0|...]
set ssl-max-version [ssl-3.0|tls-1.0|...]
set ssl-client-certificate {string}
set ssl-server-certificate {string}
set ssl-auth-client {string}
set ssl-auth-server {string}
end
config sccp
Description: SCCP.
set status [disable|enable]
set block-mcast [disable|enable]
set verify-header [disable|enable]
set log-call-summary [disable|enable]
set log-violations [disable|enable]
set max-calls {integer}
end
next
end
Was ist zu beachten, wenn SIP (VoIP) über eine Fortigate implementiert wird?
Wenn SIP resp. VoIP über eine FortiGate unter FortiOS 6.2 implementiert/ konfiguriert wird ist folgendes wichtig:
Im FortiOS gibt es zwei Funktionen welche den SIP Traffic manipulieren.
- Session Helper
- ALG (Application Layer Gateway)
Diese zwei Funktionen werden über eine globale Einstellung / Konfiguration gesteuert:
| Konfiguration über die CLI:
|
# config system settings # set default-voip-alg-mode [proxy-based | kernel-helper-based] # end |
|
|
Die Optionen "proxy-based" und/oder "kernel-helper-based" haben folgende Bedeutung:
Somit wird durch folgende Konfiguration entweder der "ALG" oder der "Session Helper"
|
Um den "ALG" somit als Standard zu aktivieren, und den "Session Helper" zu deaktivieren, muss folgendes konfiguriert werden:
| Konfiguration über die CLI:
|
|
Session Helper als Standard konfigurieren: config system settings set default-voip-alg-mode kernel-helper-based end Den Session Helper löschen: # show system session-helper | grep sip -f Durch den
config system session-helper
edit 12
set name sip <---
set protocol 17
set port 5060
next
end
Den gefundenen "Integer" - in unserem Beispiel die zwölf(12): config system session-helper delete [INTEGER_WERT --> in unserem Fall 12] end config system session-helper delete 12 end Deaktivieren der globalen "sip"-Funktionen:
config system settings
set default-voip-alg-mode kernel-helper-based
set sip-expectation disable
set sip-nat-trace disable
end
Damit die Konfiguration aktiviert wird muss ein Neustart des Devices durchgeführt werden: execute reboot Danach wird SIP resp. VoIP nicht mehr durch die FortiGate speziell über den "ALG" oder den "Session Helper" verarbeitet da der "Session Helper" nicht mehr existiert und der "ALG" nur dann genutzt wird, wenn auf einer Firewall Policy ein "VoIP Profile" konfiguriert wurde. Aus diesem Grund sollte darauf geachtet werden, dass "kein" VoIP Profile auf einer entsprechenden Firewall Policy Rule konfiguriert wurde. Nur so ist gewährleistet, dass die FortiGate betreffend SIP resp. VoIP den Traffic normal verarbeitet ohne in den SIP / VoIP Traffic einzugreifen. Wenn dennoch ein "VoIP Profile" benutzt wird sollte man sich der Problematik bewusst sein und folgenden Artikel berücksichtigen: https://fortinet.also.ch/wiki/index.php?title=FortiGate:FAQ#SIP_.2F_VoIP -> 65.1 Was im FortiOS als "SIP ALG" zu verstehen und soll ich diese Funktion benutzen? |
Ausgehend davon, dass SIP (VoIP) nicht benutzt wird, respektive die Konfiguration zur Nichtbenutzung korrekt durchgeführt wurde, kann mit nachfolgenden Befehlen dies bestätigt werden. Die Befehle können durchgeführt werden um festzustellen ob der "Session Helper" und / oder der "ALG" für SIP (VoIP) benutzt werden. Wurde die Konfiguration korrekt durchgeführt, bestätigen diese Kommandos dass SIP (VoIP) weder über den "Session Helper" noch über den "ALG" verarbeitet werden da die "counter" im Output für diese Kommandos auf Null stehen. Damit diese Überprüfung korrekt durchgeführt werden kann, muss dementsprechend SIP (VoIP) Traffic durchgeführt werden:
SIP Session Helper
| Konfiguration über die CLI:
|
# diagnose sys sip status
dialogs: max=131072, used=0
mappings: used=0
dialog hash by ID: size=8192, used=0, depth=0
dialog hash by RTP: size=8192, used=0, depth=0
mapping hash: size=8192, used=0, depth=0
count0: 0
count1: 0
count2: 0
count3: 0
count4: 0
SIP ALG
# diagnose sys sip-proxy stats
sip stats
vdom name: root
---------------------------
active-sessions: 0
calls-attempted: 0
calls-established: 0
calls-failed: 0
calls-active: 0
registers-active: 0
| received | blocked | unknown form | long headers
req-type | req resp| req resp| req resp| req resp
UNKNOWN 0 0 0 0 0 0 0 0
ACK 0 0 0 0 0 0 0 0
BYE 0 0 0 0 0 0 0 0
CANCEL 0 0 0 0 0 0 0 0
INFO 0 0 0 0 0 0 0 0
INVITE 0 0 0 0 0 0 0 0
MESSAGE 0 0 0 0 0 0 0 0
NOTIFY 0 0 0 0 0 0 0 0
OPTIONS 0 0 0 0 0 0 0 0
PRACK 0 0 0 0 0 0 0 0
PUBLISH 0 0 0 0 0 0 0 0
REFER 0 0 0 0 0 0 0 0
REGISTER 0 0 0 0 0 0 0 0
SUBSCRIBE 0 0 0 0 0 0 0 0
UPDATE 0 0 0 0 0 0 0 0
PING 0 0 0 0 0 0 0 0
YAHOOREF 0 0 0 0 0 0 0 0
|
Wie konfiguriere ich ein VoIP Profile und was bedeuten die entsprechenden Parameter?
Bevor ein "VoIP Profile" konfiguriert wird unter FortiOS 6.2 sollte man sich der Problematik bewusst sein dh. dazu sollte folgende zwei Artikel konsultiert werden:
https://fortinet.also.ch/wiki/index.php?title=FortiGate:FAQ#SIP_.2F_VoIP 65.1 - Was ist unter «SIP ALG» zu verstehen und soll ich diese Funktion benutzen? 65.2 - Was ist unter zu beachten wenn SIP (VoIP) über eine Fortigate implementiert wird?
Wenn ein "VoIP Profile" konfiguriert werden möchte muss das entsprechende Feature resp. Menü auf dem Mgmt.-Web Interface aktiviert werden.
| Konfiguration über das WebGui:
| ||
|
Über das Menu:System -> Feature Visibility kann das VoIP Feature eingeschaltet werden: | ||
| Konfiguration über die CLI:
| ||
config system settings set gui-voip-profile [enable|disable] end | ||
| Konfiguration über das WebGui:
| ||
|
Sobald die Funktion aktiviert ist, erscheint unter "Security Profiles" -> "VoIP" der entsprechende Punkt: WICHTIG: Wenn sich nur eine limitierte Anzahl Verbindungen registrieren dürfen, so kann bei «REGISTER» die gewünschte Anzahl eingetragen werden. Wird der Wert auf 0 (null = default) belassen, so können sich unbeschränkte Anzahl Verbindungen registrieren. Das Gleiche gilt für die Anzahl der «INVITE». Die Positionen "REGISTER" und "INVITE" geben an wie viele Requests per Second und Policy über SIP akzeptiert werden.
Dies bedeutet, wenn der Wert 100 gesetzt wird so können sich über das entsprechende konfigurierte "VoIP Profile" das für eine Firewall Policy konfiguriert wurde nicht mehr als zBsp. 100 Devices am Controller registrieren (REGISTER). Wenn "INVITE" auf 100 gesetzt wird, können sich über die entsprechende Policy nicht mehr als 100 Anrufe (INVITE) durchgeführt werden. Nachdem ein entsprechendes "VoIP Profile" konfiguriert wurde, kann dieses in einer entsprechenden Firewall Policy eingebunden werden:
| ||
| Konfiguration über die CLI:
| ||
|
Auf der CLI stehen für das "VoIP Profile" unzählige Optionen zur Verfügung: # config voip profile # edit [Name des entsprechenden Profil] # set comment [Gebe einen entsprechenden Kommentar an] # config sip # set status [disable | enable] # set rtp [disable | enable] # set open-register-pinhole [disable | enable] # set open-contact-pinhole [disable | enable] # set strict-register [disable | enable] # set register-rate [Integer] # set invite-rate [Integer] # set max-dialogs [Integer] # set max-line-length [Integer] # set block-long-lines [disable | enable] # set block-unknown [disable | enable] # set call-keepalive [Integer] # set block-ack [disable | enable] # set block-bye [disable | enable] # set block-cancel [disable | enable] # set block-info [disable | enable] # set block-invite [disable | enable] # set block-message [disable | enable] # set block-notify [disable | enable] # set block-options [disable | enable] # set block-prack [disable | enable] # set block-publish [disable | enable] # set block-refer [disable | enable] # set block-register [disable | enable] # set block-subscribe [disable | enable] # set block-update [disable | enable] # set register-contact-trace [disable | enable] # set open-via-pinhole [disable | enable] # set open-record-route-pinhole [disable | enable] # set rfc2543-branch [disable | enable] # set log-violations [disable | enable] # set log-call-summary [disable | enable] # set nat-trace [disable | enable] # set subscribe-rate [Integer] # set message-rate [Integer] # set notify-rate [Integer] # set refer-rate [Integer] # set update-rate [Integer] # set options-rate [Integer] # set ack-rate [Integer] # set prack-rate [Integer] # set info-rate [Integer] # set publish-rate [Integer] # set bye-rate [Integer] # set cancel-rate [Integer] # set preserve-override [disable | enable] # set no-sdp-fixup [disable | enable] # set contact-fixup [disable | enable] # set max-idle-dialogs [Integer] # set block-geo-red-options [disable | enable] # set hosted-nat-traversal [disable | enable] # set hnt-restrict-source-ip [disable | enable] # set max-body-length [Integer] # set unknown-header [discard | pass | respond] # set malformed-request-line [discard | pass | respond] # set malformed-header-via [discard | pass | respond] # set malformed-header-from [discard | pass | respond] # set malformed-header-to [discard | pass | respond] # set malformed-header-call-id [discard | pass | respond] # set malformed-header-cseq [discard | pass | respond] # set malformed-header-rack [discard | pass | respond] # set malformed-header-rseq [discard | pass | respond] # set malformed-header-contact [discard | pass | respond] # set malformed-header-record-route [discard | pass | respond] # set malformed-header-route [discard | pass | respond] # set malformed-header-expires [discard | pass | respond] # set malformed-header-content-type [discard | pass | respond] # set malformed-header-content-length [discard | pass | respond] # set malformed-header-max-forwards [discard | pass | respond] # set malformed-header-allow [discard | pass | respond] # set malformed-header-p-asserted-identity [discard | pass | respond] # set malformed-header-sdp-v [discard | pass | respond] # set malformed-header-sdp-o [discard | pass | respond] # set malformed-header-sdp-s [discard | pass | respond] # set malformed-header-sdp-i [discard | pass | respond] # set malformed-header-sdp-c [discard | pass | respond] # set malformed-header-sdp-b [discard | pass | respond] # set malformed-header-sdp-z [discard | pass | respond] # set malformed-header-sdp-k [discard | pass | respond] # set malformed-header-sdp-a [discard | pass | respond] # set malformed-header-sdp-t [discard | pass | respond] # set malformed-header-sdp-r [discard | pass | respond] # set malformed-header-sdp-m [discard | pass | respond] # set provisional-invite-expiry-time [Integer] # set ips-rtp [disable | enable] # set ssl-mode [off | full] # set ssl-send-empty-frags [enable | disable] # set ssl-client-renegotiation [allow | deny | secure] # set ssl-algorithm [high | medium | low] # set ssl-pfs [require | deny | allow] # set ssl-min-version [ssl-3.0 | tls-1.0 | tls-1.1 | tls-1.2] # set ssl-max-version [ssl-3.0 | tls-1.0 | tls-1.1 | tls-1.2] # set ssl-client-certificate [string] # set ssl-server-certificate [string] # set ssl-server-certificate [string] # set ssl-auth-client [string] # set ssl-auth-server [string] # end # config sccp # set status [disable | enable] # set block-mcast [disable | enable] # set verify-header [disable | enable] # set log-call-summary [disable | enable] # set log-violations [disable | enable] # set max-calls [Integer] # end # end |
Weitere Informationen welche Option welche Funktion besitzt kann dem nachfolgendem Link entnommen werden:
https://docs.fortinet.com/document/fortigate/6.2.1/cli-reference/449620
Ebenso sind diverse VoIP spezifische CLI-Befehle ersichtlich:
https://docs.fortinet.com/document/fortigate/6.2.1/cli-reference/424620/voip-profile
Wie kann man auf der FortiGate ein Debug für VoIP durchführen?
Ausgehend davon, dass der SIP-Helper und / oder SIP ALG benutzt wird, kann mit nachfolgenden Kommandos ein Debug für SIP ausgeführt werden:
- Konfiguriere "putty" für ein logging dh., alle Informationen werden in ein Log aufgezeichnet (Category > Session > Logging > All session output)
- Erstelle eine SSH Verbindung zur FortiGate
- Führe ein Login durch und gebe folgendes ein:
| Konfiguration über die CLI:
|
|
Alle Debug Filter zurücksetzen: # diagnose debug reset Einen Filter für die SIP Applikation setzen: # diagnose debug application sip -1 Den Debug Modus aktiveren (Output an die Console senden): # diagnose debug enable Bei der Konfiguration des Debug 1 Configuration changes, mainly addition/deletion/modification of virtual domains
2 TCP connection accepts or connects, redirect creation
4 Create or delete a session
16 Any IO read or write
32 An ASCII dump of all data read or written
64 Include HEX dump in the above output
128 Any activity related to the use of the FortiCarrier dynamic profile feature to determine the correct profile-group to use
256 Log summary of interesting fields in a SIP call
1024 Any activity related to SIP geo-redundancy
2048 Any activity related to HA syncing of SIP calls
Zusätzlich gibt es die Möglichkeit zum Debug Filter ein "log-filter" für den SIP ALG zu setzen welcher, sofern gesetzt, für das Kommando "diagnose debug application sip" angewendet: # diagnose sys sip-proxy log-filter ?
list Display the current filter
clear Clear the current filter
vd Index of virtual domain. -1 matches all
src-addr4 IPv4 source address range to filter by
dst-addr4 IPv4 destination address range to filter by
src-addr6 IPv6 source address range to filter by
dst-addr6 IPv6 destination address range to filter by
src-port Source port to filter by
dst-port Destination port to filter by
policy Policy to filter by
policy-type Policy-type to filter by
voip-profile VoIP profile to filter by
negate Negate the specified filter parameter
Ein Filter wird anhand der zur Verfügung stehenden Filter Parameter gesetzt. # diagnose sys sip-proxy log-filter src-addr4 198.18.0.60 255.255.255.255 Ein gesetzter Filter kann zur Kontrolle anhand «list» aufgeführt werden: # diagnose sys sip-proxy log-filter list Um den gesamten Filter zurück zu setzen führe folgendes aus: # diagnose sys sip-proxy log-filter clear Nachdem das Troubleshooting erfolgreich durchgeführt wurde setze alle Filter zurück und deaktiviere den Debug Modus: # diagnose debug disable # diagnose debug reset |
Was ist ein Session Helper mit “Pinhole” und wie kann dies konfiguriert werden?
Funktion:
In diesem Beispiel wird die Adresse des Medienempfängers im SIP-SDP-Payload an die genattete IP-Adresse angepasst.
Wichtig zu berücksichtigen:
Es muss beachtet werden dass ein Pinhole geöffnet wird und die Firewallregel zustandsabhängig sind. Nur so kann die Rückmeldung / Antwortverkehr ermöglicht werden.
Dies ist auch zu berücksichtigen wenn nicht explizit eine Firewallregel erstellt wurde um den eingehenden Datenverkehr zuzulassen, da dieses Konzept auch bei einigen anderen Protokollen verwendet wird (zBsp. NAT-T für IPsec).
| Konfiguration über die CLI:
|
config voip profile
edit "voip-profile-name"
config sip
set strict-register [enable|disable]
...
end
next
end
|
NTP
Wie kann ich einen beliebigen Zeitserver auf der FortiGate konfigurieren?
Der Zeitserver auf einer FortiGate ist eine globale Einstellung. Dieser Punkt ist zu berücksichtigen, wenn auf der FortiGate mit VDOMs gearbeitet wird. Die Zeit-Einstellungen sind somit im GLOBAL zu finden.
Die Zeitzone wird folgendermassen konfiguriert:
| Konfiguration über das WebGui:
|
|
| Konfiguration über die CLI: |
# config system global # set timezone <ZEITZONEN_INDEX> # end BEISPIEL Zeitzone 26 (GMT+1:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna setzen. # config system global # set timezone 26 # end |
Wie kann der gewünschte Zeitzonen Index ermittelt werden?
| Konfiguration über die CLI:
|
# config system global # set timezone ? --> Erzeugt eine Liste mit allen Zeitzonen Codes: 01 (GMT-11:00) Midway Island, Samoa 02 (GMT-10:00) Hawaii 03 (GMT-9:00) Alaska 04 (GMT-8:00) Pacific Time (US & Canada) 05 (GMT-7:00) Arizona 81 (GMT-7:00) Baja California Sur, Chihuahua 06 (GMT-7:00) Mountain Time (US & Canada) 07 (GMT-6:00) Central America 08 (GMT-6:00) Central Time (US & Canada) 09 (GMT-6:00) Mexico City 10 (GMT-6:00) Saskatchewan 11 (GMT-5:00) Bogota, Lima,Quito 12 (GMT-5:00) Eastern Time (US & Canada) 13 (GMT-5:00) Indiana (East) 74 (GMT-4:00) Caracas 14 (GMT-4:00) Atlantic Time (Canada) 77 (GMT-4:00) Georgetown 15 (GMT-4:00) La Paz 87 (GMT-4:00) Paraguay 16 (GMT-3:00) Santiago 17 (GMT-3:30) Newfoundland 18 (GMT-3:00) Brasilia 19 (GMT-3:00) Buenos Aires 20 (GMT-3:00) Nuuk (Greenland) 75 (GMT-3:00) Uruguay 21 (GMT-2:00) Mid-Atlantic 22 (GMT-1:00) Azores 23 (GMT-1:00) Cape Verde Is. 24 (GMT) Monrovia 80 (GMT) Greenwich Mean Time 79 (GMT) Casablanca 25 (GMT) Dublin, Edinburgh, Lisbon, London 26 (GMT+1:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna 27 (GMT+1:00) Belgrade, Bratislava, Budapest, Ljubljana, Prague 28 (GMT+1:00) Brussels, Copenhagen, Madrid, Paris 78 (GMT+1:00) Namibia 29 (GMT+1:00) Sarajevo, Skopje, Warsaw, Zagreb 30 (GMT+1:00) West Central Africa 31 (GMT+2:00) Athens, Sofia, Vilnius 32 (GMT+2:00) Bucharest 33 (GMT+2:00) Cairo 34 (GMT+2:00) Harare, Pretoria 35 (GMT+2:00) Helsinki, Riga, Tallinn 36 (GMT+2:00) Jerusalem 37 (GMT+3:00) Baghdad 38 (GMT+3:00) Kuwait, Riyadh 83 (GMT+3:00) Moscow 84 (GMT+3:00) Minsk 40 (GMT+3:00) Nairobi 85 (GMT+3:00) Istanbul 41 (GMT+3:30) Tehran 42 (GMT+4:00) Abu Dhabi, Muscat 43 (GMT+4:00) Baku 39 (GMT+3:00) St. Petersburg, Volgograd 44 (GMT+4:30) Kabul 46 (GMT+5:00) Islamabad, Karachi, Tashkent 47 (GMT+5:30) Kolkata, Chennai, Mumbai, New Delhi 51 (GMT+5:30) Sri Jayawardenepara 48 (GMT+5:45) Kathmandu 45 (GMT+5:00) Ekaterinburg 49 (GMT+6:00) Almaty, Novosibirsk 50 (GMT+6:00) Astana, Dhaka 52 (GMT+6:30) Rangoon 53 (GMT+7:00) Bangkok, Hanoi, Jakarta 54 (GMT+7:00) Krasnoyarsk 55 (GMT+8:00) Beijing, ChongQing, HongKong, Urumgi, Irkutsk 56 (GMT+8:00) Ulaan Bataar 57 (GMT+8:00) Kuala Lumpur, Singapore 58 (GMT+8:00) Perth 59 (GMT+8:00) Taipei 60 (GMT+9:00) Osaka, Sapporo, Tokyo, Seoul 62 (GMT+9:30) Adelaide 63 (GMT+9:30) Darwin 61 (GMT+9:00) Yakutsk 64 (GMT+10:00) Brisbane 65 (GMT+10:00) Canberra, Melbourne, Sydney 66 (GMT+10:00) Guam, Port Moresby 67 (GMT+10:00) Hobart 68 (GMT+10:00) Vladivostok 69 (GMT+10:00) Magadan 70 (GMT+11:00) Solomon Is., New Caledonia 71 (GMT+12:00) Auckland, Wellington 72 (GMT+12:00) Fiji, Kamchatka, Marshall Is. 00 (GMT+12:00) Eniwetok, Kwajalein 82 (GMT+12:45) Chatham Islands 73 (GMT+13:00) Nuku'alofa 86 (GMT+13:00) Samoa 76 (GMT+14:00) Kiritimati |
Ein eigener Zeitserver kann auf der FortiGate nur über die CLI konfiguriert werden:
| Konfiguration über die CLI:
|
# config system ntp # set ntpsync enable # set type custom # set syncinterval 360 # config ntpserver # edit 1 # set server "<NTP-SERVER-NAME oder IP>" # next # edit 2 --> so kann ein zweiter NTP Server konfiguriert werden # set server "<NTP-SERVER2-NAME oder IP>" # next # end # end BEISPIEL:NTP Server Konfiguration mit ch.pool.ntp.org # config system ntp # set ntpsync enable # set type custom # set syncinterval 360 # config ntpserver # edit 1 # set server "ch.pool.ntp.org" # next # end # end |
Wie kann ich den NTP-Dienst auf einem Interface aktivieren?
Wenn ich möchte, dass der System NTP Server auf einem Interface aktiviert ist, damit dieser als dhcp Parameter an die Clients propagiert werden kann, muss man diesen in den System Einstellungen aktivieren:
| Konfiguration über das WebGui:
|
|
| Konfiguration über die CLI: |
# config system ntp # set server-mode enable # set interface "<INTERFACE1> <INTERFACE2> ... <INTERFACEn>" # end BEISPIEL Wir konfigurieren das Interface internal1 und internal2 als NTP Server: # config system ntp # set server-mode enable # set interface "internal1 internal2" # end |
DHCP Option für NTP Server konfigurieren. Die restlichen DHCP Optionen sind bereits konfiguriert.
| Konfiguration über das WebGui:
|
|
Einrichten des Zeitservers beim DHCP Server:
|
| Konfiguration über die CLI: |
# config system dhcp server # edit <INTIGER> # set timezone-option default # set ntp-server1 <INTERFACE IP ADRESSE> # next # end BEISPIEL: Wir konfigurieren den NTP Server mit der IP Adresse 192.168.1.99 (IP Adresse vom Interface) # config system dhcp server # edit 1 # set timezone-option default # set ntp-server1 192.168.1.99 # next # end |
PCI Compliance
Wireless-Controller
Wo finde ich Informationen betreffend FortiGate Wireless-Controller und Forti Access Points?
Nachfolgender Artikel gibt Auskunft über die verschiedenen Konfigurationen und den Betrieb von Forti Access Points im Zusammenhang mit dem FortiGate Wireless Controller:
FortiAP:FAQ
Wie konfiguriere ich einen Remote Access Point mit Split Tunnel?
Vorbemerkungen:
Ziel dieser Anleitung ist es, mit einem FortiAP-24D a eine gesicherte Remoteverbindung von einem Aussenstandort zu einem Hauptstandort zu erstellen. Es handelt sich hier um ein typisches Szenario, welches eingesetzt werden soll, um kleine Aussenstandorte oder HomeOffice Mitarbeiter anzubinden. Die Dokumentation wurde mit einem AP24d erstellt. Es eignen sich aber grundsätzlich auch folgende Access Points um ein solches Szenario zu etablieren:
- FAP-11C
- FAP-14C
- FAP-21D
- FAP-24D
- FAP-25D
- FAP-28C
Ausgangslage:
| Zielarchitektur | Verwendete Geräte |
|
|
|
Vorbedingungen:
- Die Firewall im Main Office ist korrekt konfiguriert, so dass Clients im LAN über den WAN Anschluss ins Internet kommen.
- Die Firewall im Main Office wird direkt und ohne weitere Router mit einer public IP vom Provider von der WAN Seite verbunden.
- Der FortiAP befindet sich auf Werkseinstellungen, kriegt via DHCP am WAN Port eine IP, einen gültigen Default Gatway, sowie einen gültigen DNS Server.
- Der FortiAP ist in der Lage über den am Ort vorhandenen Internetanschluss mindestens über die Ports 53TCP/UDP, 443TCP, 5246/UDP, 5247/UDP ins Internet zu kommunizieren.
Konfigurationsschritte
1. Einschalten von CAPWAP auf WAN Interface
|
|
Die Verwaltung der Access Points über die Fortigate geschieht mit dem Protokoll CAPWAP. Damit die Fortigate Firewall Access Points über das WAN Interface verwalten kann, muss auf diesem Interface CAPWAP aktiviert werden. |
2. Erstellen der SSID
|
|
Unter Wifi & Switch Controller -> SSID -> + Create New wird eine neue SSID erstellt. Dabei müssen die gelb markierten Parameter konfiguriert werden. Damit später das Splitt-Tunneling funktioneirt ist es insbesondere sehr wichtig, dass der Defaultgateway der IP der Fortigate auf diesem Interface entspricht. Die anderen Parameter wie Name, SSID, Security Mode, IP Range etc. können nach gutdünken angepasst werden. Nachdem diese SSID konfiguriert wurde, muss ein zusätzlicher Parameter wie folgt auf der CLI konfiguriert werden: # config wireless-controller vap # edit [Name of SSID Profil] # set split-tunneling enable # end |
3. Erstellen FortiAP Profil
|
|
Unter Wifi & Switch Controller -> FortiAP Profiles -> + Create New wird ein neues FortiAP Profil erstellt. Dabei müssen die gelb markierten Parameter konfiguriert werden. Inbesondere wichtig ist hier, dass der korrekte AP Typ (AP-24d in diesem Fall) gewählt wird, und dass die zuvor erstellte SSID gewählt wird. Verfügt der Access Point zusätzlich über LAN Ports, so kann definiert werden, welches Netz an diesen LAN Ports ausgegeben werden soll. Es kann entweder das Netz am Remotestandort ausgegeben werden (Bridge to WAN) oder auch mittels NAT gearbeitet werden. Wird gewünscht dass hier das selbe Netz wie bei der SSID verwendet werden kann, so muss dies ebenfalls mittels "Bridge to SSID" und wahl des entsprechenden Netzes hinterlegt werden. Nachdem das FortiAP Profile konfiguriert wurde, können über die CLI zusätzlich die Netze konfiguriert werden, welche eben nicht über den VPN Tunnel gehen sollen, sondern lokal ausgekoppelt werden sollen. Im obenstehenden Beispiel wäre dies das Netz 192.168.1.0/24 welches sich hinter dem Swisscom Router befindet. Somit hat ein Gerät hinter dem FortiAP folgende Kommunikationsmöglichkeiten:
# config wireless-controller wtp-profile # set split-tunneling-acl-local-ap-subnet enable # config split-tunneling-acl # edit [Use a integer example "1"] # set dest-ip [IPv4 address as 192.168.1.0/24] # end Wird gewünscht, dass nur gewisse Netze an den Hauptstandort geroutet werden sollen, und alles andere (inklusive Internetverkehr) lokal ausgekoppelt werden soll, so muss mit einer umgekehrten Maskierung gearbeitet werden, und hier in der Konfiguration alle Netze angegeben werden, welche nicht durch den Tunnel sollen. Der hier konfigurierte CAPWAP Tunnel wird ausserdem standardmässig nicht mit DTLS verschlüsselt. Dies muss ebenfalls in der CLI konfiguriert werden: # config wireless-controller wtp-profile # edit [Name des entsprechenden Profils] # set dtls-policy dtls-enabled # end Der durch die DTLS Verschlüsselung anfallende Overhead beträgt je nach AccessPoint ca. 20%. |
4. Vorprovisionieren des AP
|
|
Unter Wifi & Switch Controller -> Managed FortiAPs -> + Create New kann nun der zu verbindende Accesspoint vorkonfiguriert werden. Wichtig hierbei ist die korrekte Seriennummer, sowie das entsprechende vorgängig erstellte FortiAP Profil. Hat sich der Access Point bereits bei der Fortigate gemeldet, so sieht man dies anhand der IP unter der Kategorie Managed AP Status. |
5. Erstellen der Firewall Policy
Damit der Datenverkehr zwischen dem AP und dem Internet, sowie zwischen dem AP und den internen Ressourcen gewährleistet werden kann, benötigt es auch entsprechende Firewall Regeln:
6. Definieren der Management IP auf dem AP
Damit der AP nun den Weg zu seinem Controller findet, wenn er das erste Mal am Remote Standort eingesteckt wird, müssen wir ihm hierfür die IP konfigurieren. Dies geschieht auf dem Accesspoint direkt. Ein nicht konfigurierter Accesspoint hat standardmässig die IP 192.168.1.2 auf dem WAN Port. Auf diese kann man sich mittels Telnet verbinden, um die entsprechende Konfiguration vorzunehmen. Ein Zugriff auf den Access Point ist allenfalls auch via USB und FortiExplorer möglich. (Siehe FortiExplorer Handbuch)
C:\Users\huberch>telnet 192.168.1.2 FAP24D3X15001883 # login: admin FAP24D3X15001883 # cfg -a AC_IPADDR_1=172.20.120.142 FAP24D3X15001883 # cfg -c FAP24D3X15001883 # exit
7. Verbinden
Nachdem der Access Point mit dem Internet verbunden wurde, wird er innerhalb von 3 - 5 Minuten eine Verbindung zu seinem Fortigate Controller aufnehmen. Dies kann im GUI überprüft werden:
Quellen und weiterführende Informationen:
Log
Wie muss eine Fortigate konfiguriert werden, damit sie zu Analysezwecken auf ein Kiwi Syslog loggt?
Einleitung:
Die folgende Anleitung wird dann relevan, wenn von einer Fortigate Firewall auf einen Syslogserver geloggt werden muss, ohne dass auf FortiCloud zurückgegriffen werden kann (wenn beispielsweise kein Internetzugriff existiert). Kiwi Syslog ist ein kostenfreier Basic-Syslogserver, welcher unter Windows installiert werden kann.
Konfiguration Fortigate:
Damit die Fortigate Firewall möglichst viel Logs auf den Syslogserver schreiben kann, müssen einige Einstellungen vorgenommen werden:
| Konfiguration über die CLI:
|
config log memory setting set status enable end config log null-device setting set status enable end config log gui-display set resolve-hosts enable set resolve-apps enable end config log setting set fwpolicy-implicit-log enable set local-in-allow enable set local-in-deny-unicast enable set local-in-deny-broadcast enable set local-out enable set log-invalid-packet enable end |
Mit folgender Einstellung wird der Firewall mitgeteilt, wo der Syslogserver steht, an welchen die Logs gesendet werden sollen:
| Konfiguration über die CLI:
|
config log syslogd setting set status enable set server "ip-des-syslog-servers" end |
Die Firewall sendet nun die Syslogs der hier konfigurierten IP via 514 UDP.
Damit allenfalls auch erlaubter Traffic geloggt wird, muss das Logging pro gewünschte Firewallregel eingeschaltet werden:
| Konfiguration über die CLI:
|
config firewall policy edit 1 set logtraffic all end |
Konfiguration Kiwi Syslog Server
Der Installer für den Kiwi Syslogserver kann hier oder hier:
Datei:Kiwi-Syslog-Server-9.6.3-Freeware.zip heruntergeladen werden.
Nach der Installation des Tools muss folgender Parameter unter dem Menüpunkt Setup angepasst, und die IP des lokalen Adapters angewählt werden, auf dem die Logs empfangen werden:
Sobald diese Einstellung gespeichert wurde, kommen die Logs im Kiwi Syslog Programm an.
