Table of Contents
Fortinet
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 <PID>
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é (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 : Parallel Path Processing (Life of a Packet) v5.6.6
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 <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
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 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
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 <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
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 <user> <mot de passe>
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 <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
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 sectionmanual
si on veut forcer la sauvegarde manuellerevert
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).
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 : 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 :
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
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é : 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 sessionsmay_dirty
sont également flagguéesdirty
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 sessionsblock
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 "<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.
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 :
- Identity-based policies sur help.fortinet.com
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 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 <nom_du_nouveau_vdom>
.
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 <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.
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 <VDOM_NAME> 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 <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
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 <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
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) : 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 :
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 <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
Docs
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) # <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.
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 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 <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
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 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”.
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 :
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 <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.
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 <filename> execute restore config usb <filename>
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 : <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 :
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 (<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
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 : 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.
:
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