Category: Fortinet

In various scenarios, you may want to recover psk plaintext from encrypted format out of a FortiGate or from a FortiGate config backup.

Method 1:

“Print Instructions” menu through a FortiClient profile, ther are 2 alternatives for recovering PSK:

I don’t remember if you need to change existing tunnel or duplicate tunnel or restore a fake config …

https://forum.fortinet.com/tm.aspx?m=137961

Method 2:

1) Log in into the web-interface as a (super?) admin.

2) Change your url/path to https://fortigateip/api/v2/cmdb/vpn.ipsec/phase1-interface?plain-text-password=1

3) Firefox understands the JSON reply. I hope your browser does too. Search for the term “psksecret” on the page. Passwords/secrets should be listed as plain text passwords now.

Method 3:

You can always view the Pre-Shared Key of a WiFi SSID via the GUI. But since FortiGate/FortiOS uses the same algorithm for storing these passwords as for (say) phase1 PSK’s, you can simply:

Create a dummy SSID via the GUI.

Change the password from CLI.

config wireless-controller vap

edit “dummy-decrypt”

set passphrase ENC some-base64-string-from-phase1-PSK

end

Go back to the GUI.

Edit the dummy SSID.

Push the eye logo to reveal the SSID/PSK/whatever password.

I conclude that the encoding method/key must be somewhat fixed in FortiOS (since a FortiVM can decode passwords as well).

By design, password can’t be be salted or they will be no way to restore a config file during RMA process from example.

Note: All three methods do not all work on any FortiOS versions.

Essayons ici de clarifier quelques points sur ces 2 approches

Modes d’inspection

 Proxy

     L'inspection par proxy consiste à tamponner le trafic et à l'examiner en entier avant de déterminer une action. Ce tampon de l'ensemble des données à analyser permet à ce processus d'inclure davantage de données pour l'analyse que les méthodes basées sur les flux (flow) ou l'inspection DNS.
     L'avantage d'une méthode basée sur le proxy est que l'inspection peut être plus approfondie que les autres méthodes, ce qui permet de réduire le nombre de faux positifs ou des résultats négatifs dans l'analyse des données/traffic.

Flow-based

     La méthode d'inspection basée sur les flux examine le dossier lors de son passage dans le FortiGate sans aucune mise en mémoire tampon (ou presque...). À l'arrivée de chaque paquet du trafic, il est traité et transmis sans attendre la transaction complete ou la page web, etc.
     L'avantage de la méthode flow est que l'utilisateur obtient un temps de réponse pour les demandes HTTP (et un buffer) réduit, car les packets "coulent" à la vitesse ou ils arrivent.
     Les inconvénients de cette méthode sont qu'il y a une probabilité plus élevée d'un faux positif ou négatif dans l'analyse des données et qu'un nombre de points de controle ne sont pas disponibles/supportés dans la méthode d'inspection basée sur les flux. Il y a également moins d'actions disponibles au choix en fonction de la catégorisation du site web par les services FortiGuard

Avantages & inconvénients ?

J’ai pour habitude de dire, du plus indolore au plus complexe/précis

Implicit flow < Implicit proxy-based < transparent redirect to web proxy OU explicit proxy

1: Filtrage Implicit Flow

• IPv4 uniquement en profil flow-based
• Pas de blocage uniquement à la deuxiéme tentative

2: Filtrage Implicit Proxy

• IPv4 avec profil proxy-based (interception protocolaire)
• passage en CPU
• gourmand en perf
• qq petites fonctions en +; page de blocage

3a: Transparent Web Proxy

• Invisible du navigateur / client
• 2 policies dépendantes (IPv4 + redirect + web-proxy policy)
• double processing
  +++ gourmand en perf / RAM
• User-agent / RegexHost / URL Category

3b: Explicit Web Proxy

• Nécessite une configuration (qui peut etre WPAD)
• 1 policie dédiée dans web-proxy policy
• pas supporté sur toutes les machines / pas très apprécié par certaines applications (O365)
  ++ gourmand en perf / RAM
• User-agent / RegexHost / URL Category

permet le meilleur niveau de détail/sécurité (presque idem entre 3a et 3b

/!\ en cas de vdoms activés : Les commandes qui suivent sont entrées en mode “config global”  
 
get system ha status                            <– Pour voir les informations détaillées sur l’état du cluster ainsi que la raison de la dernière bascule  
 
Prim-FW (global) # get sys ha status 
HA Health Status: OK 
Model: FortiGate-VM64-KVM 
Mode: HA A-P 
Group: 9 
Debug: 0 
Cluster Uptime: 14 days 5:9:44 
Cluster state change time: 2019-06-13 14:21:15 

Raison des dernières bascules: 
 

<2019/06/13 14:21:15> FGVMXXXXXXXXXX44 is selected as the master because it has the largest value of uptime. 
<2019/06/13 14:15:46> FGVMXXXXXXXXXX46 is selected as the master because it has the largest value of uptime. 
<2019/06/12 11:17:04> FGVMXXXXXXXXXX44 is selected as the master because it has the largest value of override priority. 
ses_pickup: enable, ses_pickup_delay=disable 
override: disable 

Vérifier la synchronisation de la configuration de chaque membre du cluster: 

 
Prim-FW(global)#diag sys ha checksum cluster 
 
================== FGVMXXXXXXXXXX44 ================== 
is_manage_master()=1, is_root_master()=1 
debugzone 
global: c5 33 93 23 26 9f 4d 79 ed 5f 29 fa 7a 8c c9 10 
root: d3 b5 fc 60 f3 f0 f0 d0 ea e4 a1 7f 1d 17 05 fc 
Cust-A: 84 af 8f 23 b5 31 ca 32 c1 0b f2 76 d2 57 d1 bc 
all: 04 ae 37 7e dc 84 aa a4 42 3d db 3c a2 09 b0 60 
 
checksum 
global: c5 33 93 23 26 9f 4d 79 ed 5f 29 fa 7a 8c c9 10 
root: d3 b5 fc 60 f3 f0 f0 d0 ea e4 a1 7f 1d 17 05 fc 
Cust-A: 84 af 8f 23 b5 31 ca 32 c1 0b f2 76 d2 57 d1 bc 
all: 04 ae 37 7e dc 84 aa a4 42 3d db 3c a2 09 b0 60 
 
================== FGVMXXXXXXXXXX46 ================== 
is_manage_master()=0, is_root_master()=0 
debugzone 
global: c5 33 93 23 26 9f 4d 79 ed 5f 29 fa 7a 8c c9 10 
root: d3 b5 fc 60 f3 f0 f0 d0 ea e4 a1 7f 1d 17 05 fc 
Cust-A: 84 af 8f 23 b5 31 ca 32 c1 0b f2 76 d2 57 d1 bc 
all: 04 ae 37 7e dc 84 aa a4 42 3d db 3c a2 09 b0 60 
 
checksum 
global: c5 33 93 23 26 9f 4d 79 ed 5f 29 fa 7a 8c c9 10 
root: d3 b5 fc 60 f3 f0 f0 d0 ea e4 a1 7f 1d 17 05 fc 
Cust-A: 84 af 8f 23 b5 31 ca 32 c1 0b f2 76 d2 57 d1 bc 
all: 04 ae 37 7e dc 84 aa a4 42 3d db 3c a2 09 b0 60 

 
S’il n’y a pas de mismatch, la configuration est synchronisée. Auquel cas, un problème de cluster remonté via la GUI sera un bug d’affichage. 

S’il y a un mismatch, voici comment voir où le mismatch se situe : 

1.vérifier dans quelle grande partie de la conf le mismatch se trouve: 
# diag sys ha checksum cluster 
================== FGT1 ================= 
is_manage_master()=0, is_root_master()=0 
debugzone 
global: : 79 24 76 8a a8 03 9a 81 dc c4 3c f8 96 72 59 11 
root: cf 85 55 fe a7 e5 7c 6f a6 88 e5 a9 ea 26 e6 92 
all: f4 62 b2 ce 81 9a c9 04 8f 67 07 ec a7 44 60 1f 
checksum 
global: : 79 24 76 8a a8 03 9a 81 dc c4 3c f8 96 72 59 11 
root: cf 85 55 fe a7 e5 7c 6f a6 88 e5 a9 ea 26 e6 92 
all: f4 62 b2 ce 81 9a c9 04 8f 67 07 ec a7 44 60 1f 
================== FGT2 ================== 
is_manage_master()=1, is_root_master()=1 
debugzone 
global: 89 f2 f0 0b e8 eb 0d ee f8 55 8b 47 27 7a 27 1e 
root: cf 85 55 fe a7 e5 7c 6f a6 88 e5 a9 ea 26 e6 92 
all: a7 8d cc c7 32 b5 81 a2 55 49 52 21 57 f9 3c 3b 
checksum 
global: 89 f2 f0 0b e8 eb 0d ee f8 55 8b 47 27 7a 27 1e 
root: cf 85 55 fe a7 e5 7c 6f a6 88 e5 a9 ea 26 e6 92 
all: a7 8d cc c7 32 b5 81 a2 55 49 52 21 57 f9 3c 3b 

2. donc comme on le voit il y a une différence sur « global ». Il faut donc aller sur chaque membre du cluster et regarder plus en détail cette partie. 

# diag sys ha checksum show <VDOM_NAME> 

Par exemple: 

# diag sys ha checksum show global 

Donc ici (on peut changer de membre du cluster avec # exec ha manage <ID_membre_cluster> ou # exec ha manage <ID_membre_cluster> <login_admin> : 

FGT_1 #diag sys ha checksum show global  system.global: d6c216d8449d75b2cd80110fa02a85e5  system.accprofile: 7df6f055a28e5d5216c4d2c2b3ee77d1  system.npu: 7df6f055a28e5d5216c4d2c2b3ee77d1  system.vdom-link: 7df6f055a28e5d5216c4d2c2b3ee77d1  wireless-controller.global: 7df6f055a28e5d5216c4d2c2b3ee77d1  wireless-controller.vap: cda65c180c25050eb83398fa23ab7fd1  system.switch-interface: cda65c180c25050eb83398fa23ab7fd1  system.interface: 56f2362fd69f51a2b6fc22a008c0c755  system.password-policy: 56f2362fd69f51a2b6fc22a008c0c755  system.sms-server: 56f2362fd69f51a2b6fc22a008c0c755  system.fsso-polling: af9c2b4f63e40551e33eabd64436fb3e  system.ha: ddfeff2ae037f615fbd83110169b70d2

FGT_2 #diag sys ha checksum show global  system.global: d6c216d8449d75b2cd80110fa02a84e5  system.accprofile: 7df6f055a28e5d5216c4d2c2b3ee77d1  system.npu: 7df6f055a28e5d5216c4d2c2b3ee77d1  system.vdom-link: 7df6f055a28e5d5216c4d2c2b3ee77d1  wireless-controller.global: 7df6f055a28e5d5216c4d2c2b3ee77d1  wireless-controller.vap: cda65c180c25050eb83398fa23ab7fd1  system.switch-interface:cda65c180c25050eb83398fa23ab7fd1  system.interface: 56f2362fd69f51a2b6fc22a008c0c755  system.password-policy: 56f2362fd69f51a2b6fc22a008c0c755  system.sms-server: 56f2362fd69f51a2b6fc22a008c0c755  system.fsso-polling: af9c2b4f63e40551e33eabd64436fb3e  system.ha: ddfeff2ae037f615fbd83110169b70d2

On voit ici que c’est dans « admin settings » 

3.on peut même aller encore plus loin avec : 

# diag sys ha checksum show global <object.name> 

Par exemple: 

FGT1 #diag sys ha checksum show global system.global  [admin-server-cert]=’Fortinet_Factory’: f9d23d8f459c415d1742630c4c0cd99d  [admintimeout]=’480′: 8041fc04d56bd268f40fafc37b5fd078  [alias]=’FGVM010000087496′: a47b05f1b3646431fb078469cfca3225  [fgd-alert-subscription]=’advisory latest-threat’: e15ed9aae8a488d992774994c36566b1  [timezone]=’04’: 5af081b7089c3f69917ea509f3cb5e6d

FGT2 #diag sys ha checksum show global system.global  [admin-server-cert]=’Fortinet_Factory’: f9d23d8f459c415d1742630c4c0cd99d  [admintimeout]=’380′: 8041fc04d56bd268f40fafc37b5fd079  [alias]=’FGVM010000087496′: a47b05f1b3646431fb078469cfca3225  [fgd-alert-subscription]=’advisory latest-threat’: e15ed9aae8a488d992774994c36566b1  [timezone]=’04’: 5af081b7089c3f69917ea509f3cb5e6d

4. Donc l’admin timeout est différent. Un changement de conf sur le membre qui a une mauvaise valeur corrigera le souci.  

A noter que n’importe quel changement déclenchera une nouvelle synchro de configuration. 

A ce stade, on pourra refaire une synchro de configuration avec la commande déjà plus haut : 

# diag sys ha checksum cluster 

================== FGT1 ================= 
is_manage_master()=0, is_root_master()=0 
 
debugzone 
 
global: : 79 24 76 8a a8 03 9a 81 dc c4 3c f8 96 72 59 11 
root: cf 85 55 fe a7 e5 7c 6f a6 88 e5 a9 ea 26 e6 92 
all: f4 62 b2 ce 81 9a c9 04 8f 67 07 ec a7 44 60 1f 
 
checksum 
 
global: : 79 24 76 8a a8 03 9a 81 dc c4 3c f8 96 72 59 11 
root: cf 85 55 fe a7 e5 7c 6f a6 88 e5 a9 ea 26 e6 92 
all: f4 62 b2 ce 81 9a c9 04 8f 67 07 ec a7 44 60 1f 
 
================== FGT2 ================== 
 
is_manage_master()=1, is_root_master()=1 
 
debugzone 
 
global: : 79 24 76 8a a8 03 9a 81 dc c4 3c f8 96 72 59 11 
root: cf 85 55 fe a7 e5 7c 6f a6 88 e5 a9 ea 26 e6 92 
all: f4 62 b2 ce 81 9a c9 04 8f 67 07 ec a7 44 60 1f 
 
checksum 
 
global: : 79 24 76 8a a8 03 9a 81 dc c4 3c f8 96 72 59 11 
root: cf 85 55 fe a7 e5 7c 6f a6 88 e5 a9 ea 26 e6 92 
all: f4 62 b2 ce 81 9a c9 04 8f 67 07 ec a7 44 60 1f 
 

En cas de problèmes de mismatch complémentaire, tenter de recalculer les checksums: 

#diagnose sys ha checksum recalculate [<vdom-name> | global] 

 
En complément, pour diagnostiquer les problèmes de HA complémentaires : 
 

diag debug app hasync 255 
diag debug enable 
execute ha synchronize start 
diagnose debug application hatalk -1 

Lancer les commandes suivantes pour vérifier les mismatches : 

diag debug config-error-log read               <– (1) 
diag hardware device disk                      <– (2) 
show sys storage                               <– (2) 
show wanopt storage                            <– (2) 

1. Pour vérifier les lignes de configuration qui ont mal été comprises par le FortiGate  
2. La taille des disques doit correspondre 

FortiSandbox AI Engine is a database downloaded from FortiGuard and is only applicable to the FortiSandbox VM Scan Tracer Logs.  The Tracer Logs are scanned for specific features (attributes); after the scan the FortiSandbox AI Engine provides a score which is then added or subtracted from the overall file score.The FortiAI uses a ‘baseline’ FortiGuard AI DB and as well as intense local compute-power (GPU on on HW and a minimum of x16 CPU on VMs) to produce a local AI DB.  The FortiAI DBs take into consideration an absolutely enormous amount of features