======Fortinet======
{{:informatique:fortinet:fortinet_logo.png |}}
[[http://www.fortinet.com/|Fortinet]] est une marque américaine créée en 2000 qui conçoit des équipements de sécurité réseau. Elle est notamment connue pour ses appliances FortiGate, des firewalls tout-en-un ayant des fonctionnalités de prévention d'intrusion, routage, proxy, filtrage web et mail, VPN.
======Système======
En sortie d'usine, le compte **admin** a un mot de passe vide. La configuration du port CONsole est "9600/8-N-1 hardware flow control disabled" ; on peut se connecter aussi au port mgmt(1) qui a son DHCPd (192.168.99.O/24) activé par défaut, mais attention à ne pas le brancher sur le réseau de prod sous peine de préempter les attributions d'IP du DHCPd légitime !
On peut lister toutes les commandes disponibles avec la commande ''tree'', et filtrer l'affichage en CLI avec '' | grep'' comme sur un terminal Linux.
# afficher les informations du système
get system status
# d'autres informations notamment sur le logging
get mgmt-data status
# récupérer la charge du système et son uptime
(global) get system performance status
# affiche les informations des processus les plus consommateurs en CPU/mem
# équivalent de : get system performance top
diagnose sys top
# on peut préciser X et Y qui sont le délais de refresh et le nombre de ligne affiché, par ex :
diagnose sys top 1 20
# - première ligne : U — % user CPU, S - % system CPU, I — % CPU idle, T — Total memory in kB, F — free memory in kB
# - desc des colonnes : process name, pid, running status, CPU usage, memory usage. (Sleeping, Running, Zombie, < - High priority, N — Low priority)
# on peut classer par CPU usage (Shift+P) ou par mem usage (Shift+M)
# version plus user-friendly (-h pour afficher l'aide)
diagnose sys top-summary
CPU [| ] 4.5%
Mem [||||||||||||||||||||||||| ] 63.0% 2494M/3954M
Processes: 20 (running=1 sleeping=99)
[..]
# et quand un processus plante, prend trop de CPU ou de mémoire, on peut le killer :
diagnose sys kill 11
=====Redémarrage=====
Pour redémarrer ou éteindre le système :
execute reboot
execute shutdown
Il n'est pas possible de planifier un redémarrage automatique ! La seule possibilité est de programmer un reboot quotidien :
config global
config sys global
set daily-restart enable
set restart-time 04:13
end
Attention, il redémarrera donc tous les jours à 4h13 !
Autre possibilité : configurer une authentification SSH par clé ([[informatique:fortinet:start#sauvegarde_en_scp|comme indiqué ici]]) puis ajouter une tâche at ou cron qui fait :
ssh admin@firewall "config global
> execute reboot
> y"
=====Ordre de traitement des paquets=====
Step #1 - Ingress
1. Denial of Service Sensor
2. IP integrity header checking
3. IPsec connection check
4. Destination NAT
5. Routing
Step #2 - Stateful inspection engine
1. Session Helpers
2. Management Traffic
3. SSL VPN
4. User Authentication
5. Traffic Shaping
6. Session Tracking
7. Policy lookup
Step #3 - Security profiles scanning process
1. Flow-based Inspection Engine
2. IPS
3. Application Control
4. Data Leak Prevention
5. Email Filter
6. Web Filter
7. Anti-virus
8. Proxy-based Inspection Engine
9. VoIP Inspection
10. Data Leak Prevention
11. Email Filter
12. Web Filter
13. Anti-virus
14. ICAP
Step #4 - Egress
1. IPsec
2. Source NAT
3. Routing
MAJ d'après la doc officielle Fortinet : [[https://docs.fortinet.com/d/life-of-a-packet-56|Parallel Path Processing (Life of a Packet) v5.6.6]]
{{:informatique:fortinet:life-of-a-packet_fortios-5.6.6.png? |}}
=====Hardware=====
# information sur le matériel
get hardware status
# partitionnement du disque dur (au sens Linux, càd bas niveau)
diagnose hardware deviceinfo disk
# lister les partitions (gestion des images de fortiOS)
diagnose sys flash list
# info sur les CPU (~ /proc/cpuinfo)
diagnose hardware sysinfo cpu
# ~lspci
diagnose hardware pciconfig
# allocation de la mémoire
diagnose hardware sysinfo memory
# afficher l'allocation des slabs (espaces mémoire pré-alloué pour les sessions par ex)
diagnose hardware sysinfo slab
# afficher l'utilisation de la mémoire partagée (SHM)
diagnose hardware sysinfo shm
====Power/alimentation====
Information sur les alimentations :
diagnose hardware deviceinfo psu
PSU 01:
Product Manufacturer : Murata-PS
Product Name : D1U54P-W-450-12-HA4C
Product Version : RJ
Product Serial : X00001
Product Extra : Pri f/w rev: 9151001909-13-01
Product Extra : Sec f/w rev: 9157001909-13-01
PSU 02:
Product Manufacturer : Murata-PS
Product Name : D1U54P-W-450-12-HA4C
Product Version : RJ
Product Serial : X00002
Product Extra : Pri f/w rev: 9151001909-13-01
Product Extra : Sec f/w rev: 9157001909-13-01
!
execute sensor detail
====Interfaces====
# affiche le tableau des compteurs d'interface (bytes, packets, errs, drop, etc...)
diagnose netlink device list
# affichage des infos "bas niveau" d'une interface (port1 ici) :
#(notamment les compteurs d'interface, la MTU, son adresse MAC, etc...)
diagnose netlink interface list port1
# pour clearer les compteurs d'interface ("bas niveau", ça ne met pas à jour les compteur de la première commande d'en haut !) :
diagnose netlink interface clear port1
# informations détaillées sur un port (en mode global)
# équivaut à : get hardware nic
diagnose hardware deviceinfo nic
# modifier la MTU d'une interface
config system interface
edit "port1"
set mtu-override enable
set mtu 9000
next
# modifier la TCP MSS (doit être = MTU - 40 (20 d'entêtes IP et 20 d'entêtes TCP))
config system interface
edit "port1"
set tcp-mss 8960
next
Rappel: la MTU IP est de 1500 octets par défaut. Pour la vérifier entre 2 machines, il faut lancer un PING en interdisant la fragmentation (bit "don't fragment" = 1) et en spécifiant sa taille. Pour une MTU par défaut on peut envoyer des PINGs de taille max 1472 (1500 moins les entêtes IP (20) et ICMP (8)), un seul octet de plus (1473) et on ne pourra plus l'envoyer sans fragmenter, donc cela génèrera une erreur.
# Sous Linux:
ping -M do -s 1473 10.10.10.10
> ping: local error: Message too long, mtu=1500
# Sous Windows:
ping -f -l 1473
> Le paquet doit être fragmenté mais paramétré DF.
# Sous FortiOS :
execute ping-options df-bit yes
execute ping-options data-size 1473
execute ping 10.10.10.10
> sendto failed
//A noter que les erreurs affichées ci-dessus sont locales car détectées directement par ma machine cliente, dans la mesure ou l'on dépasse sa propre MTU. En général ce test est réalisé pour détecter la MTU sur le réseau entre 2 machines distantes quand on suspecte une MTU réduite (< 1500).//
Afficher les caractéristiques des modules GBIC/SFP* connectés et reconnus :
get sys interface transceiver port13
Interface port13 - SFP/SFP+
Vendor Name : Intel Corp
Part No. : FTLX8571D3BCVIT
Serial No. : XYZ
Measurement Unit Value High Alarm High Warning Low Warning Low Alarm
------------ ------------ ------------ ------------ ------------ ------------ ------------
Temperature (Celsius) 42.6 78.0 73.0 -8.0 -13.0
Voltage (Volts) 3.32 3.70 3.60 3.00 2.90
Tx Bias (mA) 8.07 13.20 12.60 3.00 2.00
Tx Power (dBm) -2.0 0.0 -1.0 -7.0 -8.0
Rx Power (dBm) -1.9 0.0 -1.0 -18.0 -20.0
++ : high alarm, + : high warning, - : low warning, -- : low alarm, ? : suspect.
===Port d'admin dédié===
Cette fonctionnalité, qui est pré-configurée pour les firewalls disposant de port nommés ''mgmt*'', permet de dédier une interface au management du Fortigate. Cela a pour effet d'interdire la création de règle de sécurité les incluant, de créer une route "connected" dans la table de routage, et d'ajouter un menu permettant de filtrer les IPs pouvant se connecter dessus (ce qui outrepasse les directives //trusted host// définies dans les comptes utilisateur).
Il est conseillé de ne pas router de trafic utilisateur par ces interfaces.
config system interface
edit "mgmt2"
set dedicated-to management
end
end
===Création d'un agrégat===
En webUI il suffit de créer une nouvelle interface de type "802.3ad Aggregate", qui correspond à un agrégat de type LACP en mode active / slow avec une répartition "L4" (hash de l'adresse IP et du port).
Exemple de configuration en CLI avec les ports physiques 13 et 14 :
config system interface
edit "ag-extra"
set type aggregate
set member "port13" "port14"
next
end
# en CLI on a accès aux paramètres avancés suivants :
set lacp-mode active | passive | static
set lacp-speed slow | fast
set algorithm L2 | L3 | L4
attention les paramètres de l'agrégat doivent concorder avec la configuration de l'équipement d'en face !
===Création d'un switch logique===
Pour créer un bridge (un switch logique) entre plusieurs ports d'un Fortigate :
config system switch-interface
edit mon-switch-soft
set members port1 port2 port3 port4
end
NB :
* ces interfaces doivent être vierges de toute configuration ;
* certaines fonctionnalités seront limitées sur ces interfaces
* des performances moindres sont également à prévoir
====Accélération hardware (NP)====
Certains modèles de Fortigate sont équipés de **n**etwork **p**rocessors (NP) qui prennent en charge matériellement certaines fonctionnalités. Cela permet d'alléger la charge CPU et d'accélérer le temps de traitement (pour le chiffrement de tunnels IPSec par exemple).
Pour lister les ports qui sont accélérés :
diagnose npu np1 list # ou "get hardware .."
diagnose npu np2 list
diagnose npu np4 list
diagnose npu np6 port-list
La liste des ports retournés indique les ports pris en charge par le NPx. Les ports de management n'y sont pas.
Il existe donc plusieurs type de NP : le **NP4** par exemple, qui est intégré sur certains des modèles "c" (600c, 800c) :
* il gère les sessions (fastpath acceleration)
* au début la session est remontée à la CPU pour rechercher un match avec une policy
* puis le NP4 intercepte le trafic et le gère ce qui décharge la CPU
* le NP4 gère aussi l'[[http://docs-legacy.fortinet.com/fos50hlp/50/index.html#page/FortiOS%25205.0%2520Help/NP4.077.10.html|accélération IPsec VPN]] (encryption/decryption)
* le NP4 a une capacité de 10 Gbps ingress et 10 Gbps egress ; passée cette limite les sessions sont envoyées à la CPU
* les **NP4lite** sont comme les NP4 en 2x moins puissants
* [[http://docs-legacy.fortinet.com/fos50hlp/50/index.html#page/FortiOS%25205.0%2520Help/NP4.077.05.html|NP4 session fast path requirements]]
[[informatique:fortinet:fortigate|voir un comparatif succinct des performances des différentes générations de NPx.]]
Pour désactiver l'accélération matérielle sur un flux, il faut créer une règle dans la politique de sécurité et saisir la commande suivante :
config firewall policy
edit X
set auto-asic-offload disable
====Bypass ports====
Certains modèles de Fortigate (les 800C par exemple) possèdent 2 paires de ports ayant une fonction de //accelerated bypass//. Celle-ci permet, lorsque l'unité fonctionne en mode transparent, de laisser passer le trafic entre les 2 ports si l'unité est en manque d'énergie ou pendant un reboot (**fail-open**). Aucun traitement ne sera réalisé par le Fortigate pendant le reboot, mais cela évite de couper les flux.
Dans le cas du 800C il s'agit des ports ''wan1 <-> port1'' et ''wan2 <-> port2'' (chaque paire fonctionne individuellement) ; si la fonction est activé la diode "BYPS LED" (ou fail-open) sera allumée en rouge.
Pour activer cette fonction (elle ne l'est pas par défaut) :
config system bypass
set bypass-watchdog enable
set poweroff-bypass enable
end
=====Utilisateurs=====
# lister les utilisateurs connectés
get system info admin status
# même commande, mais affiche les index
execute disconnect-admin-session ?
# pour déconnecter un utilisateur, par ex la session de l'utilisateur toto :
execute disconnect-admin-session ?
INDEX USERNAME TYPE VDOM PROFILE FROM TIME
0 admin ssh 10.1.1.24 Wed Apr 10 14:09:14 2019
1 toto ssh RO_access 10.1.2.201 Mon Apr 8 14:19:59 2019
execute disconnect-admin-session 1
Interroger (pour test) le serveur LDAP :
diagnose test auth ldap
Pour debugguer le LDAP :
diagnose debug appl authd 99
diagnose debug enable
Changer le mot de passe du compte admin :
config global
config system admin
edit admin
set password
end
Modifier globalement les paramètres de login des utilisateurs (peut se configurer en global via ''config system global'' pour l'administration ou par VDOM via ''config user setting'') :
* Dans "config system global"
admin-lockout-duration Lockout duration (sec) for firewall administration.
admin-lockout-threshold Lockout threshold for firewall administration.
admin-login-max Maximum number admin users logged in at one time (1 - 100).
admin-ssh-grace-time Admin access login grace time (10 - 3600 sec).
admintimeout Idle time-out for firewall administration.
* Dans "config user setting"
auth-type Allowed firewall policy authentication methods (http | https | ftp | telnet)
auth-cert HTTPS server certificate for policy authentication.
auth-timeout Firewall user authentication time-out.
auth-timeout-type Authenticated policy expiration behavior (idle-timeout | hard-timeout | new-session)
# blacklistage d'IP source du client
auth-blackout-time Authentication blackout time (0 - 3600 s).
auth-invalid-max Number of invalid auth tries allowed before blackout.
# désactivation temporaire d'un compte utilisateur
auth-lockout-threshold Maximum number of failed login attempts before lockout (1 - 10).
auth-lockout-duration Lockout period in seconds after too many login failures.
Pour lister les IPs/logins bloqués (en quarantaine) : dans la GUI, "Monitor> Quarantaine Monitor" ; en CLI :
diagnose user quarantine list
Et pour débloquer un blocage :
diagnose user quarantine delete src4 x.x.x.x
====Configurer un serveur Radius====
Pour centraliser les comptes/mots de passe on peut configurer un serveur Radius qui sera interrogé pour authentifier les administrateurs du Forti. Cela se fait en plusieurs étapes :
1) déclarer le serveur Radius sur le VDOM de management (root par défaut) : en GUI c'est dans "User & Authentication > RADIUS servers" ; on précise son nom, son IP et son secret (mot de passe pour s'y connecter, défini dans le clients.conf du serveur Radius) ; en CLI :
config user radius
edit "rad-srv"
set server "10.0.4.88"
set secret blablabla
next
end
2) créer le groupe "Admin fortis" dans "User & Authentification > User Groups", nouveau groupe de type "Firewall", et ajouter le serveur RADIUS dans "Remote Groups" :
config user group
edit "Admin fortis"
set member "rad-srv"
next
end
3) Créer chaque login en mode global : créer le login dans "System > Administrators", et cocher "Match a user in a remote serveur group", "Admin fortis" dans cet exemple.
config system admin
edit "admtoto"
set remote-auth enable
set accprofile "super_admin"
set vdom "root"
set remote-group "Admin fortis"
set password ENC MASCARADE
next
end
NB : on pourra définir un mot de passe de secours pour chaque compte, en cas d'inaccessibilité du serveur RADIUS.
Diagnostique :
diagnose test auth radius pap
======Configuration======
Pour lister les lignes de conf on utilise ''show'' ; pour afficher l'état du forti on utilise ''get'' ou même ''diagnose''.
=====Modificateur d'affichage=====
Par défaut l'affichage se fait page par page, et il faut appuyer sur ''entrée'' pour afficher la ligne suivante, et ''espace'' pour la page suivante. Pour afficher l'intégralité du résultat dans le terminal :
# désactiver les "more"
# équivalent d'un "terminal length 0" chez Cisco
config system console
set output standard
end
# afficher la configuration avec toutes les valeurs (mêmes celles par défaut)
show full-configuration
# afficher toutes les lignes de configuration contenant le motif
show | grep 10.0.1.51
set ip 10.0.1.51 255.255.255.0
# afficher les lignes et leur contexte
show | grep -f 10.0.1.51
config system interface
edit "port3"
set vdom "root"
set ip 10.0.1.51 255.255.255.0 <---
set allowaccess ping https ssh snmp
set vlanforward enable
set type physical
set description "vlan 1"
set alias "LAN clampins"
set snmp-index 3
next
end
=====Utilisation du grep=====
Les différentes options possibles du grep à la sauce fortiOS v5 sont :
Usage: grep [-invfcABC] PATTERN
Options:
-i Ignore case distinctions
-n Print line number with output lines
-v Select non-matching lines
-f Print fortinet config context
-c Only print count of matching lines
-A Print NUM lines of trailing context
-B Print NUM lines of leading context
-C Print NUM lines of output context
On peut utiliser une expression régulière en encadrant le motif d'apostrophes (ou de guillemets) :
# on recherche dans la table ARP les IPs se terminant par .201 ou .202
# NB : il faut protéger le caractère "|"
diagnose ip arp list | grep "\.201 \|\.202 "
index=9 ifname=port3 10.0.2.201 00:01:02:03:04:05 state=00000002 use=0 confirm=0 update=14927 ref=6
index=9 ifname=port3 10.0.8.202 00:01:02:03:04:06 state=00000004 use=22317 confirm=22317 update=8015 ref=1
=====Config de base=====
Le système :
config system global
set hostname mon_forti
set timezone 28
#28 (GMT+1:00) Brussels, Copenhagen, Madrid, Paris
config system admin
edit admin
set password
end
config system ntp
set ntpsync enable
set type custom
set syncinterval 60
config ntpserver
edit 1
set server "pool.ntp.org"
next
end
set source-ip 10.10.10.10
end
end
Le réseau :
# attribution d'un IP sur l'interface mgmt1
config system interface
edit "mgmt1"
set ip 10.104.42.248 255.255.255.128
set allowaccess ping https ssh # protocoles permis pour administrer cette interface
set type physical
end
# route par défaut
config router static
edit 1
set device "mgmt1"
set gateway 10.104.42.254
next
end
=====Sauvegarde=====
Il existe 3 modes de sauvegarde la conf :
* ''automatic'' : (celui par défaut) la configuration est sauvée à chaque fois qu'on saisit mot-clé "end" à la fin d'une section
* ''manual'' si on veut forcer la sauvegarde manuelle
* ''revert'' on peut programmer un rollback (reboot + restauration de la conf) automatique du firewall au bout d'un timeout défini ; c'est utile si la modification risque de nous faire perdre la main et que le firewall est sur un site distant. Exemple de mise en place
config global
config system global
set cfg-save revert # | automatic | manual
set cfg-revert-timeout 300 # on définit le timeout pour le rollback
end
il faut bien penser à désactiver le mode revert après la maintenance sinon il redémarrera à chaque modif (et ne la prendra pas en compte) !
======Routage======
# lister toutes les adresses IP du firewall
diag ip address list
IP=192.168.1.99->192.168.1.99/255.255.255.0 index=4 devname=mgmt1
[..]
# lister les IPs virtuelles : VIPs et NAT-pools
diag firewall iplist list
# Afficher la table de routage :
get router info routing-table details
# ou filtrer sur un adresse IP :
get router info routing-table details 10.102.38.12
Routing entry for 10.102.38.0/23
Known via "bgp", distance 20, metric 0, best
Last update 02w6d19h ago
* 10.161.201.43 (recursive via 10.161.201.52)
# analyse bas niveau de la table de routage
# équivalent à : get router info kernel
# les "scope=0" sont les routes statiques configurées
diagnose ip route list
tab=254 vf=1 scope=0 type=1 proto=11 prio=0 0.0.0.0/0.0.0.0/0->10.105.191.225/32
pref=0.0.0.0 gwy=10.161.201.52 dev=36(HUB-LAN)
tab=254 vf=1 scope=0 type=1 proto=11 prio=0 0.0.0.0/0.0.0.0/0->10.105.191.226/32
pref=0.0.0.0 gwy=10.161.201.52 dev=36(HUB-LAN)
[..]
# afficher la table de correspondance IP <-> adresse MAC <-> interface
get system arp
# la même, en plus détaillée :
diagnose ip arp list
# afficher les règles de policy-based routing ("policy routes" ou PBR)
diagnose firewall proute list
# afficher le cache de routage
diag ip rtcache list
Vider le cache de routage :
config router policy
purge
En webUI on peut voir la table de routage dans le "Routing Monitor" ; depuis la version 6 il faut aller dans "Dashboard> Network", passer le curseur sur le widget "Routing" et cliquer sur "Expand to fullscreen". Pour créer un raccourci direct (à la suite des liens FortView préexistants dans le menu Dashboard), cliquer sur "Save as monitor" (bouton en haut de la fenêtre lorsqu'il est en FullScreen).
{{ :informatique:fortinet:routing_monitor_reduc.png?nolink&600 |}}
=====Static=====
Le routage statique possède une distance administrative par d"faut de 10, donc inférieure aux protocoles de routages dynamiques (ce qui veux dite qu'il est prioritaire !). Lorsqu'on déclare une route statique dans un Fortigate, on peut modifier la distance et/ou la priorité d'une route que l'on déclare.
La différence entre la **distance (administrative)** et la **priorité** d'une route est la suivante :
* le Fortigate n'insère dans sa table de routage que la route dont la distance est la plus petite ; c'est la métrique "prioritaire" ;
* lorsque 2 routes ont 2 distances identiques, alors :
* elles sont toutes 2 ajoutées à la table de routage mais seule celle dont la priorité est la plus petite sera utilisée pour router les paquets (donc en sortie du forti). En revanche l'autre acceptera les paquets entrants, et ne provoquera donc pas d'erreur de **RPF** (Reverse Path Forwarding c'est-à-dire routage asymétrique ; NB : pour désactiver le RPF (non conseillé) il suffit de saisir la commande ''set asymroute enable'' en config system)
* si elles ont la même priorité, alors on est en situation d'**ECMP** (Equal Cost Multi-Path) ce qui veut dire répartition de charge sur les 2 next-hop (un paquet de chaque côté, en Round-Robin)
Indépendamment de cela, il faut noter que :
* les **policy routes** sont prises en compte en premier lieu, quelles que soient les autres paramètres
* les **préfixes** (la longueur des masques réseau des routes) sont ensuite pris en compte, AVANT les métriques
Pour résumer :
>the "priority" parameter is used in situation where a static route needs to be present in order to accept incoming traffic and pass the RPF check (anti-spoofing).
source : [[http://kb.fortinet.com/kb/viewContent.do?externalId=FD32103|Routing behavior depending on distance and priority for static routes, and Policy Based Routes]] chez kb.fortinet.com
=====OSPF=====
Exemple de configuration OSPF (à c/c avec des pincettes) :
config router ospf
config area
edit 0.0.0.0
next
end
config network
edit 1
set prefix 172.16.15.0 255.255.255.252
next
end
config ospf-interface
edit "OSPF_SRV"
set authentication md5
set cost 10
set dead-interval 3
set hello-interval 1
set interface "SRV-iVDOM"
set ip 172.16.15.2
set md5-key 1 "totopwet"
set priority 0
next
end
config redistribute "connected"
end
config redistribute "static"
set status enable
end
config redistribute "rip"
end
config redistribute "bgp"
end
config redistribute "isis"
end
set router-id 10.0.0.15
set passive-interface "ico-untrust"
# annoncer sa route statique par défaut dans l'OSPF, et en tant que external 1
set default-information-originate enable
set default-information-metric-type 1
end
Diag :
# affiche le status de tous les protocoles de routage dynamiques de ce forti :
get router info protocols
get router info ospf status
get router info ospf neighbor
get router info ospf interface
# afficher le LSDB (LSAs type 1 et 2) :
get router info ospf database brief
# afficher les détails de chaque LSA
get router info ospf database router lsa
# affiche les LSAs envoyés par ce Fortigate :
get router info ospf database self-originate
get router ospf
show router ospf
#
# Logging (à partir de la version 5.4+)
#
config router ospf
set log-neighbour-changes enable
#
# Debug
#
#diagnose ip router ospf packet hello enable
diagnose ip router ospf all enable
diagnose ip router ospf level info
diagnose debug cli 0
diagnose debug console timestamp enable
diagnose debug enable
# nettoyage du debug
diagnose ip router ospf all disable
diagnose debug disable
# redémarrer le processus OSPF
execute router clear ospf [process x]
# pour vider l'état du routage
config router policy
purge
end
====Agrégation de routes====
Pour simplifier les tables de routage, on peut agréger les routes sur les ABR (Area Border Router) ou les ASBR (Autonomous System Border Router). Cela consiste, sur ledit routeur, à fusionner plusieurs annonces en une seule, de préfixe plus court (par exemple 10.0.0.0/24 et 10.0.1.0/24 => 10.0.0.0**/23**). En réduisant les annonces on simplifie la table de routage de tous les routeurs, on diminue la charge CPU lors des changements de topologie, et on diminue la charge sur le réseau.
L'agrégation se configure de 2 façons, suivant qu'il s'agisse d'ABR (LSA de type 3) ou d'ASBR (LSA de type 5) :
* sur un ABR, pour agréger des routes apprises de l'aire 1 (c'est un exemple) :
config router ospf
config area
edit 0.0.0.1
config range
edit 0
set prefix 10.0.0.0 255.255.254.0
end
end
end
* sur un ASBR, pour agréger des routes redistribuées (connected, statiques, etc..) dans l'OSPF :
config router ospf
config summary-address
edit 0
set prefix 10.0.0.0 255.255.254.0
end
end
Ces routes sont visibles dans la table de routage de l'ABR/ASBR sous la forme :
get router info routing-table ospf
[..]
O 10.0.0.0/23 [110/0] is a summary, Null, 00:02:21
On voit les réseaux dans la database :
get router info ospf database brief
[..]
Summary Link States (Area 0.0.0.0)
Link ID ADV Router Age Seq# CkSum Flag Route
10.0.0.0 10.0.10.1 154 80000092 2570 0031 10.0.0.0/23
[..]
get router info ospf database summary lsa 10.0.0.0
[..]
Summary Link States (Area 0.0.0.0)
LS age: 309
Options: 0x2 (*|-|-|-|-|-|E|-)
LS Type: summary-LSA
Link State ID: 10.0.0.0 (summary Network Number)
Advertising Router: 10.0.10.1
LS Seq Number: 800002df
Checksum: 0x60e2
Length: 28
Network Mask: /23
TOS: 0 Metric: 11
sources :
* [[http://kb.fortinet.com/kb/documentLink.do?externalID=FD30329|OSPF route summarization for LSAs Type3 (on ABR) and Type5 (on ASBR)]]
* https://community.fortinet.com/t5/FortiGate/Technical-Note-OSPF-route-summarization-for-LSAs-Type3-on-ABR/ta-p/198559
====Redistribution de route====
On peut activer la redistribution de __toutes__ les routes statiques dans l'OSPF en activant ''config redistribute "static"'' ; cependant si on veut n'annoncer que certains préfixes il faut filtrer les annonces. On utilise pour cela :
* une **access-list** (ou **ACL**) qui sélectionne des réseaux
* une **route-map** qui associe une action à une ACL
Exemple de redistribution de 2 (parmi d'autres que l'on ne veut pas annoncer) routes statiques dans l'OSPF :
# définition de l'access-list pour matcher 10.1 et 10.2 /16
# exact-match permet de ne sélectionner que le préfixe exact (pas ses sous-réseaux)
config router access-list
edit "acl_static-to-ospf"
set comments "définition d'une liste de réseaux"
config rule
edit 1
set prefix 10.1.0.0 255.255.0.0
set exact-match disable
next
edit 2
set prefix 10.2.0.0 255.255.0.0
set exact-match disable
next
end
# définition de la route-map
# préciser l'action "permit" est facultatif car c'est celle par défaut
config router route-map
edit "rm_static-to-ospf"
config rule
edit 1
set match-ip-address "acl_static-to-ospf"
set action permit
next
end
# activation de la redistribution des routes statiques dans l'OSPF
# et filtrage des annonces
config router ospf
config redistribute "static"
set status enable
set routemap "rm_static-to-ospf"
end
end
====Tips====
===MTU mismatch===
A partir d'une certaine version de fortiOS (v6 peut-être ?), l’algorithme de calcul des MTUs des tunnels IPSec a changé et ne tombe plus sur les mêmes valeurs que les précédentes versions. De ce fait un upgrade ou l'ajout d'un nouveau fortigate peut aboutir a des erreurs de "MTU mismatch" : ''OSPF: RECV[DD]: From X.X.X.X via itfY: MTU size is too large (1934)'') lors de l'établissement des adjacences OSPF (dont la MTU des interfaces doit être scrupuleusement la même que celle du voisin). Pour contourner ce comportement, on peut il faut désactiver les vérification de MTU pour les interfaces connectées aux voisins de version/MTU différente :
config router ospf
config ospf-interface
edit interf_X
set mtu-ignore enable
end
end
Il est aussi possible de forcer la MTU sur l'interface :
config router ospf
config ospf-interface
edit interf_X
set mtu 2000
end
end
Ref : [[https://community.fortinet.com/t5/FortiGate/Technical-Tip-OSPF-MTU-mismatch-after-upgrade/ta-p/197883|Technical Tip : OSPF MTU mismatch after upgrade]]
=====BGP=====
Exemple de configuration BGP basique :
# NB : les numéros d'AS 64512 et 64513 sont privés
config router bgp
set as 64512
set router-id 10.0.255.2
config neighbor
edit "10.0.200.94"
set remote-as 64513
next
end
# déclaration des réseaux annoncés
config network
edit 1
set prefix 10.0.255.2 255.255.255.255
next
edit 2
set prefix 10.0.200.94 255.255.255.254
next
edit 3
set prefix 10.143.8.0 255.255.255.248
next
end
end
Diagnostique :
# afficher les routes apprises en BGP
show bgp routes all
get router info protocols
get router info bgp neighbor
get router bgp
# afficher la configuration
show router bgp
Debug :
diagnose ip router bgp all
diagnose debug enable
# clearer toutes les connexions BGP
execute router clear bgp all
Article plus détaillé : [[informatique:fortinet:bgp|Fortigate BGP]]
=====PBR=====
**Policy-Based Routing**, **PBR** ou **router policy** : fonctionnalit qui permet de bypasser la table de routage en définissant des règles d'exception (suivant l'adresse source, l'interface source, le protocole ou d'autres critères).
Dans la mesure ou ce sont des verrues réseau, l'utilisation de PBR est à proscrire au maximum.
=====NAT=====
La translation d'adresse (NAT) se configure dans une règle de la politique de sécurité (cocher "Enable NAT"). Plusieurs types de NAT sont possibles :
* **Static NAT** : on faire correspondre à une IP interne une IP externe virtuelle (une VIP). C'est utile pour masquer l'IP réelle d'un serveur accessible sur Internet par exemple. On créer un objet "Virtual IP" (dans le menu "Policy & Objects > Objects > Virtual IPs"), que l'on doit juste renseigner en adresse destination dans une règle de sécurité entrante (internet vers réseau local).
Configuration d'un objet VIP :
external IP = l'IP publique de remplacement (virtuelle)
mapped IP = l'IP réelle du serveur (inconnue des clients sur le réseau externe)
C'est du NAT 1-pour-1 c'est-à-dire que les ports ne sont pas translatés et que même les flux sortant initiés par le serveur seront translatés avec la VIP.
* **Dynamic NAT** : on attribue un pool d'adresses IPs externes ("Policy & Objects > Objects > IP Pool"), la première qui est libre sera utilisée pour translater la ou les IPs internes.
* **overloading** : forme de NAT dynamique qui consiste à translater les ports pour mapper plusieurs IPs internes sur une seule IP virtuelle externe. On peut soit utiliser un "IP Pool" d'une seule IP (on fera alors du **PAT** (Port Adresse Translation), translation de ports clients), soit utiliser l'IP de l'interface de sortie du firewall (**masquerading**, c'est ce qui est utilisé sur les box des FAIs). Cependant cette dernière méthode n'est pas recommandée car elle mélange les flux du firewall et des clients NATtés.
* **overlapping** : lorsque 2 réseaux ayant le même adressage doivent se parler (par exemple dans la cas d'un VPN entre 2 entreprises). Dans ce cas on fait correspondre aux 2 réseaux une nouvelle plage d'adresses qui ne se recoupe plus.
Configuration d'un objet IP Pool :
external IP range = l'IP (ou les IPs) de substitution
=======Sessions======
Le terme de session s'applique à chaque connexion traversant ou s'arrêtant au Fortigate, quel que soit le protocole (TCP évidemment mais aussi UDP, ICMP, etc...). Comme c'est un firewall //stateful// le sens d'ouverture des sessions est important, et les retours sont implicitement permis (à la différence des ACLs en général que l'on doit déclarer dans les 2 sens).
# compter les connexions dans le VDOM
get system session status
# liste concise des sessions (1/ligne) - affiche les DNAT et SNAT
get system session list
Pour afficher plus de détails on utilise ''diagnose sys session'' ; cette commande étant très verbeuse elle s'utilise presque exclusivement en appliquant un filtre pour avoir un résultat lisible.
# pour afficher les sessions HTTP ouvertes depuis la machine 10.0.0.2
diagnose sys session filter proto 6
diagnose sys session filter src 10.0.0.2
diagnose sys session filter dport 80
diagnose sys session list
# en plus verbeux :
diagnose sys session full-stat
diagnose sys session stat
# pour afficher les filtres en place
diagnose sys session filter
# pour supprimer toutes les sessions **matchant le filtre courant**
diagnose sys session clear
# ! inutile de préciser qu'on flush toutes les sessions si on n'utilise pas de filtre !
Les flags :
* ''may_dirty'' indique qu'une session a ouverte car acceptée par la politique de sécurité ; si cette dernière vient à être modifiée, toutes les sessions ''may_dirty'' sont également flagguées ''dirty'' ce qui signifie qu'elles doivent être revalidées par la nouvelle politique. C'est ce que fera le firewall lorsqu'il recevra le prochain paquet de la session :
* si celle-ci est toujours valide, il supprime le flag ''dirty''
* sinon il la flag ''block'', ce qui provoque le drop de tous les prochains paquets. Les sessions ''block'' restent dans la table de sessions jusqu'à leur expiration (leur timeout est diminué).
Pour modifier les timeouts par défaut (3600 secondes = 1 heure par défaut) :
config system session-ttl
set default 1800
end
Modifier le timeout d'un type de session, par exemple des flux HTTP :
config system session-ttl
config port
edit 80
set protocol 6
set start-port 80
set end-port 80
set timeout 1800
next
end
end
Enfin, il est aussi possible de personnaliser le TTL de sessions dans les objets service du firewall (ici ports tcp/80 et 8080) :
config firewall service custom
edit "HTTP_custom"
set tcp-portrange 80 8080
set session-ttl 1800
next
end
=======Firewall======
# afficher la politique de sécurité
show firewall policy
# stats sur le filtrage de paquets
get sys performance firewall statistics
=====Identity-based policy=====
Depuis la version 5.2 on peut créer des règles de sécurité qui, si elles matchent un flux, agissent comme un portail captif et invitent l'utilisateur à s'authentifier en HTTPx.
Pour cela il faut d'abord définir un groupe d'utilisateurs (dans User & Device > User > User Groups), puis l'ajouter en "Source" dans une une règle classique de la politique de sécurité :
config user group
edit "wifi-users"
set member "toto" "tata"
end
config firewall policy
edit ""
set groups "wifi-users"
end
Les pré-requis pour cela :
* il faut qu'au moins un des services suivants soit inclus dans les services permis de la règle : HTTP, HTTPs, TELNET ou FTP.
* Pour que le client génère un flux que le firewall redirige vers son portail d'authentification, celui-ci doit résoudre les noms donc il doit avoir un DNS qui répond
* le portail captif (HTTP) est hébergé par défaut sur le port tcp/1000 du firewall donc, en cas de firewalls chainés, il faut que ce service ne soit pas bloqué
* si une règle plus large existe, même en-dessous de la règle d'identité, celle-ci matchera en priorité donc aucune authentification ne sera réalisée (constatation empirique !..).
Une fois authentifié, un utilisateur peut "utiliser" les règles comprenant son groupe (même sur d'autres interfaces source/dest) sans re-saisir son login/mdp.
====Utiliser un certificat spécifique====
Pour utiliser un certificat spécifique pour la page d'authentification :
* faire que l'IP du portail captif du Fortigate résolve (par exemple 10.0.0.1 <-> wifi.intra.domaine.com)
* créer un certificat matchant ce nom (wifi.intra.domaine.com)
* rediriger l'authentification vers cette URL et préciser le certificat à utiliser (il faudra au préalable l'ajouter dans la liste des certificats disponibles sur le Fortigate, ce qui se fait dans "System / Certificates") :
config firewall policy
edit 36
set auth-redirect-addr "wifi.intra.domaine.com"
set auth-cert cert-wifi.intra
end
Enfin, il faut passer la page d'authentification en HTTPS (par défaut elle est servie HTTP) :
config user setting
set auth-secure-http enable
end
doc utile :
* [[http://help.fortinet.com/fos50hlp/52data/Content/FortiOS/fortigate-firewall-52/Security%20Policies/Identity%20Based%20Policies.htm|Identity-based policies]] sur help.fortinet.com
* [[http://kb.fortinet.com/kb/viewContent.do?externalId=FD30760|Using secure authentication (HTTPS) on a FortiGate and redirecting the authentication page]]
On peut personnaliser la mire d'authentification dans le menu "System / Config / Replacement Messages".
Changer le port par défaut (par défaut c'est le 1000) :
config system global
set auth-https-port 1001
end
Pour lister les utilisateurs authentifiés ainsi que diverses infos y ayant attrait :
diagnose firewall auth list
# (remplacer "list" par filter/clear pour filtrer ou supprimer des sessions)
=====Session-helper=====
Ce terme défini la fonction d'un [[https://en.wikipedia.org/wiki/Application-level_gateway|ALG (Application-Level Gateway)]], un firewall capable d'ouvrir des connexions dynamiquement en interprétant des protocoles de niveau 7 OSI (applications). C'est nécessaire pour certains protocoles comme le H323 par exemple, qui ouvre une connexion tcp/1720 classique, puis initie une connexion data/VoIP sur un port non connu à l'avance, dynamiquement négocié entre le client et le serveur.
On peut lister la configuration du Fortigate uniquement en CLI, en mode global :
config global
config system session-helper
show
# exemple pour le H323
# indique que ce service utilise initialement une connexion
# sur le port 1720 en TCP (proto 6 ; 17 si UDP)
edit 2
set name h323
set protocol 6
set port 1720
next
Seuls certains protocoles sont interprétés par le Fortigate, la liste est consultable en créant une nouvelle entrée :
config system session-helper
edit 0
set name ?
ftp ftp
tftp tftp
ras ras
h323 h323
h245O H245 call-out.
h245I H245 call-in.
tns tns
mms mms
sip sip
pptp pptp
rtsp rtsp
dns-udp dns-udp
dns-tcp dns-tcp
pmap pmap
rsh rsh
dcerpc dcerpc
mgcp mgcp
======VDOM======
Les VDOM sont aux Fortigate ce que les VR sont aux Cisco : des équipements virtuels dotés de tables de routage étanches les unes des autres, permettant de créer virtuellement plusieurs firewalls. Pour activer le support des VDOMs (10 max avec un licence de base), c'est soit dans le dashboard en webUI soit en CLI :
config system global
set vdom-admin enable
end
NB : attention on est déconnecté après l'activation.
Une fois le support des VDOMs activés, celui par défaut sera le root et il faudra préciser à chaque fois sur lequel on se connecte (ici le root) ou si on veut se connecter en global (pour les commandes... globales : management, HA, etc) :
config global
# ou
config vdom
edit root
end
Pour créer un nouveau VDOM il suffit de faire ''edit ''.
====Interconnecter 2 VDOMs====
On peut relier 2 VDOMs via un équipement externe ou via des vdom-links, des interconnexions internes au Fortigate (qui transitent par le "fond de panier logiciel" du châssis). On les créer comme on créer une interface classique, mais pour les supprimer on doit passer par la CLI :
config global
config system vdom-link
delete
end
Les vdom-link **npuX-vlink**, créés automatiquement quand on active la prise en charge des VDOMs, sont offloadés (accélérés matériellement). Le nombre de liens créé est fonction du nombre de Network Processor (NPU) ; par exemple sur les 800c il y en a un (NP4). On ne peut pas les supprimer, même si on ne s'en sert pas.
====Supprimer un VDOM====
Pour supprimer un VDOM, comme pour tout objet dans FortiOS, il faut d'abord supprimer les références à cet objet. Pour lister les références à un VDOM, aller dans Global > System > VDOM et cliquer sur le nombre de référence affiché pour les lister. En CLI on peut les lister ainsi (exemple pour un VDOM nommé "vpn") :
diagnose sys checkused system.vdom.name vpn
entry used by table system.interface:name 'ssl.vpn'
entry used by table system.vdom-property:name 'vpn'
On ne peut supprimer le VDOM que lorsqu'il ne reste plus que les 2 références sus-citées (qui sont générées et supprimées automatiquement avec le VDOM). Une fois cette condition remplie : Global > System > VDOM, clic droit puis Supprimer ; ou en CLI :
config vdom
delete
end
======Cluster HA======
=====Configuration=====
Exemple de configuration (CLI) :
config system ha
set group-name "ha-pri"
set mode a-p
set hbdev "port21" 50 "port22" 50
set session-pickup enable
set ha-mgmt-status enable
set ha-mgmt-interface "mgmt2"
set ha-mgmt-interface-gateway 10.0.7.254
set override disable
set priority 150
set monitor "port23" "port24"
end
Normalement l'IP de management du master devient l'IP virtuelle d'admin du cluster et le backup n'est plus joignable ; pour se connecter dessus il fait se connecter au master d'abord, puis saisir :
# se connecter sur le membre d'id=1 du HA à partir du master avec le login spécifié
execute ha manage 1
On peut forcer la création d'une seconde interface de management pour accéder directement au backup :
config system ha
set ha-mgmt-status enable
set ha-mgmt-interface "mgmt2"
set ha-mgmt-interface-gateway 10.0.7.253
end
La mgmt2 ainsi créée permet de joindre le backup en SSH mais pas en SNMP, c'est une limitation de la bidouille. Pour contourner cette limitation, on peut :
* soit utiliser la communauté suffixée par "-numéro_de_série_du_membre"
* soit (en CLI) activer le "ha-direct" pour chaque host en permit
config global
config system snmp community
edit 1
config hosts
edit 1
set ip 10.0.7.87 255.255.255.255
set ha-direct enable
end
====Diagnostique====
Rappel: pour obtenir un prompt sur le membre passif d'un cluster, il faut se connecter en SSH sur le membre actif, puis :
c g
execute ha manage
# ex: execute ha manage 1 networkadmin
//à réaliser en mode global si les VDOMs sont activés.//
# état du HA (état de la configuration et status)
get system ha
get system ha status
# sensiblement identique à la commande précédente
diagnose sys ha status
Si désynchro, détermination de la zone non synchro (également visible en GUI en plaçant le curseur sur "Not Synchronized" dans Global/System/HA.)
# détermination du VDOM (ou global) non synchro
diagnose sys ha checksum cluster
# pour le VDOM non synchro (ex: global), détermination de la portion de conf non synchro
diagnose sys ha checksum show global
[...]
firewall.internet-service-name: 3ecf1b51cca70d08b66bfe86d8e9accc
rule.fmwp: 00000000000000000000000000000000
à comparer avec la conf du membre désynchro; dans mon cas j'ai 2 portions de conf désynchro.
Plus rapidement, si comme dans l'exemple on sait que c'est sur la partie "config global" qu'il y a un delta, on peut extraire les "conf global" des 2 membres et les comparer manuellement (dans Notepad++ avec le plugin "compare" par exemple). Penser à afficher la conf sur une seule page (sans les ''---more---''):
config system console
set output standard
end
On peut resynchroniser la conf en saisissant manuellement les commandes manquantes sur le bon member ; si cela ne se fait pas tout seul (attendre quelques minutes quand même...), on relance le process de synchro :
# désactiver/activer le HA sur les 2 membres
execute ha synchro stop
execute ha synchro start
diagnose sys ha checksum recalculate
Si toujours KO, remonter le cluster from scratch pour resynchroniser le backup sur le primaire (pas de coupure normalement, mais présence en baie nécessaire) : [[https://community.fortinet.com/t5/FortiGate/Technical-Tip-Rebuilding-an-HA-cluster/ta-p/195429|Rebuilding an HA cluster (KB Fortinet)]]
====Diag avancé / prise de trace====
# sur le primaire
execute ha synchronize stop
diag debug reset
diag debug enable
diag debug console timestamp enable
diag debug application hasync -1
diag debug application hatalk -1
execute ha synchronize start
# sur le backup
diag debug reset
diag debug enable
execute ha synchronize stop
diag debug console timestamp enable
diag debug application hasync -1
diag debug application hatalk -1
execute ha synchronize start
A la fin du process (10m), désactiver le debug :
diag debug disable
diag debug reset
# diag avancé
diagnose sys ha dump 1
diagnose sys ha dump 2
diagnose sys ha dump 3
diagnose sys ha showcsum
diagnose sys ha showcsum 1
diagnose sys ha showcsum 2
diagnose sys ha showcsum 3
# relancer le HA "brutalement"
fnsysctl killall hasync
fnsysctl killall hatalk
Liens :
* [[https://community.fortinet.com/t5/FortiGate/Technical-Tip-Troubleshooting-a-checksum-mismatch-in-a-FortiGate/ta-p/197551|Troubleshooting-a-checksum-mismatch-in-a-FortiGate]]
* [[https://community.fortinet.com/t5/FortiGate/Troubleshooting-Tip-How-to-troubleshoot-HA-synchronization-issue/ta-p/193422?externalID=FD45183|How-to-troubleshoot-HA-synchronization-issue]]
* [[https://community.fortinet.com/t5/FortiGate/Technical-Tip-Rebuilding-an-HA-cluster/ta-p/195429|Technical Tip: Rebuilding an HA cluster]]
======Log / Syslog======
En webUI, la configuration se réalise dans "Log & Report > Log Config > Log Settings" (en Global).
Apparemment depuis les versions FortiOS 5.6, le log sur les disques SSD n'est plus activé/activable pour des raisons d'usure prématurée du SSD. Dans les "Log & Report > Log settings" on n'a donc plus de choix pour l'option "Display Logs From", et il est affiché "Selected log location is currently disabled."
Pour consulter les logs en CLI :
# configuration par défaut en v5.2.3 :
config log setting
set resolve-ip disable
set resolve-port enable
set log-user-in-upper disable
set fwpolicy-implicit-log disable # règle balais implicite de la policy ("deny de fin")
set fwpolicy6-implicit-log disable
set log-invalid-packet disable
set local-in-allow enable
set local-in-deny-unicast enable
set local-in-deny-broadcast enable # à désactiver pour éviter le flood de log de broadcast (netbios, etc)
set local-out enable # trafic initié par le firewall
set daemon-log disable
set neighbor-event disable
set brief-traffic-format disable
set user-anonymize disable
end
# filtrer sur une certaine catégorie
execute log filter category event
# on peut aussi filtrer sur le contenu du message de log :
execute log filter field msg Heartbeat
# défini le nb de ligne affichées
execute log filter view-lines 50
# en fonction de la date
execute log filter field date 2014-05-06 2014-05-07
# voir les filtres
execute log filter dump
category: traffic
device: memory
start-line: 11
view-lines: 10
max-checklines: 0
HA member:
log search mode: on-demand
pre-fetch-pages: 2
Oftp search string:
# afficher les logs :
execute log display
# afficher les buffers de log
get log memory global-setting
# afficher l'utilisation de l'espace disque par les logs
diagnose sys logdisk usage
# limiter le nb de log par seconde pour éviter les surcharges CPU
set security log event-rate 1000
Configurer l'export syslog vers un serveur distant : en webUI on ne peut configurer qu'un seul serveur distant, en CLI on peut en saisir jusqu'à 3
# configurer un serveur syslog distant :
config log syslogd setting
set status enable
set csv {disable | enable}
set facility
set port
set reliable {disable | enable}
set server
end
config log syslogd2 setting
end
# filtrer les logs à envoyer :
config log syslogd filter
set traffic {enable | disable}
set web {enable | disable}
set url-filter {enable | disable}
set severity notification
end
# pour désactiver l'envoi de certains logs vers le (r)syslog :
config log memory filter
set extended-traffic-log disable
end
config log fortianalyzer filter
set extended-traffic-log disable
end
config log disk filter
set extended-traffic-log disable
end
Envoyer un message de log pour tester :
# générer des messages de log pour test :
diagnose log test
Pour debugguer le process de gestion des logs, miglogd :
diagnose debug application miglogd -1
diagnose debug enable
Afficher les logs d'erreur de configuration (lors de l'import d'un fichier par ex.) :
diagnose debug config-error-log read
=====Docs=====
* [[https://community.fortinet.com/t5/FortiGate/Technical-Tip-Displaying-logs-via-FortiGate-s-CLI/ta-p/193027|Technical Tip: Displaying logs via FortiGate's CLI]]
======Mail d'alerte======
Le Fortigate peux envoyer des mails d'alerte par rapport à un niveau (Emergency, Alert, Critical, Error, Warning, etc...) ou une catégorie ; cela se configure dans "Log & Report > Alert E-mail".
Le serveur de mail à utiliser est personnalisable dans "System > Advanced > Email Service".
Pour tester l'envoi de mail, en CLI : ''diagnose log alertmail test''
======Services réseau======
=====DHCP=====
Le DHCP server se définit depuis la version 5 dans une interface en GUI et ainsi en CLI :
config system dhcp server
edit 1
set default-gateway 10.204.12.1
set netmask 255.255.254.0
set interface "paie"
config ip-range
edit 1
set start-ip 10.204.12.2
set end-ip 10.204.13.253
next
end
set timezone-option default
set dns-server1 10.204.0.4
set dns-server2 10.204.0.3
next
# lister les attributions d'adresses
execute dhcp lease-list
# vider les attributions d'adresses
execute dhcp lease-clear <@ IP | all>
# debug
diagnose debug console timestamp enable
diagnose debug app dhcps 7
diagnose debug enable
=====NTP=====
Le NTP client (pour MAJ l'heure du firewall) se configure via le Dashboard global, dans le panneau "System Information" : il faut cliquer sur le lien de la ligne de la date et l'heure. Depuis la version 5.6, un encart "System Time" a été ajouté dans "System / Settings", ce qui est plus logique...
En CLI on peut affiner les réglages NTP, notamment ajouter plus d'un serveur de temps, configurer l'interface source, etc... Exemple de configuration :
config global
config system ntp
set ntpsync enable
set type custom
config ntpserver
edit 1
set server "10.0.1.1"
next
edit 2
set server "10.0.2.2"
next
end
set source-ip 10.0.0.1
end
end
Pour vérifier l'état de la synchronisation de temps, et si les serveurs sont joignables :
diagnose sys ntp status
synchronized: yes, ntpsync: enabled, server-mode: disabled
ipv4 server(10.0.1.1) 10.0.1.1 -- reachable(0xf1) S:1 T:5 selected
server-version=4, stratum=4
reference time is debbeaed.145d3c58 -- UTC Fri Jun 1 15:55:25 2018
clock offset is -0.004431 sec, root delay is 0.001755 sec
root dispersion is 0.074173 sec, peer dispersion is 53 msec
====Activer le serveur NTP du FTG====
Le Fortigate peut faire office à son tour de serveur NTP pour un réseau local ; il faut pour cela l'activer sur chaque interface individuellement ; cela se configure via la configuration NTP cliente du Fortigate : dans le Dashboard > Status, puis System Information > System time, cliquer sur [change] et enfin cocher la case "Enable NTP Server", et ajouter les interfaces sur lesquelles l'activer ("Listen on Interfaces").
======Services sécurité======
=====Antivirus=====
Via la GUI on peut vérifier son état dans : "System > Config > Fortiguard > AntiVirus and IPS Options".
# forcer l'update de la base
execute update-now
L'antivirus est géré par le processus //scanunitd// ; on peut voir sa consommation avec un ''diag sys top''.
Pour aller plus loin :
* (regarder les logs système)
* regarder les logs de sécurité Antivirus (Log & Report > Security Log > AntiVirus)
* lancer un debug en CLI :
# pour afficher les erreurs uniquement
# "-1" est plus verbeux, mais à lancer avec parcimonie pour ne pas saturer le Forti
diagnose debug application scanunit 4
diagnose debug enable
diagnose debug disable
diagnose debug reset
=====IPS=====
diagnose test app ipsmonitor <#>
# avec # =
1: Display IPS engine information
2: Toggle IPS engine enable/disable status
3: Display restart log
4: Clear restart log
5: Toggle bypass status
97: Start all IPS engines
98: Stop all IPS engines
99: Restart all IPS engines and monitor
=====update via webproxy=====
Pour les Fortigate qui n'ont pas un accès direct à Internet, on peut configurer l'usage d'un proxy web :
config system autoupdate tunneling
set status enable
set address "10.0.178.10"
set port 3128
end
# éventuellement, spécifier l'IP source à utiliser pour cela :
config system fortiguard
set source-ip 10.0.178.1
end
src: https://kb.fortinet.com/kb/documentLink.do?externalID=FD36587
Si le Fortiguard ne se met pas à jour, on peut diagnostiquer avec :
# depuis le VDOM d'admin (root par defaut)
execute ping update.fortiguard.net
diagnose test update info
diagnose debug enable
diagnose debug application update 255
execute update-ase
execute update-av
execute update-ips
======Diagnostique et debug======
# afficher les logs de crash
diagnose debug crashlog read
# crashinfo à envoyer au support :)
diagnose debug crashlog get
# ~get tech : diagnostique complet à envoyer au support aussi
diagnose debug report
execute tac report
# debugguer une fonction (~un process)
# varie selon l'appli concernée, mais le max est toujours -1
diagnose debug application
# pour réinitialiser le niveau de debug
diagnose debug reset
# activer le log dans la console
diagnose debug comlog enable
# lire les logs
diagnose debug comlog read
# reset les logs console
diagnose debug comlog clear
diagnose debug comlog info
Sur certains modèles on ne peut pas consulter les logs de debug à postériori ; dans ce cas si on sait reproduire le problème, ouvrir une console sur le Fortigate, logguer la session puis :
diagnose debug kernel level 7
diagnose debug console timestamp enable
diagnose debug enable
En cas d'ultime recourt il existe une image de firmware (HQIP pour Hardware Quick Inspection Package) pour passer des tests hardware poussés : [[https://kb.fortinet.com/kb/microsites/search.do?cmd=displayKC&docType=kc&externalId=FD34745|RMA Note: HQIP - Hardware Quick Inspection Package]].
=====ping et cie=====
Permet de lancer des commandes de diagnostique telles le ping, traceroute, etc...
execute ping 10.10.10.10
execute ping6 | traceroute | tracert6
# pour lancer un PING étendu (bit df, taille, adresse source, etc...)
execute ping-options view-settings
Ces commandes sont lancées depuis le VDOM courant et avec l'IP de management ou celle de l'interface de sortie, selon le routage. On peut influer sur ces paramètres :
# lancer un PING depuis le VDOM EXTRA (si votre login dispose des droits de management sur ce VDOM) :
# sélectionner le VDOM EXTRA
execute enter EXTRA
current vdom=EXTRA:1
# puis lancer le PING
ping 8.8.8.8
# modifier l'IP source du Fortigate pour lancer le PING :
execute ping-options source 10.0.0.1
execute ping 8.8.8.8
=====debug flow====
Pour débugguer un flux :
diagnose debug info
diagnose debug enable
diagnose debug console timestamp en
diagnose debug cli 0
diagnose debug flow show console enable
# bonus: encore plus verbeux
diagnose debug flow show function-name enable
diagnose debug flow show iprope enable
# filtrer sur une adresse (source, dest)
diagnose debug flow filter saddr 10.104.219.3
diagnose debug flow filter daddr 10.212.179.5
# démarrer la prise de trace
# on peut la limiter aux x premiers paquet en ajoutant x à la fin
diagnose debug flow trace start
# à la fin de la prise de trace, pas de ctrl+C sous peine d'être déconnecté !
# pour stopper la prise de trace
diagnose debug flow filter clear
diagnose debug flow trace stop
diagnose debug disable
====Messages d'erreur courants====
''Denied by forward policy check''
* le flux ne matche aucune règle donc droppé par la règle balais (rule ID=0)
* le flux matche une règle DENY spécifique (rule ID=x)
* le flux matche une règle PERMIT MAIS disclaimer est activé (= l'utilisateur doit accepter le disclaimer affiché par le FW pour passer)
''iprope_in_check() check failed, drop''
* le protocole d'accès n'est pas permis sur le port de mgmt (PING, SSH, HTTPS)
* l'IP src ne fait pas partie des "trusted hosts" (dans System > Admin > Administrators)
* quand on {PING, ssh, etc} une itf(2) du FW en arrivant par une autre itf(1) ET qu'il n'existe aucune règle de sécurité depuis itf1 vers itf2 (NB : l'interface "any" ne compte pas !)
ex : PING WAN2 quand on arrive par itf DMZ et qu'il n'y a pas de politique entre DMZ -> WAN2
diagnose firewall iprope flush # permet de rafraichir la table de routage
''reverse path check fail, drop''
* antispoofing = l'IP source est connue sur une autre interface (loopback interne, route statique, autre zone, etc)
Pour désactiver l'antispoofing :
config system settings
set asymroute enable
end
''cmdb add entry failed''
* plus assez de mémoire libre ! => il faut soit killer un/des processus, soit rebooter le forti
''action=ip-conn''
Des flux semblent bloqués par le Fortigate (on ne voit pas sortir les paquets avec un ''diag sniff paquet ...''), et ressortent dans les logs avec l'action ''ip-conn'' (au lieu de accept ou deny). Ces flux sont pourtant permis par la politique de sécurité, mais le Fortigate ne reçoit pas de réponse de la destination, à cause :
* de la présence d'un firewall applicatif bloquant sur la destination
* d'un problème de manque de ressources sur ce dernier ; dans ce cas, la [[http://kb.fortinet.com/kb/documentLink.do?externalID=FD39321|KB FD39321]] recommande de vérifier les ressources du Fortigate :
diagnose hardware sysinfo memory
get system performance status
get system performance top
=====sniffer packet=====
C'est une implémentation de tcpdump ; la syntaxe basique est : ''diagnose sniffer packet '' [ ]'', par exemple pour sniffer TOUT le trafic :
diagnose sniffer packet any '' 4 0 l
# avec time-format =
# "a" affiche le timestamp absolu (UTC)
# "l" affiche le timestamp local
#Verbose levels in detail:
# 1: print header of packets
# 2: print header and data from IP of packets
# 3: print header and data from Ethernet of packets
# 4: print header of packets with interface name
# 5: print header and data from IP of packets with interface name
# 6: print header and data from Ethernet of packets with interface name
Il est important de noter que les paquets accélérés par les Network Processors (NP1, 2 etc...) ne sont pas capturés par cette commande, excepter les ouvertures de sessions. Pour sniffer tous ces paquets, il faut au préalable [[informatique:fortinet:start#acceleration_hardware_np|désactiver l'accélération matérielle]] sur le flux qu'on veut sniffer mais cela aura un impact sur les performances.
Différents exemples de captures intéressantes :
# Match TTL = 1 (on lit le 9eme octet dans IP)
diagnose sniffer packet port2 "ip[8:1] = 0x01"
# Match Source IP address = 192.168.1.2: (on lit les 4 27eme octets d'ethernet)
diagnose sniffer packet internal "(ether[26:4]=0xc0a80102)"
# Match Source MAC = 00:09:0f:89:10:ea
diagnose sniffer packet internal "(ether[6:4]=0x00090f89) and (ether[10:2]=0x10ea)"
# Match Destination MAC = 00:09:0f:89:10:ea
diagnose sniffer packet internal "(ether[0:4]=0x00090f89) and (ether[4:2]=0x10ea)"
# Match ARP packets only
diagnose sniffer packet internal "ether proto 0x0806"
diagnose sniffer packet internal "arp"
# Match IPv6 packets only
diagnose sniffer packet internal "ether proto 0x86dd"
diagnose sniffer packet internal "ip6"
# Match packets with RST flag set:
diagnose sniffer packet internal "tcp[13] & 4 != 0"
# Match packets with SYN flag set:
diagnose sniffer packet internal "tcp[13] & 2 != 0"
# Match packets with SYN-ACK flag set:
diagnose sniffer packet internal "tcp[13] = 18"
# Match packets with SYN and no ACK flags set:
diagnose sniffer packet internal "tcp[13] & 18 == 2"
diagnose debug app hatalk 255
# Afficher les paquets fragmentés seulement (MF=1 ou avec un offset de fragmentation, mais DF=0)
diagnose sniffer packet any '((ip[6:2] > 0) and (not ip[6] = 64))' 4 0 a
# Afficher les paquets ICMP de type 3 code 4
# (fragmentation nécessaire (MF) mais impossible à cause du drapeau (flag) DF)
diagnose sniffer packet any 'icmp[0] = 3 and icmp[1] = 4' 4 0 l
# alternative :
diagnose sniffer packet any 'icmp[0:2] = 0x0304' 4 0 l
=====Packet capture=====
On peut capturer des paquets au format pcap pour pouvoir interpréter la trace avec Wireshark. Pour cela, il suffit de se rendre dans le menu "Network > Packet capture".
{{:informatique:fortinet:packet_capture_5.2.png?nolink |}}
Si le menu n'apparait pas, on peut s'y rendre avec l'URL : https://[management-IP]/ng/page/p/firewall/sniffer/
Si l'on tombe sur une "Error 403: Access denied." avec l'astuce précédente, c'est que la fonction n'est pas disponible. Cela arrive si le Fortigate n'a pas de disque dur interne, ou s'il est configuré en mode "WAN Optimization" au lieu de "Disk logging" (ce mode se configure dans "Global > System > Advanced", puis "Disk settings", et nécessite un reboot du Forti + formatage du disque si on le modifie.
=====iperf=====
Les Fortigates intègrent un client iperf (accessible à partir du mode global), qui permet de réaliser des tests de débit entre 2 interfaces du même forti, ou avec un serveur externe.
conf global
# test avec un serveur iperf externe
diagnose traffictest client-intf wan1
diagnose traffictest port 5201
diagnose traffictest run -c 10.0.1.24
# test entre l'interfaces wan1 et wan2 du même forti
diagnose traffictest client-intf wan1
diagnose traffictest server-intf wan2
diagnose traffictest run
La plupart des options classiques d'iperf sont disponibles, on peut les afficher avec ''diagnose traffictest run -h''
Depuis les versions 7.0 et 7.2, on peut configurer un Fortigate également en mode serveur :
# activer la fonction en mode global
config system global
set speedtest-server enable
end
# sur l'interface d'écoute, activer le protocole "speed-test"
config system interface
edit wan1
append allowaccess speed-test
next
end
Par sécurité il n'est pas recommandé de laisser activé le mode serveur au-delà des tests de qualif/diagnostique.
=====Mécanismes de protection=====
====Conserve mode====
Le **conserve mode** est un mécanisme de protection qui est enclenché lorsque le système n'a plus assez de mémoire partagée disponible. Cela a pour conséquence de désactiver l'AV et les changements de configuration, afin de consommer moins de ressources. Il peut être invoqué également si la mémoire libre passe en dessous d'un seuil critique (red threshhold=88% par défaut). Si le seuil extrême est atteint (extrem threshold=95%) le firewall bloque les nouvelles sessions. Ce mécanisme se désactive lorsque l'on passe en dessous du seuil vert (green threshold=82%).
On peut configurer l'action à faire avec l'antivirus:
config system global
set av-failopen {off | pass | one-shot | idledrop}
* off : les sessions ouvertes continent mais les nouvelles sont bloquées ; si une session ouverte nécessite l'AV-proxy elle sera bloquée car toute nouvelle allocation de ressource est bloquée
* pass : bypass l'AV-proxy (default)
* one-shot : pareil que "pass" mais l'AV-proxy est définitievement désactivé pour les sessions ouvertes PENDANT le conserve mode.
* idledrop : le forti va chercher a libérer de la mémoire en coupant les sessions du host qui en a le plus d'ouvertes, jusqu'à sortir du conserve mode. C'est utile en cas de malware par ex, mais pas si le forti est à genoux par du trafic légitime.
====Session removal====
Le **session removal** est un mode qui s'enclenche lorsque le kernel ne peut plus allouer de mémoire il va couper les sessions les plus anciennes. Ce mode plus critique arrive après le passage en conserve mode. Le nombre de sessions coupées est visible dans le paramètre "memory_tension".
Commandes de debug:
diagnose hardware sysinfo shm
SHM counter: 9237843
SHM allocated: 29618182
SHM total: 1337155584
conservemode: 2 # <- 0=OK ; 1=conserve mode ; 2=kernel session fail mode
shm last entered: n/a
system last entered: Tue Dec 1 11:48:23 2020
SHM FS total: 1368051712
SHM FS free: 1337192448
SHM FS avail: 1337192448
SHM FS alloc: 30859264
get sys perf stat | grep Memory
Memory states: 86% used # <- raison du conserve mode
diag sys top
diag hardware sysinfo memory
Tuning pour optimiser la mémoire :
* [[https://www.cyrill-gremaud.ch/fortigate-conserve-mode-investigations/|cyrill-gremaud.ch / Conserve mode investigations]]
* [[https://help.fortinet.com/fos50hlp/52data/Content/FortiOS/fortigate-troubleshooting-52/Common_questions.htm?Highlight=Conserve%20mode#How3|Help Fortinet : How to check CPU and memory resources]]
config system global
set tcp-halfclose-timer 60 --> default 120 s
set tcp-halfopen-timer 5 --> default 10 s
set tcp-timewait-timer 0 --> default 1 s
set udp-idle-timer 60 --> default 180 s
!
config ips global
set socket-size 4 --> default 32 MB
set engine count 2 --> default 0 = infinite
!
config system dns
set dns-cache-limit 300 --> default 1800 s
!
config system session-ttl
set default 300 --> default 3600 s
======MAJ du firmware======
=====Choisir le bon=====
Ces quelques lignes non contractuelles vous donnerons des pistes pour déterminer la bonne version à installer dans votre environnement.
Il est globalement recommandé, en 2022+, de mettre à jour régulièrement les équipements sensibles comme les firewalls, afin qu'ils intègrent tous les correctifs de sécurité des failles connues. "Tant que ça marche, on n'y touche pas" est un raisonnement désuet aujourd'hui sur ce type de matériel connecté.
A la différence d'autres constructeurs, Fortinet ne publie pas (à ma connaissance) de liste de versions recommandées par modèle. Globalement, toutes les versions de FortiOS sont portées sur tous les modèles (récents).
Plus une version (majeure = les 2 premier chiffres dans le numéro de version, par exemple 7.2) est récente, plus elle dispose de fonctionnalités mais plus elle risque de comporter des bugs. De ce fait il est officieusement recommandé de ne pas installer en production des versions "trop jeunes", c'est à dire parues il y a moins de 6 mois et/ou avant la publication des 3-4 premières versions mineures (appelées "New Feature Releases"), ceci afin d'attendre la correction des plus gros bugs.
Pour accéder aux outils Fortinet, on se log sur le portail [[https://support.fortinet.com]] ;
* "Support > Ressources" ; puis "Product Life cycle" permet de connaitre les dates de fin de vente / développement / support des produits Fortinet, autant le hardware (appliances) que le software (firmwares FortiOS).
* "Support > Firmware Download" donne accès aux release notes et aux images de firmware. Le premier onglet indique les release notes des dernières versions supportées ; sur le second, "Download", on a l'historique de toutes les versions de FortiOS parues ; le 3ème onglet, "Upgrade Path", est un outil qui permet, à partir d'un modèle, de sa version actuelle et de la version cible, de connaitre la liste des versions intermédiaires à installer. C'est à suivre à la lettre pour éviter les mauvaises surprises comme la perte de configuration...
Les versions **NPI** (New Product Integration) possèdent des numéros de build différents de la majorité des autres images ; elles correspondent aux développements d'une version à un nouveau modèle qui vient de sortir. Toutes les versions ne sont pas adaptées aux nouveau modèles, et celles-ci sont moins stables que les builds courants.
Depuis la version 7.2, les versions même mineures sont tagguées en **Feature ou Mature release** ; ces flags sont indiqués dans le nom de l'image, juste après le numéro de version (par ex: FGT_100F-v7.0.7.__**F**__-build0367-FORTINET.out) et sont un indicateur de nouveautés fonctionnelles ou stabilité de la version.
Une fois la bonne version trouvée, jetez un œil aux release notes de celle-ci afin d'être sûrs qu'aucun bug ne touche votre modèle ou une des fonctionnalité que vous utilisez. Elles comportent parfois des contre-indications pour certaines configurations.
=====Mise en œuvre=====
On peut récupérer la version courante en mode global :
get system status | grep Version:
Version: FortiGate-800C v5.2.3,build0670,150318 (GA)
La pluspart du temps c'est plus simple de lancer les mises à jour via la webUI (à partir du dashboard), mais on peut aussi le faire en CLI :
# sauvegarde de la conf
execute backup config usb
execute backup full-config usb
# sauvegarde des logs
execute backup memory alllogs tftp [text|compact]
# sauvegarder les signatures IPS
execute backup ipsuserdefsig tftp
# upgrade-downgrade en CLI :
execute restore image tftp
# ou au redémarrage lorsqu'apparait ce message en console :
"Press any key to display configuration menu.........."
# restorer la conf
execute backup config ftp
NB : il n'est (à priori) pas/plus possible, dans les dernières versions de firmware (5.x et +), d'uploader une image sur le Fortigate sans l'activer : le firewall reboot systématiquement à chaque upload de firmware.
=====Rollback=====
Si une version de firmware ne fonctionne pas comme prévu, on peut faire un rollback c'est-à-dire un retour sur la précédente version :
# lister les partitions (gestion des images de fortiOS)
diagnose sys flash list
FGT800xxxxxxxxxx # diagnose sys flash list
Partition Image TotalSize(KB) Used(KB) Use% Active
1 FGT800-4.00-FW-build694-161108 27541 22537 82% Yes
2 FGT800-4.00-FW-build689-140731 27541 22537 82% No
Image build at Aug 1 2014 02:49:11 for b0689
# ensuite on peut configurer l'image (1 ou 2, primary ou secondary) à charger par défaut au prochain reboot :
execute set-next-reboot secondary
Default image is changed to image# 2.
# rebooter
execute reboot
This operation will reboot the system !
Do you want to continue? (y/n)y
=====USB auto-install=====
Une fonctionnalité intéressante des Fortigate est d'utiliser une clé USB pour faire booter le firewall dessus. Si ce dernier trouve :
* un fichier **fgt_system.conf**, il chargera ce fichier de configuration au boot
* une image **image.out** il chargera ce firmware au boot
Ces noms de fichiers sont configurables en webUI dans "System > Config > Advanced" ou en CLI :
config global
config system auto-install
set auto-install-config enable
set auto-install-image enable
set default-config-file "fgt_system.conf"
set default-image-file "image.out"
end
end
La clé doit être formatée en FAT pour être lisible par le Fortigate ; pour le vérifier :
diagnose hardware deviceinfo disk
[..]
Disk USB-7(user-usb) ref: 32 28.8GiB type: USB [Kingston DataTraveler 3.0] dev: /dev/sdc
partition ref: 33 28.8GiB, 28.8GiB free mounted: Y label: dev: /dev/sdc1 start: 0
execute usb-disk list
2019-07-23 16:07:14 43664535 image.out
Et, si la conf/l'image n'est pas chargée au démarrage, il est toujours possible de la charger en CLI :
execute restore image usb
execute restore config usb
======Métrologie/supervision======
Pour lister les capteurs du châssis :
config global
execute sensor { list | detail }
En vrac, les OIDs intéressants :
// OIDs fortigate (en v3)
# OID desc
# system
.1.3.6.1.4.1.12356.1.2.0 SN
.1.3.6.1.4.1.12356.1.100.6.1.2.1 SN
.1.3.6.1.4.1.12356.1.3.0 version fortiOS
.1.3.6.1.4.1.12356.1.8.0 gauge CPU (%)
.1.3.6.1.4.1.12356.1.9.0 gauge mémoire (%)
# network
.1.3.6.1.4.1.12356.1.10.0 nb de sessions
.1.3.6.1.4.1.12356.101.12.1.1.0 nb de tunnel vpn IPSec up
// OIDs v4-v5
# system .1.3.6.1.2.1.1.1.0
.1.3.6.1.4.1.12356.100.1.1.1.0 SN
.1.3.6.1.2.1.1.5.0 hostname
.1.3.6.1.4.1.12356.101.4.1.1.0 version de fortiOS (firmware)
.1.3.6.1.4.1.12356.101.4.1.3.0 CPU (%)
.1.3.6.1.4.1.12356.101.4.4.2.1.2.2 % CPU (Core #) 1 min
.1.3.6.1.4.1.12356.101.4.4.2.1.2.3 % CPU (Core #) 5 min
.1.3.6.1.4.1.12356.101.4.1.4.0 memoire (%) ?
.1.3.6.1.2.1.1.1 Description SNMP
.1.3.6.1.2.1.1.3 uptime
.1.3.6.1.2.1.1.4 Contact SNMP
.1.3.6.1.2.1.1.5 hostname + local domain name
.1.3.6.1.2.1.1.6 Location SNMP
# sensors
.1.3.6.1.4.1.12356.101.4.3.1.0 Hardware Sensor count
.1.3.6.1.4.1.12356.101.4.3.2.1.1 Hardware Sensor index
.1.3.6.1.4.1.12356.101.4.3.2.1.2 Hardware Sensor Name
.1.3.6.1.4.1.12356.101.4.3.2.1.3 Hardware Sensor Value
.1.3.6.1.4.1.12356.101.4.3.2.1.4 Hardware Sensor Alarm
# network (IF-MIB)
.1.3.6.1.4.1.12356.101.4.1.8.0 nb de sessions
.1.3.6.1.4.1.12356.101.4.1.11 fgSysSesRate1
.1.3.6.1.4.1.12356.101.4.1.12 fgSysSesRate10
.1.3.6.1.4.1.12356.101.4.1.13 fgSysSesRate30
.1.3.6.1.4.1.12356.101.4.1.14 fgSysSesRate60
.1.3.6.1.2.1.2.2.1.2 liste des interfaces
.1.3.6.1.2.1.2.2.1.10 IF-MIB::ifInOctets (Counter32)
.1.3.6.1.2.1.2.2.1.16 IF-MIB::ifOutOctets
.1.3.6.1.2.1.31.1.1.1.6 IF-MIB::ifHCInOctets (Counter64)
.1.3.6.1.2.1.31.1.1.1.10 IF-MIB::ifHCOutOctets (Counter64)
# table ARP/correspondance adresse IP -> MAC
.1.3.6.1.2.1.4.22.1.2 IP-MIB::ipNetToMediaPhysAddress
#(utilisation : .., par ex :
#IP-MIB::ipNetToMediaPhysAddress.3.10.0.0.1 pour obtenir la MAC de l'IP 10.0.0.1 sur le port3 du Fortigate)
# policy
.1.3.6.1.4.1.12356.101.5.1.2.1.1.1.1 fgFwPolID (index des # des règles)
.1.3.6.1.4.1.12356.101.5.1.2.1.1.2.1.1 fgFwPolPktCount
.1.3.6.1.4.1.12356.101.5.1.2.1.1.1.1 fgFwPolByteCount
# securite / UTM
.1.3.6.1.4.1.12356.101.8.2.1.1.1 fgAvVirusDetected
.1.3.6.1.4.1.12356.101.8.2.1.1.3 fgAvHTTPVirusDetected
.1.3.6.1.4.1.12356.101.8.2.1.1.5 fgAvSMTPVirusDetected
.1.3.6.1.4.1.12356.101.8.2.1.1.7 fgAvPOP3VirusDetected
.1.3.6.1.4.1.12356.101.8.2.1.1.9 fgAvIMAPVirusDetected
.1.3.6.1.4.1.12356.101.8.2.1.1.11 fgAvFTPVirusDetected
.1.3.6.1.4.1.12356.101.8.2.1.1.13 fgAvIMVirusDetected
.1.3.6.1.4.1.12356.101.8.2.1.1.15 fgAvNNTPVirusDetected
# IPS
.1.3.6.1.4.1.12356.101.9.2.1.1.2.1
# HA
.1.3.6.1.4.1.12356.101.13.2.1.1.1 fnHaStatsIndex
.1.3.6.1.4.1.12356.101.13.2.1.1.2 fnHaStatsSerial
.1.3.6.1.4.1.12356.101.13.2.1.1.3 fnHaStatsCpuUsage
.1.3.6.1.4.1.12356.101.13.2.1.1.4 ifnHaStatsMemUsage
.1.3.6.1.4.1.12356.101.13.2.1.1.5 fnHaStatsNetUsage
.1.3.6.1.4.1.12356.101.13.2.1.1.6 fnHaStatsSesCount
.1.3.6.1.4.1.12356.101.13.2.1.1.7 fnHaStatsPktCount
.1.3.6.1.4.1.12356.101.13.2.1.1.8 fnHaStatsByteCount
.1.3.6.1.4.1.12356.101.13.2.1.1.9 fnHaStatsIdsCount
.1.3.6.1.4.1.12356.101.13.2.1.1.10 fnHaStatsAvCount
.1.3.6.1.4.1.12356.101.13.2.1.1.11 fnHaStatsHostname
# IPSec tunnels names, counters and status
.1.3.6.1.4.1.12356.101.12.2.2.1.2 fgVpnTunEntPhase1Name
.1.3.6.1.4.1.12356.101.12.2.2.1.3 fgVpnTunEntPhase2Name
.1.3.6.1.4.1.12356.101.12.2.2.1.18 fgVpnTunEntInOctets
.1.3.6.1.4.1.12356.101.12.2.2.1.19 fgVpnTunEntOutOctets
.1.3.6.1.4.1.12356.101.12.2.2.1.20 fgVpnTunEntStatus (1=down ; 2=up)
Références :
* http://www.opennms.org/wiki/Fortinet_Guide#Datacollection
* http://www.circitor.fr/Mibs/Html/FORTINET-FORTIGATE-MIB.php
* [[https://community.fortinet.com/t5/FortiGate/Technical-Tip-OIDs-for-monitoring-IPsec-tunnel-status/ta-p/199930|OIDs for monitoring IPsec tunnel status]]
======Divers tips======
=====Password recovery=====
* démarrer le firewall en étant connecté au port console
* dans les 30s qui suivent l'affichage du prompt de login, se logguer en :
login: maintainer
Password: bcpbFG800CXXXXXX ("bcpb" suivi du n° de série du firewall)
Attention ce mode ne permet pas de créer des utilisateurs, juste d'en modifier des existants.
=====Reset factory=====
execute factoryreset
Il existe également la commande ''execute factoryreset2'' qui permet de garder les routes et les adresses IPs des interfaces.
=====fnsysctl=====
**fnsysctl** est une commande qui permet de lancer certaines commandes du système Linux sous-jacent. Comme elle est cachée, elle n'est ni auto-complétée dans le prompt, ni documentée (). Cette commande n'est plus disponible à partir de la version FortiOS 5.4.
FGT (global) # fnsysctl cat /proc/version
Linux version 2.4.37 (root@build192) #3 Tue Mar 17 19:52:27 PDT 2015
FGT (global) # fnsysctl ifconfig amc-dw1/1
amc-dw1/1 Link encap:Ethernet HWaddr 00:09:0F:91:00:D4
inet addr:10.1.1.52 Bcast:10.1.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING ALLMULTI MULTICAST MTU:1500 Metric:1
RX packets:3099621200 errors:0 dropped:0 overruns:0 frame:4
TX packets:3359661545 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:1702617951232 (1585.7 GB) TX bytes:2084883916597 (1941.7 GB)
Interrupt:19 Base address:0x6000 Memory:e7800000-0
FGT (global) # fnsysctl cat /proc/net/dev
Inter-| Receive | Transmit
face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed
ort13: 428296577505964 392502799967 0 4301196 0 0 0 0 141523980618022 265213255572 0 0 0 0 0 0
=====Sauvegarde en SCP=====
Pour sauvegarder les configuration sur un serveur centralisé et en SCP (src : http://kb.fortinet.com/kb/documentLink.do?externalID=12002 )
* vérifier que le SSH est bien activé et permis sur l'interface d'admin
* copier la clé SSH publique du serveur sur les Fortigate :
config system admin
edit admin
set ssh-public-key1 "ssh-rsa AAAAB3NzaC1[blabla...]onL7eow== adminsys@zeus"
end
Maintenant on peut se connecter en SSH depuis le serveur sans saisir de mot de passe :)
* activer le SCP sur les Fortigate :
config system global
set admin-scp enable
end
Maintenant on peut sauvegarder toute la smala avec un script de ce genre :
for FW in "forti1 forti2 etc"
do
scp adminsys@$FW:sys_config /save/forti/$FW.conf
done
=====config global user=====
Avec l'interface web, lorsqu'on veut créer un utilisateur on ne peut que lui accorder des droits RO ou RW sur un (ou des) VDOM(s) particulier(s), mais **on ne peut pas configurer l'accès à la partie configuration globale**. La seule manière de donner l'accès à un utilisateur à ce menu, c'est de l'ajouter dans le profil **super_user** et donc de lui donner tous les droits, ce qui n'est pas toujours souhaitable.
Pour créer un utilisateur qui ait les droits de lecture du menu global, il faut passer par la ligne de commande suivante :
* pour aller plus vite :
* créer en webUI le profil prof_RO avec tous les droits en RO
* créer un utilisateur utilisant ce profil
* puis, en CLI :
config global
config system accprofile
edit prof_diag
set scope global
end
En passant en CLI, on a accès à l'option "scope" qui permet d'activer la vue sur la partie ''config global'' du Fortigate (et en lecture seule).
source : [[http://kb.fortinet.com/kb/documentLink.do?externalID=FD34502|KB FD34502]]
=====Route statique inactive=====
Lorsqu'on ajoute une route statique via la webUI, elle peut être inactive et ne pas apparaitre dans le "Routing monitor". Si c'est le cas, vérifier en CLI :
Router # get router info routing-table details 192.168.18.0
Routing entry for 192.168.18.0/24
Known via "static", distance 10, metric 0
10.0.140.2, via port5 inactive
Cela arrive le plus souvent lorsque le next-hop déclaré n'est pas atteignable via ce port. En gros vous avez fait une faute de frappe dans la déclaration de la route statique OU vous avez un routage incohérent. Dans l'exemple ci-dessus, le next-hop 10.0.140.2 n'est pas joignable via le port5 mais via le port3 :
Router # get router info routing-table details 10.0.140.2
Routing entry for 10.0.140.0/24
Known via "connected", distance 0, metric 0, best
* is directly connected, port3
=====Policy names=====
Depuis la version 5.4 on doit attribuer un nom aux règles de sécurités. C'est obligatoire, on ne peut pas créer de policy sans la nommer. Coercitif, ce comportement peut être rendu optionnel par la directive suivante (à saisir sur chaque VDOM indépendamment) :
config system settings
set gui-allow-unamed-policy enable
Cela peut également se configurer en webUI dans System > Features Visibility, puis cocher "Allow unnamed policies"
=====Configuration d'une CRL=====
Pour utiliser une liste de révocation (récupération en HTTP) et la mettre à jour périodiquement (toutes les 3600s = 1h) :
config global
config certificate crl
edit "G_CRL_1"
set http-url "http://10.0.0.2/path_to_the_crl_file/crl.pem"
set source-ip 10.0.0.1
set update-interval 3600
next
end
end
''source-ip'' permet naturellement de spécifier l'adresse à partir de laquelle le Fortigate enverra sa requête HTTP.
Pour forcer la MAJ de la CRL "G_CRL_1" manuellement, lancer en mode global la commande :
execute vpn certificate crl import auto G_CRL_1
=====Where used ?=====
Pour pouvoir supprimer un objet (adresse, interface, VDOM, etc...) il faut que toutes ses références, dans d'autres objets, soient supprimées.
Par exemple pour supprimer une interface, il faut au préalable supprimer les routes statiques, les tunnels, les objets addresse, etc... qui en font mention. Cela peut se faire en webUI, dans le menu "Network > Interfaces" en affichant la colonne ''Ref.'' :
{{ :informatique:fortinet:forti_refs_col.png?600 |}}
On peut aussi lister les objets utilisés directement en CLI, avec la (nouvelle) commande :
fgt600e (global) # diagnose sys cmdb refcnt show system.interface:name ico_extranet
entry used by table system.interface:name 'VISIO'
entry used by table system.interface:name 'WIFI'
Si tout semble propre mais que l'objet ne peut pas être supprimé (la webUI affiche ''Entry is used''), essayer de le supprimer en CLI : le message d'erreur sera plus verbeux. Par exemple, une interface sans référence ne pouvait pas être supprimée ; en CLI il est affiché :
fgt600e (interface) # delete LAN-centre
Error: IP address 10.41.1.1 is configured as source-ip for communications to NTP server
command_cli_delete:5774 delete table entry LAN-centre unset oper error ret=-23
Command fail. Return code -23
=====VPN protocols relaying=====
Pour mettre en place un concentrateur VPN on créer une interface virtuelle "dialup", en attente de connexion IKE/IPSec entrante. Une fois le VPN établit, pour laisser passer les requêtes broadcastées à travers le routage de l'interface, il faut les transférer en unicast vers les serveurs spécifiés avec les commandes suivantes :
config system interface
edit dialup
# pour le DHCP (dans ce cas, DHCP over IPSec)
set dhcp-relay-service enable
set dhcp-relay-ip "10.1.1.24"
set dhcp-relay-type ipsec
# pour le NetBIOS
set netbios-forward enable
set wins-ip 10.1.16.253
next
Pour rappel le DHCP permet la découverte et l'attribution des paramètres réseau pour le client VPN (son IP, masque réseau, passerelle, DNS, NTP et serveurs WINs) et le NetBIOS permet de faire passer les flux vers les serveurs WINS. Cela permet par exemple un ersatzt de DNS dynamique car les clients Windows s'annoncent auprès des WINS quand ils se connectent en VPN, ou, dans certains cas, de débloquer le changement de mot de passe sur un domaine.
=====Auto filesystem check=====
Après une coupure électrique les Fortigate affichent un message d'alerte invitant l'utilisateur à rebooter et réaliser un filesystem check pour contrôler l'intégrité du système de fichier. Depuis les version 6 il est possible de réaliser automatiquement ce check au démarrage , via le menu : System> Settings> Start Up, "Auto file system check" ; ou en CLI:
config system global
set autorun-log-fsck enable
end
C'est toutefois non-recommander car 1) ça prend du temps donc il vaut mieux le planifier en heure non ouvrée et 2) en cas d'incident électrique le courant peut ne pas être stable et donc recouper le Forti pendant son check -> dangereux.
=====SSH sortant impossible=====
Contexte : Utiliser le client SSH de la CLI du Forti pour se connecter sur un autre équipement, dont les paramètres SSH ne sont pas compatibles car jugés pas assez sécurisés. Depuis le forti :
forti (root) # execute ssh admin@10.0.0.1
Unable to negotiate with 10.0.0.1: no matching key exchange method found. Their offer: diffie-hellman-group14-sha1,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512
Cela signifie que l’équipement cible propose des paramètres SSH non acceptés par le Forti, et que donc la connexion SSH ne peut s'établir. Il faut donc agir sur l'un ou l'autre des équipement, dans cet exemple on va assouplir le Forti en lui permettant d'accepter l'algo **diffie-hellman-group14-sha1** réclamé par l’équipement distant.
Pour modifier les paramètres SSH acceptés par le forti, qui ont été durcis avec certaines versions :
config global
config system global
set strong-crypto disable
append ssh-kex-algo diffie-hellman-group14-sha1
end
end
Cela permet d'assouplir les paramètres négociés à l'établissement de la connexion SSH, ce n'est pas recommandé sans bonne raison.
NB : tuner ces paramètres impacte les protocoles chiffrés : HTTPS/SSH/TLS/SSL
======Liens utiles======
* [[http://docs-legacy.fortinet.com/cb/html/index.html#page/FOS_Cookbook/Install_advanced/cb_enhance_security.html|Enhancing FortiGate Security (fortinet.com)]]