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.

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 <PID>

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é (comme indiqué ici) puis ajouter une tâche at ou cron qui fait :

ssh admin@firewall "config global
> execute reboot
> y"

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 : Parallel Path Processing (Life of a Packet) v5.6.6

# 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

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

# 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 <port>
diagnose hardware deviceinfo nic <port>
 
# 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

# 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.

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

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

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

Certains modèles de Fortigate sont équipés de network processors (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'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
• NP4 session fast path requirements

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

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

# 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 <server_name> <username> <password>

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 <new-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

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 <user> <mot de passe>

Pour lister les lignes de conf on utilise show ; pour afficher l'état du forti on utilise get ou même diagnose.

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

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

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 <new-admin-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

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

# 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).

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 : Routing behavior depending on distance and priority for static routes, and Policy Based Routes chez kb.fortinet.com

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

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 :

• 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

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

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 : Technical Tip : OSPF MTU mismatch after upgrade

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é : Fortigate BGP

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.

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

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

# afficher la politique de sécurité
show firewall policy
 
# stats sur le filtrage de paquets
get sys performance firewall statistics

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 "<ID_RULE>"
      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.

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 :

• Identity-based policies sur help.fortinet.com
• 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)

Ce terme défini la fonction d'un 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

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 <nom_du_nouveau_vdom>.

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 <nom du vlink>
      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.

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 <VDOM_NAME>
end

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 <login>

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

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 <ID> <login>
# 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

# 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 :

• Troubleshooting-a-checksum-mismatch-in-a-FortiGate
• How-to-troubleshoot-HA-synchronization-issue
• Technical Tip: Rebuilding an HA cluster

En webUI, la configuration se réalise dans “Log & Report > Log Config > Log Settings” (en Global).

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 <facility_name>
	set port <port_integer>
	set reliable {disable | enable}
	set server <ip_address>
end
config log syslogd2 setting
<blabla>
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

• Technical Tip: Displaying logs via FortiGate's CLI

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

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

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

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”).

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

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

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

# 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)
# <debug_lvl> varie selon l'appli concernée, mais le max est toujours -1
diagnose debug application <daemon> <debug_lvl>
 
# 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 : RMA Note: HQIP - Hardware Quick Inspection Package.

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

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

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 KB FD39321 recommande de vérifier les ressources du Fortigate :

diagnose hardware sysinfo memory
get system performance status
get system performance top

C'est une implémentation de tcpdump ; la syntaxe basique est : diagnose sniffer packet <interface> '<filter>' [ <verbose> <count> <time-format> ], 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 

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

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”.

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.

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.

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 :

• cyrill-gremaud.ch / Conserve mode investigations
• 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

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.

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 <file.conf>
execute backup full-config usb <file_full.conf>
 
# sauvegarde des logs
execute backup memory alllogs tftp <tftp server> [text|compact]
 
# sauvegarder les signatures IPS
execute backup ipsuserdefsig tftp <filename> <tftp server>
 
# upgrade-downgrade en CLI :
execute restore image tftp <filename> <tftp_ipv4>
# ou au redémarrage lorsqu'apparait ce message en console :
"Press any key to display configuration menu.........."
 
# restorer la conf
execute backup config ftp <FILENAME> <ftp server>

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.

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

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 <filename>
execute restore config usb <filename>

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 : <OID>.<ID_ITF>.<adresse IP>, 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
• OIDs for monitoring IPsec tunnel status

• 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.

execute factoryreset

Il existe également la commande execute factoryreset2 qui permet de garder les routes et les adresses IPs des interfaces.

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 (<TAB>). 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

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

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 : KB FD34502

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

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”

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

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. :

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

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.

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.

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.

• Enhancing FortiGate Security (fortinet.com)