Attention : le support de WAPT 1.8.2 a pris fin le 30 juin 2022.

Il y a plusieurs vulnérabilité présente dans la branche WAPT 1.8.2.7393. Merci de mettre à jour sur la version supportée la plus récente. Liste des CVEs (non exhaustive) :
  • * python engine : python 2.7 (CVE-2020-10735, CVE-2015-20107, CVE-2022-0391, CVE-2021-23336, CVE-2021-3177, CVE-2020-27619, CVE-2020-26116, CVE-2019-20907, CVE-2020-8492, etc.)
  • * cryptography : openssl : CVE-2022-2068, CVE-2022-1292, CVE-2022-0778, CVE-2021-4160, CVE-2021-3712, CVE-2021-23841, CVE-2021-23840, CVE-2021-23839, CVE-2020-1971, CVE-2020-1968, CVE-2019-1551
  • * python dependencies : cryptography (CVE-2020-36242, CVE-2020-25659), eventlet (CVE-2021-21419), jinja2 (CVE-2020-28493), psutil (CVE-2019-18874), waitress (CVE-2022-31015), lxml (CVE-2021-4381, CVE-2021-28957, CVE-2020-27783, CVE-2018-19787), ujson (CVE-2022-31117, CVE-2022-31116, CVE-2021-45958), python-ldap (CVE-2021-46823)

Changements entre 1.3 et 1.5/1.6 et conséquences

PostgreSQL a remplacé MongoDB dans WAPT

La base de données MongoDB a été remplacée par PostgreSQL avec le support JSON.

La conséquence est que ceux et celles qui avaient développé du reporting s’appuyant sur MongoDB devront adapter leurs requêtes.

Nginx est le seul serveur web aujourd’hui supporté dans WAPT

L’introduction des Websockets dans WAPT apporte de nombreux bénéfices :

  • la remontée des changements d’état des clients dans la console est instantanée ;

  • quand l”Administrateur force une mise à jour à effet immédiat, ce n’est plus le serveur qui établit une connexion avec l’agent ; l’agent WAPT maintient une connexion permanente avec le serveur ;

  • les Websockets évitent de maintenir ouvert un port en écoute sur le poste, améliorant ainsi la sécurité du dispositif ;

  • puisque l’agent WAPT initie et maintient une connexion avec le serveur, nous pouvons franchir plus facilement les proxys et les pares-feu ;

Nginx est le seul serveur web capable de gérer une grande quantité de Websockets. Cette technologie n’est pas quelque chose de trivial à implémenter et à maintenir.

En conséquence, le support IIS et Apache dans WAPT est abandonné.

Les hashs pour les signatures sont en sha256 au lieu de sha1

Les sommes de contrôle pour la liste des fichiers du paquet et la signature des attributs du fichier control sont maintenant des hashs sha256 au lieu de sha1 pour satisfaire les recommandations des organismes de sécurité.

En conséquence, nous devons resigner tous les paquets du dépôt et regénérer l’index :file:`Packages` du dépôt.

Un script permet de resigner en masse tous les paquets sur le serveur.

Les paquets machines sont nommés avec l’UUID du poste

Dans les versions <= 1.3.xx, les paquets machines sont nommés avec le nom complet du poste client.

Cela pose des problèmes lorsque la machine change de domaine, ou que la machine n’est pas dans un domaine mais change de réseau avec des noms de réseau DHCP différents.

Dans les versions >= 1.5, le paquet machine est nommé avec l’UUID du poste client, résolvant les problèmes décrit ci-avant.

En conséquence, il faut recréer et res-signer les paquets machines.

Un script sur le serveur permet de faire cette opération automatiquement.

Attribut Code Signing pour les certificats des paquets logiciels

Pour différencier les rôles de Déployeur de Paquets de celui de Développeur de Paquets, le client WAPT vérifie l’attribut Code Signing du certificat qui a signé le paquet.

Si le paquet contient du code python, c’est-à-dire qu’un fichier setup.py est présent, alors il doit être signé avec un certificat Code Signing. Sinon, il ne s’installera pas.

En conséquence, il faut recréer et déployer un certificat code signing sur le parc, et resigner les paquets logiciels avec un certificat de type Code Signing.

Le certificat est déployé lors de la mise à jour de l’agent WAPT.