Réseaux d’information sur Sweet32 pour Palo Alto clients

Réseaux d’information sur Sweet32 pour Palo Alto clients

119923
Created On 09/26/18 21:04 PM - Last Modified 06/01/23 16:42 PM


Resolution


Résumé des Sweet32 

 

Les chercheurs de la sécurité de l'INRIA ont récemment publié un article qui décrit comment un attaquant pourrait percevoir une attaque contre les informations chiffrées à l'aide de plus anciens chiffrements de blocs de 64 bits, tels que 3DES et Blowfish pour récupérer avec succès le texte brut. Pour réussir, l’attaquant devra suivre une longue session HTTPS (validation du chercheur de principe requis une session HTTPS 3DES unique être surveillée de façon continue pendant deux jours) et être en mesure d’exploiter une distincte vulnérabilité script inter-site (XSS).

 

Ces attaques ne sont pas efficaces contre les chiffrements de cryptage modernes comme AES et l'algorithme de signature numérique de courbe elliptique (ECDSA).

 

Nous ne sommes pas au courant de toute attaque active contre ce problème en ce moment.

 

Les Palo Alto Networks sont à risques dans des circonstances limitées, dans le cas d’une attaque de « downgrade » qui obligerait les systèmes de Palo Alto Networks à utiliser 3DES comme un chiffre de cryptage de dernier recours. Les clients qui sont concernés peuvent prévenir ces attaques « downgrade » en mettant en œuvre les solutions de contournement décrites ci-dessous.

 

 

Impact sur les PAN-OS

 

Incidence sur les services SSL/TLS sur le pare-feu

Logiciel système PAN-OS prend en charge le chiffrement 3DES dans le cadre de la liste de suite de chiffrement négociée via des connexions SSL/TLS se terminant sur le pare-feu. Ces séances sont IP layer 3 services SSL offerts par le pare-feu, tels que l’accès web administratif pour la gestion des périphériques, GlobalProtect portails/portes d’entrée et portail captif. Semblable à d’autres serveurs web, PAN-OS maintient une liste de préférences de chiffrement interne. L’algorithme de chiffrement 3DES n’est pas inclus dans les cryptages de priorité dans la liste, car nous estimons qu’il est un algorithme de chiffrement faible qui est généralement pas négocié par le serveur. Cependant, un client malveillant peut offrir seulement les chiffrements de blocs affectés dans le cadre du message de Bonjour client forcer le serveur à négocier 3DES.

 

Un autre aspect est la durée de la session chiffrée qui permet une attaque réussie. L’hypothèse sous-jacente est que le même jeu de clés sont utilisées pour l’ensemble de la connexion.

 

Comment sécuriser un accès SSL

 

Clients de Palo Alto Networks peuvent atténuer l’attaque de Sweet32 par le déploiement de certificats de ECDSA et verrouiller la version du protocole de TLSv1.2 pour les divers services SSL/TLS sur le pare-feu. Cela garantit qu’une suite de chiffrement basé sur ECDSA est négociée par le serveur. L’algorithme de chiffrement 3DES prennent en charge l’authentification RSA. Définissant un certificat ECDSA élimine la possibilité de négocier le chiffrement 3DES.

 

En outre, chiffrements de courbe elliptique ont construit au mécanisme qui entreraient en plus tôt que la durée de vie de la session chiffrée, contrairement au RSA Refrappe où peut varier avec l’implémentation de pile SSL spécifique de régénération des clés. Cela garantit qu’une session SSL axée sur les EC longue durée de vie n’est pas sensible à la question Sweet32.

 

Étapes pour sécuriser l’accès SSL :

 

  1. Générer/importation d’un certificat de serveur ECDSA sur le pare-feu
  2. Créer un profil de service SSL/TLS avec les versions Min et Max sur TLSv1.2
  3. Référence du certificat ECDSA dans le profil de service
  4. Appliquer les profils pour les divers services de L3 SSL/TLS

 

Voici une capture d’écran pour sécuriser l’accès à l’admin web interface du pare-feu :

 

Picture1.png

 

Impact sur le trafic SSL décrypté à travers le pare-feu

 

Les clients de Palo Alto Networks qui ont déployé le décryptage SSL sur le périmètre de l’internet (sortante) ou devant une batterie de serveurs de centre de données peuvent sécuriser leur population d’utilisateurs et/ou les biens de l’entreprise contre une attaque potentielle de la Sweet32.

 

PAN-OS permet un contrôle de chiffrement sur le trafic de données déchiffrées qui coule à travers le pare-feu. Les étapes suivantes peuvent être utilisés pour prévenir une attaque potentielle de la Sweet32 sur la circulation de données décryptées :

 

  1. Désélectionner l’algorithme de chiffrement 3DES dans les objets-> profil de décryptage-> paramètres de protocole SSL-> algorithmes de cryptage
  2. Appliquer le profil de décryptage à vos stratégies de décryptage

Voici une capture d’écran du profil décryptage qui peut s’appliquer aux politiques de déchiffrement sortante et entrante :

 

Picture2.png

 

Impact sur l’accès SSH administratif CLI

 

SSH tunnels sont généralement utilisés pour l’accès à l’administration qui transportent moins de données à des débits très faibles. Si une connexion SSH aurait une vie taille de 32 Go ou davantage de données. Un administrateur peut réinitialiser périodiquement les clés SSH pour l’accès à l’administration via un simple script expect ou tcl.

 

La commande de débogage suivante peut être utilisée pour réinitialiser les clés SSH :

fwadmin@PA-200 > déboguer gestion ssh-clé-réinitialisation du système

 

Impact sur l’accès SSH décryptée à travers le pare-feu

 

PAN-OS ne supporte pas les algorithmes de chiffrement DES/3DES lors de l’exécution de SSH proxy sur sessions SSH gestion de biens grevés derrière le pare-feu. Un tel trafic ne pas être affecté par une attaque potentielle de la Sweet32.

 

Impact sur IPSec et IKE

 

Pare-feu de prochaine génération de Palo Alto Networks sont déployés dans des environnements variés avec un mélange de périphériques prenant en charge les algorithmes de crypto IPSec anciennes et actuelles. PAN-OS prend en charge les algorithmes de chiffrement DES et 3DES pour assurer la compatibilité descendante avec les systèmes existants et les soutenir aussi comme l’homologue IPSec.

 

PAN-OS offre un moyen souple de configurer chaque aspect du crypto IKE et IPSec. Un administrateur doit explicitement sélectionner des algorithmes de chiffrement qui doivent être négociés avec l’homologue IKE passerelle et IPSec tunnel point final.

 

Ceci peut être réalisé en désélectionnant DES ou 3DES algorithmes dans le profil de chiffrement IKE et IPSec

 

Voici un aperçu des profils cryptographiques qui peut être utilisé pour empêcher une attaque de Sweet32 :

 

Picture4.pngPicture3.png

 

Remarque: pour les clients qui ne veulent pas supprimer des et 3DES dans le cadre des négociations de phase 1 et de phase 2, Pan-OS réduit les risques d'une attaque Sweet32 potentielle car il retouche la connexion en fonction des données transférées.

 

Un administrateur peut définir la grandeur nature d’une connexion IPSec en définissant la taille de la vie comme 30Go (ou en utilisant un coefficient inférieur à 32GB). Voici la commande CLI qui permet d’y parvenir :

 

fwadmin@PA-200# ensemble de réseau ike crypto-profils ipsec-crypto-profils corp-ike lifesize

> Go spécifier lifesize dans gigabytes(GB)

> Ko spécifier lifesize en kilo-octets (Ko)

> Mo spécifier lifesize en mégaoctets (Mo)

> tb spécifier lifesize dans terabytes(TB)

  <Enter>Finition entrée</Enter>

 

Si vous avez des questions ou si vous avez besoin d'aide pour mettre en œuvre les étapes décrites ci-dessus, n'hésitez pas à contacter notre équipe de soutien à https://support.paloaltonetworks.com.

 

L’équipe de soutien de Palo Alto Networks



Actions
  • Print
  • Copy Link

    https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000Cm5mCAC&lang=fr&refURL=http%3A%2F%2Fknowledgebase.paloaltonetworks.com%2FKCSArticleDetail

Choose Language