Comment corriger les chiffrements et les clés faibles sur l’interface de gestion pour SSH l’accès

Les clients exécutent des analyses de vulnérabilité s’exécutent sur l’interface de gestion de la firewall . Parfois, ces rapports reviennent comme échoués.
L’échec signalé est principalement dû à la faiblesse des chiffrements utilisés sur le firewall .
Le cas le plus courant est la faiblesse des chiffrements ssh sur l’interface de gestion. Parfois appelé Sweet 32 ou CVE-2016 -2183 dans le scan Qualys (photo ci-dessous).
Les chiffrements cryptographiques affectés sont des chiffrements de blocs d’une taille de bloc de 64 bits (3DES, Blowfish). Ceux-ci sont considérés comme faibles et dangereux à utiliser dans un environnement sûr.

L’article fournit des informations sur la façon de désactiver ces chiffrements faibles et d’utiliser les chiffrements qui ne sont pas vulnérables.





 

• N’importe quel Palo Alto Firewall .
• Tout Panorama .
• PAN-OS 8,0 et plus.

> configure
# delete deviceconfig system ssh
# set deviceconfig system ssh ciphers mgmt aes256-ctr
# set deviceconfig system ssh ciphers mgmt aes256-gcm
# set deviceconfig system ssh default-hostkey mgmt key-type ECDSA 256
# set deviceconfig system ssh regenerate-hostkeys mgmt key-type ECDSA key-length 256
# set deviceconfig system ssh session-rekey mgmt interval 3600
# set deviceconfig system ssh mac mgmt hmac-sha2-256
# set deviceconfig system ssh mac mgmt hmac-sha2-512

# commit

# exit
> set ssh service-restart mgmt

Paramètre d’échange de clés de chiffrement :
Si le scanner affiche des valeurs d’échange clés ssh dépréciées pour l’algorithme d’échange de clés comme indiqué ci-dessous, exécutez les commandes énumérées ci-dessous. Notez que ces commandes ne peuvent être exécutées que sur PAN-OS 9.0 et au-dessus.

> configure
# delete deviceconfig system ssh kex mgmt
# set deviceconfig system ssh kex mgmt ecdh-sha2-nistp521
# commit

# exit
> set ssh service-restart mgmt

Cela devrait compléter tous les changements nécessaires pour durcir le plan de gestion pour les connexions ssh.

Test :

A la rediffusion de l’analyse montrera que ces vulnérabilités ont été atténuées. 
Une autre façon de tester est NMAP d’utiliser (Zenmap sur Windows) et exécuter le script; nmap --script ssh2-enum-algos -sV -p 22 <your_firewall_ip></your_firewall_ip>

Exemple:

user1@Linux:~$ nmap --script ssh2-enum-algos -sV -p 22 x.y.z.q  //Replace x.y.z.q with firewall management IP

Starting Nmap 7.70 ( https://nmap.org ) at 2020-03-18 15:35 PDT
Nmap scan report for 10.46.161.116
Host is up (0.0059s latency).
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 12.1 (protocol 2.0)
| ssh2-enum-algos:
|   kex_algorithms: (7)
|       ecdh-sha2-nistp256
|       ecdh-sha2-nistp384
|       ecdh-sha2-nistp521
|       diffie-hellman-group-exchange-sha256
|       diffie-hellman-group14-sha1
|       diffie-hellman-group-exchange-sha1
|       diffie-hellman-group1-sha1
|   server_host_key_algorithms: (1)
|       ecdsa-sha2-nistp256
|   encryption_algorithms: (2)
|       aes256-cbc
|       aes256-gcm@openssh.com
|   mac_algorithms: (1)
|       hmac-sha2-512
|   compression_algorithms: (2)
|       none
|_      zlib@openssh.com
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 1.97 seconds

 This scan should not reveal any no weak algorithms and should display the key exchange algorithm set to a secure algorithm.