FortiGate:FAQ
FortiGate-6.0 und FortiGate-6.2:FAQ
Vorwort
Dieses FAQ ist für Fortinet Systeme basierend auf FortiOS 6.0 und/oder FortiOS 6.2 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 von der 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
Request of Proposal
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 ein entsprechender FortiGate Device identifiziert. Möchte man die "Hardware Revision" herausfinden einer FortiGate 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 CLI folgenden Befehl absetzt erhält man die "Hardware Revision" Information:
# 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 über CLI. Wenn diese Informationen benötigt wird, muss über ein Customer Care Ticket die entsprechende Information der "Hardware Generation" nachgefragt werden 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 zB um eine FG-70D. Das bedeutet, wenn eine neue "Hardware Revision" für diesen Device Release 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 zB "P15978-02". Somit kann anhand der PN Nummer keinen Rückschlüss gezogen werden, über die nötige Information von:
PN Nummer (Hardware Revision) + Hardware Generation
Diese Information 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 welcher FortiGate Device zB über wieviel "Memory" verfügt, ein "SOC" und/oder "NP" verbaut ist?
Nachfolgend eine Aufstellung die zeigt über welche Komponenten wie "SOC, NP, Memory, Storage ein FortiGate Device verfügt:
NOTE 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 zB CPU, RAM, Flash usw. Auskunft gibt: Datei:Fortinet-Hardware-Schematics.pdf
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?
Wenn für einen Kunden ein FortiGate Device evaluiert werden soll stellt sich jeweils die Frage welches ist das richtige Gerät für diesen Kunden? 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 den 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 dieser 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 den richtigen Device für den Kunden auszuwählen:
Datei:ProductMatrix.pdf
Zu den verschiedenen FortiGate Devices stehen jeweils die "Datasheet" zur Verfügung die nochmals detailliert über den jeweiligen FortiGate Device Auskunft gibt. des Weiteren stehen zu den "Datasheet" ebenso die "Quickstart" Guide zur Verfügung die zeigen "was" zum jeweiligen Device mitgeliefert wird sowie das Aussehen:
Fortinet:ProduktInfo#FortiGate
des Weiteren steht für die Produkte Information der Produkt Guide zur Verfügung der 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" das für jeden Device zur Verfügung gestellt wird, temporär geladen werden. 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
| NOTE: | Damit man zu diesem Link gelangt muss anhand eines Support Accounts eingeloggt werden sowie damit das
entsprechende Image runtergeladen werden kann, muss die entsprechende Serien Nummer des Devices eingegeben werden. Dies muss durchgeführt werden da jeder Device identifiziert werden muss anhand der Revision und Generation 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 benützen 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 wurde (kein Passwort) kann anhand des Befehls "diagnose hqip start" 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) in den Memory Bereich temporär installiert. Der Output der Serial Konsole muss "geloggt" werden damit es später dem Fortinet Support übermittelt werden kann. 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 sowie das Skript ausgeführt wird:
-> 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 eine 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 Test 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 durch mit dem User "admin" (kein Passwort). 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 worden. Wenn es nach dem Neustart zu Hinweise/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 zB 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 das diesen "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
Gibt eine Übersicht wie die Luftzirkulation (Airflow) in einer FortiGate funktioniert?
Im Nachfolgendem Dokument wird gezeigt wie die Luftzirkulation/Kühlung in den entsprechenden FortiGate Devices aufgebaut ist und wie diese funktioniert:
Datei:Fortinet-Hardware-Airflow.pdf
Wie kann ich unter die verschiedenen Hardware Informationen eines FortiGate Devices anzeigen lassen?
Um die detaillierten Hardware Informationen auf einem FortiGate Device aufzulisten steht der folgende Befehl zur Verfügung:
| Konfiguration über CLI |
# get hardware [cpu | memory | nic | npu | status] |
Somit kann anhand der Optionen folgendes ausgeführt werden:
| Konfiguration über 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 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 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 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 Benutzung zu erhalten siehe nachfolgenden Artikel: Artikel Benutzung Memory anzeigen lassen |
| Konfiguration über 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 CLI get hardware npu |
# get hardware npu legacy legacy np1 np1 np2 np2 np4 np4 Dieser Output wird nur angezeigt sofern der entsprechende Device auf dem dieser Befehl ausgeführt wird auch einen "NPU" (Networking Processing Unit) enthält. Wenn es sich um einen Device mit integrierten NPU handelt dh. SoC wird kein Output geliefert. |
Was bedeuten die verschiedenen LED's Stati über die ein FortiGate Device am FrontPanel verfügt?
Ein FortiGate Device verfügt am FrontPanel über verschiedene LED's dh. zB High Availability, Power, Status usw. Diese können verschiedenen Stati anzeigen. Die Bedeutung der verschiedenen LED's sind im nachfolgenden Dokument anhand einer FG-30E, FG-60C sowie FG-100D beschrieben:
Datei:FortiGate LED Specs.pdf
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 einer 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. Folgendermassen muss dabei vorgegangen werden:
| Konfiguration über das WebGui | Durchzuführende Schritte |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Über die CLI stehen zwei Befehle zur Verfügung, mit welchen die Temperaturen und Alarme auf FortiGate überprüft werden können. Mit diesen Befehlen können mehr Informationen ermittelt werden:
| Konfiguration über CLI | Beschreibung |
|---|---|
# 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 jeder Komponente 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 Schwellenwerte 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
| |
| NOTE |
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 Falles zurückgesendet werden 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 das folgende CLI Kommando
| Konfiguration über CLI |
# execute erase-disk [SYSTEM | Internal] |
Wenn ein Device aus Gründen der "Security Gründen" 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, der es ermöglicht bei einem RMA Austausch den Device selber zu entsorgen, anstelle diesen dem Hersteller zurück zu senden. Dieser Service wird "FortiCare RMA Secure Service" genannt. Weitere Informationen sind im folgenden 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 Fehler enthält?
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. Um die Disk's aufzulisten benutze folgenden Befehl:
|
NOTE: |
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 gewählt werden. Daraus ergiebt 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 der gewünschte Device gesetzt/gewählt wurde/ist sowie sofern 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 ausführt siehe nachfolgenden 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" (zB Stromunterbruch) im FortiOS 5.2.x die Funktion eingebaut, dass nach einem "unclean shutdwown" während dem Start Prozess dies erkannt wird und automatisch ein "filesystem check" ausgeführt wird. Diese wird "nicht" anhand eines "expliziten" Disk Tst aufgeführt sondern ähnelt einem "fsck" das auf einem Linux System ausgeführt wird. In diesem Vorgang wird durch das System bemerkt das 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. zB 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 wird ein Neustart des Devices ausgeführt und dieser "filesystem check" 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 die grösseren Devices stehen zusätzlich für die Redundanz ebenfalls "RPS Devices" (Redundand PowerSupply) zur Verfügung. Welche Geräte kompatible sind zu den seperaten "RPS Devices" siehe nachfolgender Artikel:
Fortinet:ProduktInfo#FortiRPS
Nachfolgende Tabelle zeigt für welchen FortiGate Device welches sperate 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 sowie FortiAP-S "PowerSupplies" zur Verfügung. Weitere Informationen dazu siehe nachfolgender 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 Huawai einsetzen?
Dies ist möglich jedoch ausgiebig vorgängig 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 Huawayi Electrical Transceiver SFP Module 1000Base T
NOTE Durch Fortinet werden ebenfalls nicht eigenen Transceiver eingesetzt sondern von Fremdherstellern dh. wird ein Transceiver
über Fortinet bestellt, wird ein Transceiver zB von Huaway 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 Device's 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 das 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 Desweiteren 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 befindet sich im folgenden Dokument:
Datei:FortiTransceivers-Datasheet.pdf
Was sind die genauen Spezifikationen der SFP's Module die 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 für die 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 aufgelistet der SFP Module die von Fortinet für die FortiGate Devices geliefert werden:
NOTE Die Informationen stammen aus einem Fortinet "Knowledgebase Artikel" und über diesen sind weitere Informationen verfügbar:
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 einen FortiGate Device überprüfen?
Bis anhin war es nicht möglich über einen FortiGate Device dh. über das FortiOS ein SFP Module/Tranceiver zu überprüfen dh. zB ob dieser korrekt erkannt wurde. Neu unter FortiOS 5.4 ist dies anhand des nachfolgenden Kommandos 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. Somit wird ein Fremdprodukt als SFP/QSFP Module/Transceiver eingesetzt, sollten die kurz anhand des nachfolgenden Kommandos ü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 Transeiver welche als orginal Fortinet Transeiver erworben wurden, zum teil als nicht supportet 3rd Party Module angezeigt:
Es handelt sich hierbei um einen BUG und dieser soll 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)
FortiCloud
FortiSandbox
FortiExplorer
USB Port
Konsolen Port
Was für ein Kabel wird für den Konsolen Anschluss (RS-232) benötigt?
Eine Fortigate Firewall kann über den Konsolenport, SSH oder HTTPS administriert werden. Für das initiale Setup oder bei Störungssuche ist der Konsolenport die beste Wahl. Der Konsolenport auf einer Fortigate kommt in Form einer RS232 Schnittstelle daher. Problematisch ist, dass heutigen Workstations und/oder Laptops nicht mehr mit einem RS232 Anschluss hergestellt werden. Als Workaround gibt es Adapterkabel von USB auf RS232. Folgende Adapter bietet ALSO in ihrem Sortiment:
USB Stecker Typ A
LINDY USB RS232 Converter w/ COM Port Retention RS-232 Port
Transfer Rate: up to 230 kBit/s
Chipset: FTDI
Hersteller Artikel-Nr.: 42686
ALSO Artikel-Nr.: 2909413
EAN-Code: 4002888426862
Link: https://www.also.ch/ec/cms5/6110/ProductDetailData.do?prodId=2909413
USB Stecker Typ C
LINDY USB Type C Serial Converter
Hersteller Artikel-Nr.: 43248
ALSO Artikel.Nr.: 3023950
EAN-Code: 4002888432481
Link: https://www.also.ch/ec/cms5/6110/ProductDetailData.do?prodId=3023950
Treiber:Datei:PL2303 Prolific DriverInstaller v1190.zip
Bei beiden Adaptern wird kein RS232-to-RJ45 Kabel mitgeliefert. Diese kann unter folgender ALSO-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 Pin-Belegung 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 PIN-Belegung der Seriellen Konsolen (RS-232 / DB9 / RJ-45 / AUX) auf einem FortiGate Device aus?
Nachfolgend die technischen Informationen über die Pin-Belegung der Seriellen Konsole der Fortinet Produkte wie FortiGate, FortiAnalyzer, FortiManager sowie FortiMail. In den meisten Fällen haben die Devices eine RJ45 Schnittstelle als Konsolen Port. Ältere Modelle können auch einen RS-232 DB9 Port haben. Es gibt auch Modelle mit einem AUX Port. Gemeinsam haben alle, dass sie die gleiche Pin-Belegung benutzen:
| Pin Belegung RJ45 |
|
| Pin Belegung RS232 |
|
Kann ich auf einer FortiGate den Seriellen Konsolen Port (RS-232) deaktivieren?
Wenn man zum Beispiel verhindern möchte, dass in einem Datacenter usw. über den Seriellen Konsole Port unerlaubt zugegriffen wird, kann dieser mit folgenden Befehl deaktiviert werden:
| Konfiguration über CLI |
# config system console # set login disable # end |
Es wird nur der "Konsolen Port" deaktiviert und der "USB" Port muss sofern gewünscht separat deaktiviert werden:
| Konfiguration über CLI |
# config system console # set fortiexplorer disable # end |
Web Gui
Wie kann ich den Hostname auf der Webgui Login Page sichtbar machen?
Wenn man sich über das WebGUI auf die Fortigate verbindet, wird Default mässig auf der Anmeldemaske der Hostname der Firewall nicht angezeigt.
Um den Hostname auf der Anmeldemaske zu aktivieren, muss dies über die CLI folgendermassen aktiviert werden:
| Konfiguration über CLI |
# config system global # set gui-display-hostname [enable | disable] # end |
|
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:
Die Abhängigkeiten beispielsweise von einem Interface sind jeweils hier zu finden:
Im CLI:
| Konfiguration über 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ät auf seine Seriennummer gesetzt werden:
# 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, der 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:
get hardware nic internal5 | grep Current_HWaddr Current_HWaddr 90:6c:ac:a9:d7:47
Der folgende Befehl zeigt alle TCP Session an inklusive Zeilennummer welche sich in der Session Liste befinden:
# 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 noch 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, um die komplette Konfiguration anzuzeigen. Das folgende Beispiel zeigt den Unterschied , wenn -f verwendet wird und wenn -f nicht benutzt wird:
|
show | grep ldap-group1 Ohne -f |
show | 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
|
Upgrade
Wo finde ich den Upgrade Pfad um auf eine höhere FortiOS Version upzugraden?
Seit September 2018 hat Fortinet folgendes Tool zu Verfügung gestellt:
Alternativ kann der Upgradepfad auf dem Supportportal im Download Center entnommen werden (support.fortinet.com). Leider ist dieser nur bis zur Startversion 5.2.9 hinterlegt.
| support.fortinet.com -> DOWNLOAD -> FIRMWARE IMAGES |
|
Wenn von einer früheren Version upgegradet werden soll, wird unter folgendem Link weitergeholfen:
Was muss ich beachten wenn ich auf das FortiOS 6.2.2 upgraden will?
|
Vorsicht wenn man eine FortiGate welche einen SoC3 verbaut hat, auf die Version 6.2.2 upgraden will, muss man beachten, dass die Authentifizierung mit Mobile Token für 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 man aus den Release Notes 6.2.2 entnehmen:
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 sich mit dem SSL-VPN zu verbinden. Beim Passwortfeld 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 ausdrücklich auf versuchen verwiesen im Ticket für diesen Workaround.
Backup / Restore
Wie führe ich auf der FortiGate ein Backup durch?
Backup ist nur für Feiglinge. Dieser Spruch hört oder liest man oft, wenn aber doch einmal die FortiGate ersetzt werden muss ist man froh wen 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 zu kommen.
Firmware
Wo finde ich die Release Notes für FortiOS 6.0?
Die aktuellen Release Notes für das FortiOS 6.0 kann in der folgenden Tabelle entnommen werden:
Die aktuellen Release Notes welche auch immer gepflegt werden von Fortinet selbst findet man auf der Docs Seite :
Wo finde ich die Release Notes für FortiOS 6.2?
Die aktuellen Release Notes für das FortiOS 6.2 kann in der folgenden Tabelle entnommen werden:
| FortiOS 6.0 Release Notes |
Die aktuellen Release Notes, welche auch immer gepflegt werden,findet man auf der https://docs.fortinet.com Seite:
Wann geht eine FortiOS Version end of Support?
Das FortiOS 6.0 wird 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 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 keinen technischen Support mehr von Seite Fortinet her. Das heisst, Tickets werden erst bearbeitet, wenn die FortiGate auf einen aktuellen Software Stand gebracht wurde. Der ganze Life Cycle von einer FortiOS Generation dauert also 54 Monate.
Mehr zum TAC Support : Fortinet:Support-Case#Was_wird_vom_Technischen_Fortinet_Support_.28TAC.29_nicht_unterst.C3.BCtzt.3F
Auf der folgenden Tabelle sind die Daten welche von 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 | 2020 | -- | -- |
(1) Das v4.0MR3 End of Support Date für Hardware, die 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, Fragen und die Einreichung von Fehlerberichten.
Quelle: https://support.fortinet.com/Information/ProductLifeCycle.aspx
Wie wird eine FortiGate von Grundauf mit einem entsprechenden FortiOS installiert (staging)?
Wenn ein FortiGate Device von Fortinet ausgeliefert wird, kann dieser FortiGate 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, basieren diese oft auf einem sogenannten "Branche Release". Ein "Branche Release" ist eine Vorabversion eine "GA" Releases (General Availibility). Aus diesem Grund Empfehlen wird bei jedem FortiGate Device ein "staging" durchzuführen mit dem FortiOS der Wahl. Dabei spielt es keine Rolle welcher FortiOS auf dem FortiGate Device existiert oder welche Konfiguration usw. vorhanden ist, denn durch ein "staging" wird der FortiGate Device von Grundauf neu installiert und sämtliche Konfiguration sowie das bestehende FortiOS gehen dabei verloren. Somit sollte jeder FortiGate Device in diesem Sinne aufgesetzt werden. Absolute 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 somit muss mit einem entsprechenden Device zB "USB Konverter" gearbeitet werden. Wir empfehlen den "EX-1301-2" USB Konverter der 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 von einem TFTP Server auf den FortiGate Device um diesen nachträglich zu installieren. Aus diesem Grund muss auf der entsprechende Workstation die verbunden ist mit dem FortiGate Device ein TFTP Server installiert werden. Wir empfehlen folgenden TFTP Server der frei 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 innerhalb dieses Menüs "TFTP Server". Starte den TFTP Server anhand dieses Menü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 dafür ist der Folgende: Beim ersten Start des TFTP Servers wird das "TFTP Server Root Directory" angelegt und der Server gestoppt. Per Standard befindet sich das "TFTP Server Root Directory unter folgenden Verzeichnis "C:\TFTP-Root". Kontrolliere kurz ob dieses Verzeichnis angelegt wurde sowie starte den TFTP Server abermals 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 FortiOS Image um in "image.out". Als nächsten Schritt konfiguriere die Netzwerkkarte der entsprechende Workstation die mit dem FortiGate Device über "Consolen Port" verbunden ist mit folgender IPv4 Adresse und Subnet Maske sowie deaktiviere sämtlichen anderen Netzwerkkarten wie zB für 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 varieren. Bei "staging" Prozess kann diese jedoch eruiert werden!
Die Konfiguration der Netzwerkkarte benötigt keinen "Default Gateway" sowie 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 Uebertragung des FortiOS Image zum TFTP Server erlaubt wird. Aus diesen Ausführung ergiebt 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 benütze ein normales RJ-45 Kabel. Der entsprechende
Netzwerk Port in unserem Beispiel "WAN1" ist abhängig vom FortiGate Device. Der entsprechende zu benützende Port wird während
dem "staging" Prozess aufgelistet!
Nun muss der FortiGate Device neu gestartet werden (execute restart) oder ein "power-on" ausgeführt werden. Sobald der FortiGate Device startet muss auf folgende Meldung geachtet werden um den Start Prozess abzubrechen und um in das Bios des FortiGate Devices zu gelangen:
| Konfiguration über 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 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 diesen FortiGate Device gilt:
| Konfiguration über 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 durch betreffend der Konfiguration des "staging" Prozesses:
- Ist das RJ-45 Kabel am korrekten Netzwerk Port der FortiGate angeschlossen (Beispiel: WAN1)
- Wurde die korrekte IPv4 Adresse sowie 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 Postion "[F]: Format boot device.":
| Konfiguration über 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 die Position "[T]: Initiate TFTP firmware transfer." aus:
| Konfiguration über 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 der ein Transfer des Files bestätigt wird! Auf dem FortiGate Device wird eine korrekte Uebertragung folgendermassen angezeigt:
| Konfiguration über 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 benutzt. Wird "B" für "backup" gwählt wird die Partition nicht "active" gesetzt und somit beim nächsten Neustart nicht benutzt. Wenn "R" für "run" ausgeführt wird so wird das FortiOS in den Memory Bereich installiert dh. nach einem Neustart des Devices steht 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" benutzt wird zB 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 benütze folgende Login Informationen:
| Konfiguration über CLI |
User: admin Password: [Kein Passwort] |
Nun kann die "disk" formatiert werden mit folgenden Befehl:
| Konfiguration über 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 zB eine FG-50E nicht ausgeführt werden. Der Grund ist der Folgende: 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 ausgeführt werden:
| Konfiguration über 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" die 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 das in den Flash Bereich kopiert wird angelegt. Dabei muss berücksichtigt werden, dass alle Informationen der "disk" verloren gehen. Somit FortiGate Modelle die 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 unterschieden werden zwischen folgenden Möglichkeiten
- Der FortiGate Device verfügt über einen internene Hardware "Switch Controller"!
- Der FortiGate Device verfügt über keinen internene 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 dh. nach dem ausgeführten Neustart sind auf den Interfaces für den internen Switch die nun einzeln verfügbar sind keine IP Adressen mehr konfiguriert. Um auf einen Zugriff über Mgmt. Interfaces des FortiGate Devices zu gewährleisten muss folgendes auf einem entsprechenden Interface ausgeführt werden:
Verifiziere die einzelnen Interface Namen
| Konfiguration über CLI |
# show system interface |
Konfiguriere ein entsprechendes Interface
| Konfiguration über 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 per Standard ein "redirect" auf "https" durchgeführt. Möchte man dies verhindern kann folgendes zusätzlich ausgeführt werden:
| Konfiguration über CLI |
# config system global # set admin-https-redirect [enable | disable] # end |
Der "staging" Prozess ist abgeschlossen und der FortiGate Device kann in Betrieb genommen werden!
Hier kann eine Anleitung heruntergeladen werden:
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 einwandfrei funktionieren. Der DNS Server ist eine globale Einstellung. Heisst, wenn mit VDOM gearbeitet wird, ist der System DNS Server für alle gültig. Konfiguriert werden die System-DNS-Einstellungen im Menu DNS:
| WebGui Menu : Network > DNS |
|
|
Über die CLI werden die System DNS Server folgendermassen 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 konfiguriert werden, wie lange ein DNS Eintrag im Cache gespeichert werden soll. Weiter kann auch konfiguriert werden wie viele DNS Einträge im Cache maximal gespeichert werden können.
| 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 "locak 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 die 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 relativ 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 welche authentifiziert und verschlüsselt ist aufgerufen. So bezieht der Client eine DNSSEC validierte Information vom Namensserver. So lesen keine Drittpersonen mit. Die Namensauflösung des Resovers erfogt dann im Klartext. Dies ist aber nicht so schlimm, da der Urheber der Anfrage nicht ersichtlich ist. Es soll aber bereits Pläne geben, dass die Kommunikation zwischen DNS-Resovler 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 Protokol. Falls der Dienst nicht verfügbar ist, wird in der Regel über UDP53 die Anfrage getätigt. (dies ist natürlich abhängig wie die Sicherheitseinstellungen des Systemes sind.) Auf der FortiGate ist es so eingestellt, wenn die DoT Anfrage nicht funktioniert wird normal über UDP53 die Anfrage unverschlüsselt abgesetzt.
Problematisch ist , dass der Port 853 an vielen Orten (Perimeter Firewalls, Hotels oder öffentliche Hot Spots) noch blockiert wird. Ausserdem bringt TCP, noch dazu in Kombination mit TLS, einiges an Verwaltungs-Overhead mit sich, der die für zügiges Surfen elementare Namensauflösung einbremst.
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 CLI |
# config system dns # set dns-over-tls [disable|enable|force] # set ssl-certificate "Fortinet_Factory" # end |
Wie kann ich auf einer FortiGate den DNS Cache löschen?
Der 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 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 ausliefert. 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 da 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 als «DNS Database» umgesetzt werden. Standardmässig ist dieses Feature auf der FortiGate NICHT ERSICHTLICH und muss erst unter folgendem Abschnitt konfiguriert werden:
| WebGui Menu : System->Feature Visibility' |
|
Das Feature DNS Database muss eingeschaltet werden: |
| Komfiguration ü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: | ||||||
|
Und nehme wir an im Internen LAN würde es ebenfalls die Domaine geben "mydomain.ch". 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 zurückgibt 192.168.1.1 da die Anfrage vom "INTERNEN" LAN kommt und nicht vom Extern. Um so eine konfiguration durchzuführen muss folgendes konfiguriert werden:
| Konfigurieren ü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 entsrpechende 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 benutzt 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 dh. 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 das der externe Port "Recursive" Anfragen absetzt:
|
| Komfiguration ü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:: |
| Komfiguration über die CLI: |
# config system dns-server # edit internal # set mode recursive # end |
Nun fehlt nur noch der letzte Schritt das heisst dem User muss über DHCP der entsprechende DNS Server zugewiesen werden:
| 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 so wird dieser ausgeliefert. Ist ein entsprechender Eintrag nicht vorhanden wird die Anfrage über das "wan" Interface an die externen DNS Server weitergewiesen (definierte System DNS Server).
Wie kann ich auf der Fortigate für den DNS Server und einer bestimmten Zone einen "Zone Transfer" aktivieren?
Wenn auf einer FortiGate ein DNS Server konfiguriert wird, 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 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 im folgenden Artikel entnommen werden:
FortiGate-6.0-6.2:FAQ#Wie_kann_ich_auf_einer_FortiGate_einen_Split-DNS_Server_einrichten.3F
Desweiteren ist bei der Komunikation zwischen "authoritativen" und/oder "none-authoritativen" Servern darauf zu achten, mit welcher IP die Komunikation durchgeführt wird. Dies bedeutet im normal Fall wird der "non-authoritative" Server (in unserem Beispiel die FortiGate) ebenfalls im "authoritativen" Server eingetragen. Kommuniziert die FortiGate nicht die gewünschte "Source IP Adresse" zum authoritativen Server, kann diese mit folgender Konfiguration entsprechend gesetzt werden:
| Konfiguration über 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 spricht man von einem Split DNS Server dh. dieser beantwortet Anfragen von bestimmten Source Adressen anderst 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 also zB "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 befindet- wird der Traffic von "mail.mydomain.ch" -da dieser mit der Public IP aufgelöst wird- zur Firewall gesendet. Der Grund ist Routing bedingt dh. "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 dh. wenn ein interner DNS Server vorhanden ist so wird ein "Forwarder" für "mydomain.ch" konfiguriert und für "mail.mydomain.ch" die IP Adresse zB "192.168.1.100" konfiguriert denn diese stellt die interne Adresse von "mail.mydomian.ch" dar. Ist kein interner DNS Server vorhanden kann die "Split DNS" Server Funktion auf einer FortiGate benutzt werden. Weitere Informationen siehe nachfolgenden Artikel:
FortiGate-6.0-6.2: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 kann die Funktion "dnstranslation" benutzt werden. Diese Funktion steht im Zusammenhang mit dem "Session-Helper". Um eine "dnstranslation" zu implementiren 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 konfiguriere diesen folgendermassen: # 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" siehe nachfolgender Artikel: Allgemein:Assigned-Internet-Protocol-Numbers-RFC |
| Schritt 2 |
|
Als nächstes konfigurieren wir die "dnstranslation" und zwar gemäss unserem Beispiel folgendermassen: # 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 sowie dessen Antwort werden folgendermassen auf der FortiGate abgearbeitet: Anfrage = User --> nslookup mail.mydomain.ch --> Anfrage an Public DNS Server --> FortiGate Policy Allow --> Public DNS Server Anfrage "mail.mydomain.ch" Antwort = Public DNS Server Antwort mail.mydomain.ch --> 212.59.153.125 --> FortiGate "Session-Helper" --> "dnstranslation" Funktion = 192.168.1.100 --> User NOTE wie hier in diesem Beispiel gezeigt kann die Funktion anhand "nslookup" getestet werden und somit verifiziert werden ob die "dnstranslation" korrekt funktioniert! |
In diesem Sinne kann jede DNS Anfrage die über die FortiGate läuft umgeschrieben werden. Natürlich ist diese Funktion nicht "nur" auf Public DNS Server beschränkt sondern nur auf Port 53 DNS (udp). Dies bedeutet diese Funktion "dnstranslation" kann ebenfalls für temporaere Umleitungen im internen Bereich benutzt werden. Diese Funktion kann oder sollte jedoch kein Split DNS Server ersetzen da die vers. Einträge nicht ersichtlich sind auf der FortiGate.
DDNS
DHCP
ARP
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 es empfängt oder die FortiGate selber erzeugt.
Alle Netzwerkgeräte, die 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 ein nächster Hop. Jeder Routing Hop im gerouteten Pfad erfordert eine Routingtabellensuche (Routing Lookup), um das Paket weiterzuleiten, bis dieses das endgültige Ziel erreichen kann.
Beim Routing von Paketen findet FortiGate zunächst eine passende Route in seiner Liste der Routen 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 es verschiedene Routenattribute, um die beste Route zu ermitteln.
Die richtige Routing-Konfiguration ist wichtig. Wenn Routen falsch konfiguriert sind, erreichen Pakete ihr Ziel nicht und gehen verloren.
Standardmässig sind viele Aspekte auf FortiGate stateful. Das bedeutet die FortiGate entscheidet 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 seine Session Tabelle. Alle folgenden Pakete werden gemäss Session Tabelle und nicht nach der Routingtabelle weitergeleitet. So werden alle Pakete, welche zu der gleichen Session gehören dem gleichen Pfad 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 ein zusätzliche Routingtabellen Lookups durch, um diese Informationen wiederherzustellen
Eine Methode der manuell konfigurierten Routen ist die statische Route. Wenn man eine statische Route konfigurieren, wird der FortiGate mitgeteilt: "Wenn du ein Paket siehst, dessen Ziel innerhalb eines bestimmten Bereichs liegt, sende dieses es über ein bestimmtes Netzwerkinterface an einen bestimmten Router". Es kann auch die Distanz und die Priorität so konfigurieren, dass die FortiGate die beste Route zu jedem Ziel ermitteln kann, das mehreren Routen entspricht.
In einfachen Heimnetzwerken ruft DHCP beispielsweise automatisch eine statische Route ab und konfiguriert diese selbstständig. Das ISP Modem sendet dann den gesamten ausgehenden Datenverkehr über den Internet-Router des ISPs, der Pakete an ihr Ziel weiterleiten kann. Dies wird typischerweise als Standard-Route bezeichnet, da der gesamte Traffic, der nicht mit anderen Routen übereinstimmt, standardmässig über diese Route geleitet wird. Das hier gezeigte Beispiel ist eine Standardroute.
Das Ziel-Subnetzwert von 0.0.0.0.0.0/0.0.0.0.0 passt zu allen Adressen innerhalb eines Subnetzes. Die meisten FortiGate, als Perimeter Gerät des Netzwerkes fungieren, verfügen über mindestens eine dieser Standardrouten, um sicherzustellen, dass der Internettraffic an den ISP weitergeleitet wird.
Subnetze welche auf der FortiGate direkt eine Layer 2 Konnektivität verfügen, brauchen keine statische Route
Jede Route in der Routingtabelle hat die folgenden Attribute:
- Network
- Gateway IP
- Interfaces
- Distance
- Metric
- Priority
Distanz:
Die Distanz oder 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 diejenige 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. OSPF gilt als genauer als RIP.
Die folgenden Werte sind die Distanzen auf der 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 diese beide in der Routingtabelle aktiv. Welche Route wird also verwendet, um passende Pakete zu routen? In diesem Szenario verwendet FortiGate den Prioritätswert als Tiebreaker, um die beste Route zu ermitteln. Routen mit geringerer Priorität werden immer 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 ermittelt anhand von Routenattributen, welche durch das Routing zu Verfügung gestellt werden. (Metric, Distanz, Priorität ..) Was passiert also, wenn zwei oder mehre 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 Ausgleichstraffik 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 Interfacevolumenschwellenwerten 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 Sessions 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 FortiGate eine primäre Route, bis ein Schwellenwert für das Verkehrsaufkommen 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 pro Interface konfiguriert werden: # config system interface # edit [INTERFACE_NAME] # set spillover-threshold [Wert zwischen 0 und 16776000 definieren] |
BEISPIEL:
In diesem Szenario hat 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, die 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- und Sicherheitsgründen gelöscht. Reverse Path Forwarding (RPF) ist ein Mechanismus, der FortiGate welches das Netzwerk vor IP-Spoofing-Angriffen schützt. Es wird überprüft, ob es eine Route zurück zur Destination des Pakets gibt. Diese Prüfung wird auf dem ersten Paket einer neuen Session durchgeführt. Es wird auch nach einer Routenänderung auf dem nächsten Paket in der ursprünglichen Richtung ausgeführt.
Es gibt zwei RPF-Methoden:
- Loose
- Strict
Veranschaungsbeispiel:
|
Diagramm |
Beschreibung |
|
|
In diesem Szenario wird der eingehende Internetverkehr, der bei wan1 ankommt, akzeptiert, da die Standardroute eine gültige Route zurück zur Source ist. Es gibt jedoch zwei Interfaces, die 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 über Port1. So wird der Datentraffic von 192.168.4.0.0/24 nach Port1 eingestellt, weil er bei der RPF-Prüfung fehlgeschlagen ist. Das andere Interface, die den Datentraffic nicht weiterleitet, ist wan2. Während wan2 physisch mit dem Internet verbunden ist, sind die einzigen IP-Adressen, die als Sourcen oder Destinationen für wan2 gelten, die im Subnetz 198.18.2.0/24. So wird eingehender Datentraffic von einer anderen Source nicht durch die RPF-Prüfung geleitet und wird 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 |
|
|
So fixen wir das Problem: 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 behoben, indem eine statische Route hinzugefügt wird. In diesem Fall ist es eine Standardroute für wan2. Diese zweite Standardroute muss die gleiche Distanz haben wie die Standardroute für wan1. Dadurch 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 sind zwei Routen mit gleicher Distanz, aber unterschiedlicher Priorität konfiguriert worden. Eine Route ist also die beste (die mit der niedrigsten Priorität), aber beide sind aktiv. Die beste Route wird für den ausgehenden Traffic verwendet, aber beide können eingehende Verbindungen 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
|
Das RPF kann entweder stricte oder loose durchgesetzt werden.
Im loose Modus wird das Paket akzeptiert, solange es einen aktiven Weg zur Source-IP über das eingehende Interface gibt. Es muss nicht die beste Route sein, sondern nur eine aktive.
Im Strict Modus überprüft FortiGate, ob der beste Weg zur Source-IP-Adresse über das eingehende Interface führt. Die Route muss nicht nur aktiv sein (wie im Falle des loose Modus), sondern auch die beste.
Die RPF-Prüfung kann auf zwei Arten deaktiviert werden. Wenn man asymmetrisches 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 tun:
|
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 |
|
Diagramm |
Beschreibung | ||
|
|
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 er zuvor kein SYN-Paket an 10.0.1.2 gesendet hat), antwortet er mit einem RST-Paket (Reset). | ||
|
|
Was passiert also im gleichen Szenario, wenn Strict RPF verwendet wird? Das stricte RPF löscht das SYN-Paket. Auch wenn die wan1-Standardroute eine aktive Route für das Subnetz 10.0.4.0/24 ist, ist sie nicht die beste Route. Die beste Route ist über das Interface port1, da diese einen niedrigeren Distanzwert hat.
Obwohl das stricte RPF sicherer ist, kann es bei Verwendung des dynamischen Routings zu Fehlalarmen führen. Dynamische Routen können sich schnell ändern, und sie können die FortiGate veranlassen, legitime Pakete jedes Mal fallen zu lassen, wenn sich die bevorzugte Route ändert. Im Allgemeinen wird empfohlen, looses RPF in Kombination mit Firewallregeln zu verwenden, die gefälschten Datenverkehr blockieren, anstatt zu diesem Zweck strictes RPF zu verwenden. |
Wie wird auf einer FortiGate das Routing abgearbeitet?
Dieser Artikel beschreibt wie die FortiGate das Routing abarbeitet, sowie selektiert das heisst welches Routing zuerst greift wie zum Beispiel Cache, Policy Routen usw. Wenn verschiedenen Routings benützt werden zm Beispiel Policy Route (Layer 4), Distanz (Layer 3) ist es Wichtig zu wissen, wie diese Routings abgearbeitet wwerden. 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 dh. Ethernet Packete werden basierend auf deren "MAC Adressen" abgearbeitet und "nicht" anhand deren IP's. |
Wie der "cache" eines Routing eingesehen werden kann sowie auf den neusten Stand gebracht wird siehe nachfolgender Artikel: Routing Cache anzeigen
Nachfolgendes Diagramm zeigt wie ein "lookup" im Zusammenhang mit den verschiedenen "Routing Tabellen" durchgeführt wird:
|
Diagramm |
Beschreibung |
|
|
Dieses Diagramm zeigt auf das verschiedenen "Routing Tabellen" existieren die für das verschiedene eingesetzte 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! |
Wie kann ich auf einer FortiGate die Routingtabelle ansehen?
Wenn ich ab dem FortiOS 5.4 die Routing Tabelle auf einer FortiGate sehen möchte muss ich folgendes beachten. Ich habe die Möglichkeit die aktiven Routen in der Routingtabelle anzuschauen (Nur Routen welche momentan aktiv sind). Es gibt auch ein Kommando, mit welchem ich alle Routen sehen kann, welche in der Routingtabelle eingetragen sind. (aktive aber auch inaktive Routen)
Über das WebGui kann ich nur die aktive Routingtabelle anschauen:
|
Menu: Monitor -> Routing Monitor |
Konfiguration über CLI: get router info routing-table all |
|
Über das WebGui kann ich nur die aktive Routingtabelle anschauen: Gehe auf Monitor -> Routing Monitor |
Um auf der CLI nur die "aktiven" Routing Einträge aufzulisten kann folgendes Kommando benutzt 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 Routingtabelle sehen möchte (aktive und inaktive Routen) kann ich die Routing Datenbank folgendermassen 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
|
Weitere Optionen für das Kommande get router info routing-table sind folgende:
| Parameter | Beschreibung |
|---|---|
| details | Anzeigen der Detail Informationen der Routingtabelle |
| all | Anzeigen von allen Einträgen in der Routingtabelle |
| 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 Routingtabelle der verbundenen Routen an |
| database | zeigt die Datenbank der Routingtabelle an (alle Routen aktiv sowie passiv) |
Wie kann ich auf einer FortiGate den Routing "cache" auflisten und aktualisieren?
Auf der FortiGate wird ein Cache angelegt. Dies bedeutet, wenn ein Routing Eintrag erstellt wird (wie zum Beispiel eine statische Route konfiguriert wird), wird im Hintergrund ein Eintrag im Cache angelegt, sobald diese Route das erste Mal benutzt wird. Dadurch muss die FortiGate nicht jedes Mal, die Routing Tabelle konsultieren, sondern kriegt bei einer nächsten Anfrage die Routinginformationen schneller direkt aus dem Cache. Wenn ich sehen will, welche Routen im Cache sind kann ich folgendes Kommando 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 und 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 kann dies indirekt über das refreshen der Routing Tabelle geschehen. Mit diesem Kommando execute router restart werden im Cache und im Kernel die Routing Informationen auf den neuesten Stand gebracht:
|
Konfiguration über CLI: execute router restart |
# execute router restart |
Aus diesem Grund ist es dringend empfohlen nach jeder Routing Aenderungen diesen Befehl abzusetzen um zu gewährleisten das alle Routing Informationen alle Routing Tabellen auf den neusten Stand gebracht werden.
Was ist eine Blackhole-Route?
Eine Blackhole-Route ist eine Route, die den gesamten an sie gesendeten Datentraffic unterbindet. Dies funktioniert sehr ähnlich wie /dev/null in der Linux-Programmierung. Blackhole-Routen werden verwendet, um Pakete zu entsorgen, anstatt auf verdächtige Anfragen zu reagieren. Dies bietet zusätzliche Sicherheit, da der Absender keine Informationen aus dem Destinationsnetzwerk bekommt.
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 wen das Tunnelinterface aktiv ist (und somit der VPN Tunnel up), ein Routing Eintrag erstellt. Wenn dieser Tunnel down geht und somit das Tunnelinterface down geht, wird die nächste zutreffende Route für die Session benutzt. Meist ist dies die Default Route zum Standard Gateway. Das bedeutet, der Traffic welches für die remote Lokation des Tunnels gedacht ist, wird ins Internet geroutet. 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 in 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 |
Beschreibung |
|
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 das dieses Netz 172.16.16.0/24 auf das Interface vpn_to_sideB mit der Distanz 10 geroutet wird.
|
Routing Tabelle über das WebGui: |
|
Gehe ins Menu Monitor -> Routing Monitor
|
|
Routing Tabelle ü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:
|
Routing Tabelle über das WebGui: |
|
Gehe ins Menu Monitor -> Routing Monitor
|
|
Routing Tabelle ü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 anschauen (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 Range auf auf eine Blackhole-Route konfigurieren. Mit diesen drei Routen kann so jeglichen Traffic welcher in das Public WAN (INTERNET) geroutet wird, direkt abgefangen werden.
Für folgenden Private Netze kann also eine Blackhole Route defaultmässig eingerichtet werden:
Private Netze Gemäss RFC1918:
- 10.0.0.0/8
- 172.16.0.0/12
- 192.168.0.0/16
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 config router static 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 config router static 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 Privat IP Bereich siehe auch: https://de.wikipedia.org/wiki/Private_IP-Adresse
|
|
Wenn ein Class D Netz(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 wir Multicast Routen einrichten. 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 schalten als Perimeter Firewall. 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 Telefon 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 werden oder verifiziert werden, dass dieses ausgeschalten 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 Adressen Objekte erstellen für 224.0.0.0 - 224.255.255.255 und 239.0.0.0 - 239.255.255.255
| 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
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 |
Policy Routing
Email Service
SMS Service
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 erworben werden muss:
SMS-ELIC-100 FortiSMS - License for 100 SMS text messages
Der Lizenz Key kann über das folgende Kommando auf die FortiGate eingelesen werden:
| Konfiguration über die CLI |
# execute fortiguard-message add xxxx-xxxx-xxxx-xxxx-xxxx ---> Den Aktivierung Code der SMS Lizenz gemäss erhaltenem Dokument einfügen. # execute fortiguard-message update |
Das Guthaben kann folgendermassen ü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
Prozesse
System
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 der Powershell erstellt werden Folgender 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 Variable 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, welche 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
Role
Interface
Wie kann ich die Interface Statistik auf einer FortiGate anschauen?
Um die Interface Statistik anzuschauen kann über die CLI folgende Befehle eingegeben werden:
| Konfiguration über 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 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)
|
Switch Mode
Sniffer Mode / CTAP
Switch Controller
Administrator
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 wenn ich die Firewall per IP Adresse aufrufe (egal ob per CLI oder GUI).
| Konfiguration über 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 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 |
Beschreibung |
|
|
|
|
User / Gruppe
Wie konfiguriere ich eine Usergruppe?
|
Konfiguration über das WebGui |
Beschreibung |
|
|
|
|
| Konfiguration über CLI | Beschreibung |
config user group
edit "gr-Wartung"
set member "user1" "user2"
next
end
|
Die User können mit folgendem Syntax der Gruppe "USER" "NEXT-USER" .... "END-USER" hinzugefügt werden. |
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
|
Die Usergruppe wird mit dem Kommando set groups <GRUPPEN_NAME> hinzugefügt |
Im Monitor können authentifizierte User angeschaut werden:
Monitor -> Firewall User Monitor
Um den User zu deauthorizieren muss der entsprechende User mit Rechtsklick angewählt werden und dann der Button Deauthenticate gewählt werden.
Wie eröffne ich einen User mit 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 für eine erfolgreiche Authentifizierung. 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 |
Beschreibung | ||
|
| ||
|
| ||
|
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ührt werden.
| ||
| Konfiguration über CLI | Beschreibung | ||
config user local
edit "user1"
set type Password
set two-factor sms
set sms-phone "41791234567"
set password "password"
next
end
|
Den User konfigurieren.
| ||
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
|
Bei der Policy muss der User in der Source angegeben werden, damit die Authentifizierung zieht. In dieser Regel sind ANY Services konfiguriert. Für einen produktiven sicheren Betrieb empfiehlt sich nur die Services freizuschalten, welche auch benötigt werden. Weiter empfiehlt es sich entsprechende UTM Features zu aktivieren um sich optimal abzusichern. |
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 ungültig.
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 und den dazugehörenden 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 und den dazugehörenden 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 zB 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 Status: State Value UDP Reply not seen 0 UDP Reply seen 1 Proto_state Feld für ICMP (proto 1) Für ICMP existiert kein Status und ein FortiOS zeigt für ICMP immer "proto_state=00" | ||||||||||||||||||||||||||
|
expire=21 |
Diese Positione gib an wie lange die Session noch gültig ist bis diese gelöscht wird resp. abgelaufen ist (TTL = time to live). | ||||||||||||||||||||||||||
|
origin-shaper= |
Gibt an ob ein Traffic Shaper benutzt wird. Wenn ein Traffic Shaper benutzt wird werden Informationen ausgegeben betreffend Priorität und Bandbreite. 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 erlaubt wird über die Firewall Policy wird eine "session" erstellt und bezeichnet (flag) als "may_dirty". Wenn eine Änderung in der Firewall Policy durchgeführt wird so werden "alle" existierenden "sessions" von "may_dirty" auf "diry" gesetzt. Dadurch werden sämtliche Packet ab diesem Zeitpunkt nicht mehr über den NPU gesendet sondern zum CPU. Der CPU kontrolliert abermals das Packet in der Firewall Policy und wenn dieses erlaubt wird, werden diese "sessions" auf "may_dirty" gesetzt. Wenn dieses Packet in der Firewall Policy nicht erlaubt wird werden diese Packet verworfen und mit einem "flag" "block" versehen. Danach verbleibt die "session" im Memory bis diese den TTL resp. "expire" erreicht. So kann die FortiGate über die "flags" "dirty"und/oder "may_dirty" erkenne/evaluieren nach einer Modifikation der Firewall Policy ob diese weiterhin erlaubt werden (may_dirty) resp. die entsprechende "session" geblockt werden (block). | ||||||||||||||||||||||||||
|
policy_id=0 |
Gibt an welche Firewall Policy-ID benutzt wurde. Die Firewall Policy-ID 0 indiziert eine "Local-In Policy". | ||||||||||||||||||||||||||
|
statistic |
Steht für den Packet Counter der auch über die Firewall Policy der FortiGate ersichtlich ist. statistic (bytes/packets/err): org=3408/38/0 reply=3888/31/0 tuples=2 | ||||||||||||||||||||||||||
|
hook=out dir=org |
Gibt an wie die Packete für "out" und "in" verarbeiet werden dh. wenn NAT (Network Address Translation) benutzt wird so werden die Positionen "act=snat" 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 erstellt wird für eine Verbindung im Zusammenhang mit Authentifizierung wird der "user=" sowie die Gruppenzugehörigkeit "group=" sowie das "authed" Flag gesetzt |
Referenz: http://kb.fortinet.com/kb/documentLink.do?externalID=FD30042
Wie kann ich die Session Timer auf der FortiGate manipulieren 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 Session die FortiGate verwalten muss, desto weniger CPU Ressourcen werden für die Behandlung der Sessions gebraucht. Es gibt verschiedene Möglichkeiten die Anzahl an gleichzeitigen Sessions zu reduzieren:
Wenn der Trafficflow gestoppt wird, bleibt die die dazugehörige Session in der FortiGate bis ein bestimmter Timer abläuft. Dieses Verhalten gilt für TCP und UDP Session. (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 folgendermassen konfigurieren:
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 auch kurzen Transaktionen basieren. Zum Beispiel DNS ist so ein Protokoll. In diesem Fall wird empfohlen, den Timer für das Protokoll auf einen geeigneten aber kurzen Wert zu ändern.
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 Inspektionsmoden auf der FortiGate? Proxy vs Flow
Jede Fortigate Firewall hat zwei mögliche Betriebsmodis, 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 den Datenverkehr anhand der Informationen aus den vollständigen Paketen. Die Entscheidung über das weitere Vorgehen mit einem Datenstrom wird somit immer anhand vollständiger Datenpakete vorgenommen. In diesem Betriebsmodi 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 werden.
Im GUI ist diese Konfiguration unter System > Settings > Inspection Mode zu finden.
Im CLI kann dieser Konfigurationspunkte wie folgt geändert 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 gestellte Einstellung gestellt 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 der Version 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. Wenn ich die Proxybasierte Inspektion haben will, muss diese in der jeweiligen Policy konfiguriert werden.
Proxymodus
|
Konfiguration über das WebGui |
Beschreibung |
Konfiguration über die CLI |
|
in die entsprechende Policy gehen und da kann im dann der Inspektions Modus auf Proxy eingestellt werden. Folgend UTM Features sind im Proxy Modus unterstützt:
|
config firewall policy edit [Policy-ID] --> Policy ID eingeben z.B edit 2 set inspection-mode proxy next end |
Flow Modus
|
Konfiguration über das WebGui |
Beschreibung |
Konfiguration über die CLI |
|
Default mässig ist in der Policy der Flow Inspektionsmodus aktiviert. Falls man von Proxy auf Flow zurückstellen will kann man dies aber auch in der entsprechenden Policy vornehmen. Folgend UTM Features sind im Flow Modus unterstützt:
|
config firewall policy edit [Policy-ID] --> Policy ID eingeben z.B edit 2 set inspection-mode flow next end |
Flow Modus - NGFW
Was hingegen immer noch Global eingestellt wird ist der NGFW Modus. Standartmässig ist dieser auf Profile Based eingestellt. Das bedeutet, das UTM Profile erstellt werden und diese an Policies angewendet werden. Der Policy-based Modus bedeutet, dass Applikation und Webfilter direkt in der Policy definiert werden. Erfordert dass ein einzelnes SSL/SSH Inspektionsprofil auf alle Policies angewendet wird. Antivirus ist immer Profil basierend, unabhängig welcher NGFW Modus konfiguriert ist.
|
Konfiguration über das WebGui |
Beschreibung |
Konfiguration über die CLI |
|
Im Menu Settings kann der NGFW Modus definiert werden. |
config system settings set ngfw-mode [profile-based | policy-based] end |
NAT
Wie funktioniert das Destinations Nat auf einer FortiGate?
VIPs sind dnat Objekte. Bei jeder Session, welche mit einem VIP übereinstimmen wird die Destination IP Adresse übersetzt (genatet). Ü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 ein one-to-one Mapping für eingehende und ausgehende Verbindungen gilt. Wenn also eine Policy für ausgehenden Traffic konfiguriert wird und das VIP Objekt dann auf dem ausgehenden Interface ausgewählt wird, wird die IP Adresse genatet. 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. Das heisst, 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, welche Anfragen auf die Adresse 198.18.1.2 auf die IP Adresse 172.16.1.100 nated. Der Request wird also auf der FortiGate weitergeleitet auf den Server in der DMZ 172.16.1.100. Über Policies kann noch geregelt werden, welche Services alles Zugriff auf den Zielserver haben sollen (172.16.1.100). Ich empfehle jeweils nur die benötigten Services im VIP Objekt zu konfigurieren. Der Grund ist, dass gemäss Flow Diagram zuerst das Destinations NAT vollzogen wird und erst dann die Firewall Policies abgehandelt werden. Das heisst, wenn ich alle Services im VIP Objekt konfiguriere, sind diese potentiell auf das Zielsystem bereits durchgeschalten. Wenn man sich bei den Policies verkonfiguriert hat man sozusagen einen bypass konfiguriert.
Flow Diagramm:
Wie richte ich ein Destinations Nat mit einem VIP Objekt ein?
|
Konfiguration über das WebGui |
Beschreibung |
|
Ü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 genatet.
|
|
|
Um eine neue Regel zu erstellen geht man über Policy & Objects -> IPv4 Policy ->
|
|
Konfiguration über die CLI |
Beschreibung |
# 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 VIP Objektes über die CLI |
# 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 des IP Adressen Objekt für 0.0.0.0/0 |
# 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 |
Konfigurieren der Policy über die CLI |
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 nur mit dem 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 geNATed 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 Problemmann kann das untrust Interface im virtuellen IP-Objekt auswählen. Wenn man zwei ISP-Verbindungen hat, z.B. eine gute (ISP1) und eine billige (ISP2), MÜSSEN die Interfaces im virtuellen IP-Objekt ausgewählt weren, wenn man auf eine feste IP-Adresse von ISP1 verweist. Andernfalls wird diese auf allen ausgehenden Verbindungen verwendet, die dann mit dem ISP2 nicht funktioniert.
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 Quell-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 die ausgehende Interface genatet, während ausgehende Verbindungen zu ISP1 weiterhin an die virtuelle IP-Adresse genatet werden (Label 3).
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 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
Wie kann ich beim SSL-VPN einen Bookmarker konfigurieren, das 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 die nur über einen IPSec Tunnel erreichbar ist, über ein Bookmark auf einem SSL-VPN Portal auf einer 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üpunktVPN > SSL-VPN Settings:
|
|
Mit einem Apply werden die gewählten Einstellungen appliziert. |
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 der Firewall dies erlaubt. Für diese Firewallregel benötigen wir einen IP Pool, damit die Source IP des Requests der Firewall dem entsprechend 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:
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 |
Beschreibung |
|
|
|
|
Network:
|
|
Authentication
|
|
Phase 1 Proposal
|
|
|
Phase 2 konfigurieren
|
Schritt 2 - Routen konfigurieren
|
Konfiguration über das WebGui |
Beschreibung |
|
|
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 |
Beschreibung |
|
|
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:
|
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 geleitet 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 Bordmitteln etabliert werden.
Unter FortiOS 6.0 kann ein L2TP over IPSec Client2Side Tunnel nur teilweise im GUI konfiguriert werden. Da gewisse Konfigurationsschritte im CLI vorgenommen werden müssen, basiert die folgende Anleitung komplett 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 Addressobjekt.
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 (im 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 folgt 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 ueber ein Site to Site VPN ein ServerLAN auf der Remote Seite erreicht?
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 die Site 1 auch auf den Server 172.16.16.20 zuzugreifen. 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 weiter geroutet wird. Das unten dokumentierte Szenario basiert auf dem Umstand dass auf Site1 sowie auf Site2 eine Fortigate Firewall im Einsatz ist. Ein Teil der untenstehenden Anleitung kann jedoch auch dann übernommen werden, wenn auf Site2 eine Firewall eines Drittherstellers zum Einsatz kommt, oder wenn sich Site2 in einer Public Cloud wie Azure oder AWS befindet. Die generischen, herstellerneutralen Schritte, um ein solches Szenario zu konfigurieren sind immer die folgenden:
- Firewall Site2: Ändern sie die IPs des SSL-VPN-Pool auf einen IP-Range, damit der IP-Pool der Site2 nicht mit dem Pool von Site1 kollidiert.
- Firewall Site1: Konfigurieren Sie in der SSL VPN Client2Site Konfiguration die Split Networks so, dass das entsprechende Netz von Site2 (172.16.16.0/24) über den SSL VPN Tunnel geroutet wird.
- Firewall Site1 und Site2: Konfigurieren Sie die IPSec Einstellung des entsprechenden Tunnels so, dass sich das SSL-VPN-Client2Site Netz von Site1 (10.10.10.1/24)) auf beiden Seiten entweder in der Local oder in den Remote Networks befindet. Somit werden diese IP über den IPSec Tunnel überhaupt erst zugelassen.
- Firewall Site2: Erstellen Sie eine statische Route damit das SSL VPN C2S Netz von Site1 via IPSec Tunnel an Site1 ü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 Netzwerkschemata:
|
Netzwerkplan: | |
|
Violett : Bestehende Konfiguration. |
Konfiguration über das WebGui: Die Konfiguration basiert auf dem FortiOS 6.0.2:
|
Konfiguration Site 1 | |
|
Als erstes die User anlegen. Diese können als Lokale User eingerichtet werden (In unserem Beispiel machen wir das 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 in eine Usergruppe zuweisen. Diese Usergruppe wird beim SSL-VPN Portal dann benutzt. |
# 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 abzudecken was passiert wen 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 Screen abgebildet. (Tunnel Mode off Enable Web Mode off, Enable FortiClient Download on) |
# config vpn ssl web portal # edit "dummy-portal" # end # end | |
|
Wir konfigurieren jetzt das eigentliche SSL-VPN Portal. Wir benutzen den Tunnel-Mode. Das bedeutet, wir können nur mit dem FortiClient die Verbindung etablieren.
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:
|
|
' Adress Objekt definieren für Splittunnel: # config vpn ipsec phase2-interface # edit "Site1_to_Site2" -> Name des Tunnels # edit "site1-sslvpn-site2" -> Name definieren des Selektors # set phase1name "Site1_to_Site2" # set proposal aes256-sha256 aes128gcm aes256gcm chacha20poly1305 -> Gewünschte Verschlüsslungsalgerithmen 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 | |
|
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 VPN Regeln oberhalb der Regulären Regeln sind. | |
|
| |
|
Konfiguration Site 2 | |
|
Im bestehenden IPSEC Tunnel zur Site 1 muss noch einen zweiten 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 definieren des Selektors # set proposal aes256-sha256 aes128gcm aes256gcm chacha20poly1305 -> Gewünschte Verschlüsslungsalgerithmen 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 Site1 <-> Site2 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 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 abchecken 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 Selectors mit rechtsklick auf Bring Up klicken | |
|
| |
|
Wenn alles grün ist, ist der Tunnel up and running |
|
Damit der Traffic an den Server weiter geleitet 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 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 etabliert. Wir sehen die IP Adresse, welche von der Site1 dem Client zugewiesen wurde (10.10.10.2) |
|
Auf der Site2 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 welchen 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 Durchsatzwerten 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 keinanderer Traffic und keine anderen Tasks verarbeitet wird.
- Der gesamte 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
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 werden, 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
Wie kann ich einen Registrierten User von der FortiGate wieder deregistrieren?
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 CLI |
# diag endpoint registration list |
Um einen bestimmten User von der FortiGate aus zu deregistrieren kann das mit dem folgenden Befehl erreicht werden:
| Konfiguration über CLI |
# diag endpoint registration deregister <FortiClient UID> 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 CLI |
# config system interface # edit <tunnel.interface> # set fortiheartbeat disable # end |
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 diersen 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 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 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 CLI |
fg20-master# config system ha fg20-master (ha) # set authentication enable fg20-master (ha) # set encryption enable fg20-master (ha) # end |
| Konfiguration über 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 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 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 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, gibt 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 CLI |
fw-master # execute ha manage ? fw-master # <id> please input peer box index. fw-master # <0> Susidary unit FGT60Exxxxxxxxxxd |
In diesem Fall ist die ID des passiven Devices 0
nun kann man mit dem selben Befehl auf den passiven Member sich verbinden:
| Konfiguration über 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 Slave angezeigt gefolgt von einem Dollar ($) Zeichen.
Um den Slave wieder zu verlassen kann der Befehl exit benutzt werden:
| Konfiguration über CLI |
fw-slave $ exit fw-master # |
DoS
Wie kann ich die DoS Policy im FortiOS aktivieren?
Standard mässig sind die DoS Policy im FortiOS nicht sichtbar im Webgui. Diese müssen über die Feature Einstellungen zuerst eingeschalten werden.
Um diese Sichtbar zu machen muss Menu System-> Feature Visibility der Schalter DoS Policy aktiviert werden.
Über die CLI kann man dies folgendermassen einschalten:
| Konfiguration über 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-6.0-6.2: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 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 Quell-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 Quell-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 Ziel-IP-Adresse den konfigurierten Schwellenwert überschreitet, wird die Aktion ausgeführt. |
5000 Gleichzeitige Sessions |
|
udp_flood |
Wenn der UDP-Traffic zu einer Ziel-IP-Adresse den konfigurierten Schwellenwert überschreitet, wird die Aktion ausgeführt. |
2000 Pakette pro Sekunde |
|
udp_scan |
Wenn die Anzahl der UDP-Session, die von einer Quell-IP-Adresse stammen, den konfigurierten Schwellenwert überschreitet, wird die Aktion ausgeführt. |
2000 Pakette pro Sekunde |
|
udp_src_session |
Wenn die Anzahl der gleichzeitigen UDP-Verbindungen von einer Quell-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 Ziel-IP-Adresse den konfigurierten Schwellenwert überschreitet, wird die Aktion ausgeführt. |
5000 Gleichzeitige Sessions |
|
icmp_flood |
Wenn die Anzahl der an eine Ziel-IP-Adresse gesendeten ICMP-Pakete den konfigurierten Schwellenwert überschreitet, wird die Aktion ausgeführt. |
250 Pakette pro Sekunde |
|
icmp_sweep |
Wenn die Anzahl der ICMP-Pakete, die von einer Quell-IP-Adresse stammen, den konfigurierten Schwellenwert überschreitet, wird die Aktion ausgeführt. |
100 Pakette pro Sekunde |
|
icmp_src_session |
Wenn die Anzahl der gleichzeitigen ICMP-Verbindungen von einer Quell-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 Ziel-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 Pakette pro Sekunde |
|
sctp_scan |
Wenn die Anzahl der SCTP-Sitzungen, die von einer Quell-IP-Adresse stammen, den konfigurierten Schwellenwert überschreitet, wird die Aktion ausgeführt. |
1000 Pakette pro Sekunde |
|
sctp_src_session |
Wenn die Anzahl der gleichzeitigen SCTP-Verbindungen von einer Quell-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 Ziel-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 auflisten für eine Analyse?
Unter 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 zB mit folgenden Befehl die konfigurierten DoS Policies aufgelistet werden die Konfiguriert wurden:
# 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.
Der nachfolgende Befehl listet alle IPv4 Adressen auf für die ein "match" für eine 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 Packet 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 anhand des folgenden Befehls ein Filter gesetzt werden:
# diagnose ips anomaly filter
clear Clear anomaly filter.
id Anomaly ID.
ip IP and subnet mask.
pps pps
freq frequency
Der Status des Filter kann mit folgenden 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 zB ein anhand eine Policy ID (id) oder zB 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?
Im FortiOS 6.0 kann das Feature auf dem ausgehenden Interface Richtung Internet aktiviert werden. Das Interface muss in der Role WAN oder undefined sein.
| Konfiguration über das WebGui | Konfiguration über die CLI |
|
|
config system interface
edit wan1
set scan-botnet-connections block
next
end
|
Wenn man auf botnet packages klickt kann man die Liste abrufen, aus welcher man entnehmen kann, welche Botnetze und C&C Netze bekannt sind.
Im Gegensatz zum FortiOS 6.0 wird im FortiOS 6.2 der Botnet und C&C Schutz über ein IPS Profil konfiguriert, welches in einer Firewall Regel aktiviert werden muss.
Dafür muss eventuell bei den Features die Intrusion Prevention Option eingeschaltet werden:
| Konfiguration über das WebGui | Konfiguration über die CLI |
|
System -> Feature Visibility und das Feature einschalten.
|
config system settings
set gui-ips enable
end
|
Jetzt kann unter den Security Profilen ein neues IPS Profil angelegt werden.
| Konfiguration über das WebGui | Konfiguration über die CLI |
|
Securtiy Profiles -> Intrusion Prevention ->
|
config ips sensor
edit "Botnet-Sensor"
set scan-botnet-connections block
next
end
|
Das IPS Profil muss jetzt an eine Policy angewendet werden:
| Konfiguration über das WebGui | Konfiguration über die CLI |
|
Policy & Objects -> IPv4 Policy ->
|
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 das Event angeklickt wird, können noch mehr Details entnommen werden:
|
Antivirus
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 Default mässig deaktiviert und müssen über die CLI aktiviert werden. Mit folgendem Befehl können die Industrie Signaturen aktiviert werden:
| Konfiguration über CLI |
config ips global set exclude-signatures none end |
Um die Signaturen wieder zu excluden wird folgender Syntax verwendet:
| Konfiguration über CLI |
config ips global set exclude-signatures industrial end |
Traffic Shaper / TOS / DSCP
SIP / VoIP
NTP
Wie kann ich einen beliebigen Zeitserver auf der FortiGate konfigurieren?
Die 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 | Durchzuführende Schritte | Konfiguration über 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 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 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 | Durchzuführende Schritte | Konfiguration über 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 | Durchzuführende Schritte | Konfiguration über CLI |
|---|---|---|
|
|
Einrichten des Zeitservers beim DHCP Server:
|
# 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 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 an einen 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 validen Default Gatway, 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 SplitTunneling 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 dem 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 eine neue 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 das CLI zusätzlich die Netze konfiguriert werden, welche eben nicht über den VPN Tunnel gehen sollen, sondern welche 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 im 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 die IP hierfür 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 kann dann zum Zug kommen, 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, der unter Windows installiert werden kann.
Konfiguration Fortigate:
Damit die Fortigate Firewall möglichst viel Logs auf den Syslogserver schreiben kann, müssen einige Einstellungen getätigt werden:
| Konfiguration über 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, dem die Logs gesendet werden sollen:
| Konfiguration über CLI |
config log syslogd setting set status enable set server "ip-des-syslog-servers" end |
Die Firewall sendet nun der hier konfigurierten IP die Syslogs via 514 UDP.
Damit allenfalls auch erlaubter Traffic geloggt wird, muss das Logging pro gewünschte Firewallregel eingeschaltet werden:
| Konfiguration über 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 werden, 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.
