Présentation des principes de sécurité¶
Sont documentés ici différents principes avancés de sécurité incorporés dans WAPT.
La lecture de cette documentation n’est pas indispensable pour utiliser WAPT ; elle est cependant recommandée pour vous permettre de mieux comprendre certains choix architecturaux.
Préambule et définitions¶
Attention
Le service WAPT fonctionne en compte système privilégié.
Attention
A partir de la version 1.5 de WAPT, le répertoire d’installation par défaut devient C:\Program Files (x86)\wapt.
Indication
les sous-composantes wapttray, waptservice et waptexit de l’agent WAPT peuvent être optionnellement désactivées en fonction du contexte d’usage.
Périmètre à sécuriser¶
Les éléments à sécuriser qui concernent strictement WAPT sont :
Le serveur WAPT (waptserver).
Les agents WAPT (wapt-get) et ses sous-composantes (wapttray, waptservice et waptexit).
La console de management (waptconsole).
Les communications réseaux entre ces différentes composantes.
En complément des éléments listés ci-dessus, un exploitant de WAPT devra choisir et suivre une méthodologie adaptée au contexte de son Organisation pour :
Assurer un téléchargement sûr de tous les autres fichiers servant à constituer un paquet WAPT.
Rédiger le script python
setup.pyd’installation d’un paquet WAPT de telle manière à éviter toute faille de sécurité ou de confidentialité exploitable.Gérer de manière sûre les clés privées de signature des paquets.
Gérer de manière sûre les Autorités de certification et de révocation des certificats SSL et HTTPS.
La gestion sûre de ces éléments complémentaires est exclue du périmètre de cette documentation.
Description des utilisateurs typiques¶
Les rôles suivants doivent être compris pour évaluer les principes de sécurité présents dans WAPT :
Utilisateur
Un Itilisateur est un individu équipé d’un machine avec l’agent WAPT (Enterprise et Community).
Déployeur de Paquet
Un Déployeur de Paquet est un individu pouvant signer des paquets ne contenant PAS de code python (en général les paquets de type group, unit et host) et les charger sur le dépôt principal (Enterprise).
Développeur de Paquet
Un Développeur de Paquet* est un individu pouvant signer des paquets, qu’ils intègrent ou non du code python et les charger sur le dépôt principal (Enterprise);
Note
La distinction entre Déployeur de Paquet et Développeur de Paquet n’existe que dans la version Enterprise de WAPT.
SuperAdmin
Le SuperAdmin est un individu avec tous les droits dans WAPT.
Administrateur Local
Utilisateur disposant des droits d’administration locaux sur les postes équipés de WAPT (Enterprise et Community) ;
Note
En fonction du contexte de la documentation et de la version du produit, un Administrateur désignera un Déployeur de Paquet, un Développeur de Paquet ou bien le SuperAdmin.
Note
Les Utilisateurs membres du groupe de sécurité Active Directory waptselfservice sont considérés comme des Administrateurs Locaux du point de vue de la sécurité WAPT.
Description des menaces pesant sur les biens sensibles WAPT¶
Par définition, un bien sensible est une donnée (ou fonction) jugée comme ayant de la valeur pour un attaquant.
Sa valeur est estimée selon des critères de sécurité (aussi appelés besoins de sécurité) :
Aisponibilité;
Intégrité;
Confidentialité;
Authenticité.
Les biens sensibles à protéger sont les suivants :
Bien sensible B1 : Les communications¶
Les communications entre le serveur central et les agents ainsi que les communications entre la console et le serveur sont un bien sensible et doivent être protégées.
Note
Besoin de sécurité des communications
Intégrité;
Confidentialité;
Authenticité.
Bien sensible B2 : Les données d’inventaire¶
Les informations sur l’état de déploiement des paquets, ainsi que configuration matérielle et logicielle des postes clients sont un bien sensible et doivent être protégées.
Note
Besoin de sécurité des données d’inventaire
Intégrité;
Confidentialité.
Bien sensible B3 : Les journaux d’historique¶
Les journaux générés par WAPT sur le serveur central et les agents sont un bien sensible et doivent être protégés.
Note
Besoin de sécurité des journaux d’historique
Disponibilité.
Bien sensible B4 : Les valeurs de configuration¶
Les valeurs de configuration du serveur (clés du serveur https, configuration accès à la base de données, configuration de l’authentification au serveur) sont un bien sensible et doivent être protégés.
Note
Besoin de sécurité des valeurs de configuration
Intégrité;
Confidentialité.
Bien sensible B5 : Les exécutables WAPT installés sur les postes client¶
Les exécutables WAPT installés sur les postes client managés (contenu du répertoire wapt incluant les binaires, les dll, les fichiers de configuration et la base de données) sont un bien sensible et doivent être protégés.
Note
Besoin de sécurité des valeurs de configuration
Intégrité.
Bien sensible B6 : L’authentification¶
Les données d’authentification à la console d’administration ainsi que les données d’authentification des agents sur le serveur (clé publique de chaque agent WAPT) sont un bien sensible et doivent être protégées.
Note
Besoin de sécurité de l’authentification
Intégrité;
Confidentialité.
Description des hypothèses sur l’environment d’exploitation de WAPT¶
Par définition, les hypothèses sont des déclarations portant sur le contexte d’emploi de WAPT ou de son environment.
Les hypothèses suivantes sur l’environment d’exploitation de WAPT doivent être considérées :
Hypothèse H1 : Les Administrateurs et Déployeurs de Paquet WAPT sont formés¶
Les Administrateurs et les Développeurs de Paquets sont formés à l’usage de WAPT. En particulier, ils doivent s’assurer que leurs identifiants et clés de sécurité restent secrets.
Hypothèse H2 : Les systèmes subjacents à WAPT sont sains¶
Les systèmes d’exploitation sur lesquels les agents WAPT s’exécutent mettent en oeuvre des mécanismes de protection adéquats (confinement, contrôle d’accès, etc.) paramétrés et configurés selon les bonnes pratiques.
Les systèmes d’exploitation sont à jour des correctifs en vigueur au moment de l’installation, ils sont sains et exempts de virus, chevaux de Troie, etc.
Hypothèse H3 : Les binaires nécessaires au fonctionnement de WAPT sont intègres¶
Toutes les librairies et outils nécessaires au fonctionnement de WAPT sont considérées saines. A la réception d’une requête par l’agent WAPT, il vérifie que la requête est correctement signée.
Hypothèse H4 : Les paquets WAPT sont construits de manière sûre¶
Il est de la responsabilité de l”Administrateur de s’assurer que les fichiers destinés à être intégrés dans des paquets WAPT proviennent de sources sûres et sont en particuliers exempts de virus, chevaux de Troie, etc.
Hypothèse H5 : Les Utilisateurs des postes client ne sont pas Administrateurs Locaux¶
Un Utilisateur n’a pas les droits d’administration de son poste de travail. Sinon l”Utilisateur est considéré comme un Administrateur Local.
En particulier, l”Utilisateur n’a pas les droits d’écriture dans le répertoire d’installation du client WAPT.
Hypothèse H6 : Les Administrateurs Locaux des postes client sont formés¶
L”Administrateur Local d’un poste client doit être formé à l’exploitation de WAPT, ou à défaut ne pas modifier les fichiers d’installation se trouvant dans le dossier d’installation de WAPT.
Description des menaces pesant sur les biens sensibles WAPT¶
Par définition, une menace est une action ou un événement susceptible de porter préjudice à la sécurité globale de la machine équipée de WAPT.
Les agents menaçants à considérer pour l’évaluation de sécurité sont les suivants :
Entités non-autorisées : il s’agit d’un attaquant humain ou d’une entité qui interagit avec WAPT mais qui ne dispose pas d’un accès légitime à celui-ci.
Note
Les Administrateurs et les Administrateurs Locaux ne sont pas considérés comme des attaquants.
Les menaces qui portent sur les biens sensibles WAPT définis ci-dessus sont les suivantes :
Description des fonctions de sécurité de WAPT¶
Par définition, les fonctions de sécurité sont l’ensemble des mesures techniques et mécanismes mis en œuvre pour protéger de façon proportionnée les biens sensibles contre les menaces identifiées.
Fonction de sécurité F1 : Authentification des contrôles d’accès¶
Fonction de sécurité F1A : Authentification d’une machine lors de son enregistrement initial dans la base de données WAPT¶
Nouveau dans la version 1.5.
Note
risques traités
L’inscription d’une machine illégitime dans la base de données.
Une attaque par déni de service par surcharge de la base de données.
Eviter l’enregistrement d’un inventaire falsifié dans la base de données.
Solution mise en place¶
Pour exister dans la base de données et ainsi apparaître dans la console WAPT, une machine doit s’enregistrer auprès du serveur WAPT avec une commande register.
La commande register peut être exécutée automatiquement lors de l’installation ou de la mise à jour de l’agent WAPT si la machine est correctement enregistrée avec un compte machine Kerberos dans le domaine Active Directory de l”Organisation.
Si la machine ne présente pas au serveur WAPT un ticket Kerberos valide, alors la commande register échoue;
Note
La méthode avec Kerberos assume que le serveur Active Directory répond au moment du register.
Fonction de sécurité F1B : Vérification des certificats HTTPS du serveur par les clients WAPT¶
Nouveau dans la version 1.5.
Note
risques traités (notamment MITM) :
L’envoi d’informations sensibles à un serveur WAPT illégitime et non-autorisé.
La récupération d’informations sensibles par une entité non-autorisée.
L’affichage d’informations falsifiées dans la console de l”Administrateur.
Une mauvaise date est envoyée lors d’une requête HEAD (demande de modification de date de fichier) empêchant les futures mise à jours.
Envoyer le mot de passe de la console à un serveur WAPT illégitime et non-autorisé.
Solution mise en place¶
Pour fonctionner correctement en version sécurisée :
Une option de vérification du certificat HTTPS serveur est introduite dans le fichier
C:\Program Files (x86)\wapt\wapt-get.inides agents WAPT qui force la vérification du certificat serveur par les agents WAPT .Une option de vérification du certificat HTTPS serveur est introduite dans le fichier
C:\Program Files (x86)\wapt\wapt-get.inides agents WAPT qui force la vérification du certificat serveur par les agents WAPT.
L’implémentation technique peut être basée sur deux méthodes :
Utiliser un utilitaire de vérification de certificat implémenté dans la configuration du service Nginx du serveur WAPT ; cette méthode est généralement fournie par une Autorité de Certification validée pour votre réseau.
Utiliser la méthode d”épinglage de certificat qui consiste a fournir à l’agent WAPT une liste de certificats de confiance qui sera stockée et maintenue dans le dossier
C:\Program Files (x86)\wapt\ssl\server.
Fonction de sécurité F1C : Aucun port n’écoute sur les agents WAPT¶
Nouveau dans la version 1.5.
Note
risques traités
Une entité non-autorisée utilise un port ouvert à mauvais escient.
Solution mise en place¶
Les connexions vers le serveur WAPT sont exclusivement initiées pas les clients, et les différentes actions instantanées (update / upgrade / install …) passent au travers d’une connexion permanente par une Websocket initiée par l’agent WAPT.
Note
si HTTPS est activé, l’agent vérifie que la Websocket s’établit bien avec le bon serveur.
Fonction de sécurité F1D : Signature des remontées d’inventaire¶
Nouveau dans la version 1.3.12.13.
Note
risques traités
Une entité non-autorisée envoie un inventaire falsifié d’une machine existante dans la base de données WAPT.
Solution mise en place¶
Au premier register, chaque machine crée un couple clé privée / certificat public dans le répertoire
C:\Program Files (x86)\wapt\privateaccessible en lecture uniquement aux Administrateurs Locaux. Une fois la machine enregistrée, la clé publique est envoyée au serveur WAPT.Lors d’une mise à jour de l’inventaire, le nouvel inventaire est envoyé signé avec la clé privée de la machine et déchiffré par la clé publique enregistrée dans la base de données.
Le serveur refusera de valider tout inventaire signé avec une mauvaise clé.
Fonction de sécurité F2 : Protection de l’intégrité du processus d’installation des paquets WAPT¶
Fonction de sécurité F2A : Signature des paquets WAPT¶
Note
risques traités
Pour éviter qu’une entité non-autorisée modifie le contenu ou le comportement d’un paquet WAPT.
Solution mise en place¶
Quand un Administrateur ou un Développeur de Paquet construit un paquet WAPT, un fichier
WAPTmanifest.sha256est créé qui liste les sommes de contrôle de tous les fichiers du paquet.Un fichier
signature.sha256chiffré avec la clé privée est ensuite créé dans le dossierWAPT, il contient la somme de contrôle du fichierWAPTmanifest.sha256.L’ensemble est archivé avec l’extension .wapt.
Quand un agent WAPT télécharge un paquet WAPT, l’agent vérifie que le fichier
signature.sha256a été signé avec la clé privée qui correspond au certificat présent dans le dossierWAPT.L’agent WAPT vérifie ensuite que le certificat (ou la chaîne de certificat)
certificate.crta bien été signé avec une clé privée correspondant à un des certificats présents dans le dossierC:\Program Files (x86)\wapt\ssl.L’agent WAPT fait ensuite la somme de contrôle de tous les fichiers du paquet (excepté les fichiers
signature.sha256etcertificate.crt) et vérifie que cela correspond au fichierWAPTmanifest.sha256contenu dans le paquet.Si l’une de ces étapes n’est pas validée, alors cela signifie qu’un fichier a été modifié/ ajouté/ supprimé. Alors, l’exécution du setup.py est annulée.
Le paquet en défaut est ensuite supprimé du cache local ; l’évènement est rapporté dans les log de l’agent.
Note
Depuis la version 1.5, le fichier manifest est passée de sha1 à sha256.
Fonction de sécurité F2B : Signature des attributs du fichier control¶
Nouveau dans la version 1.4.
Note
risques traités
Une entité non-autorisée modifie des dépendances WAPT sur la machine en falsifiant le fichier
https://waptserver/wapt/Packages.
Solution mise en place¶
Lors de la signature d’un paquet WAPT, les attributs sensibles du paquet sont listés dans l’attribut signed_attributes.
Note
Exemple d’une liste signed_attributes :
package, version, architecture, section, priority, maintainer, description, depends, conflicts, maturity, locale, min_os_version, max_os_version, min_wapt_version, sources, installed_size, signer, signer_fingerprint, signature_date, signed_attributes,
Les attributs listés dans signed_attributes sont signés avec la clé privée de l”Administrateur et la signature est stockée dans l’attribut signature du fichier control.
Le certificat associé à cette clé privée est stocké dans le fichier WAPT\certificate.crt à l’intérieur du paquet WAPT.
Sur le serveur WAPT, lors de l’opération wapt-scanpackages (déclenchée par un ajout ou suppression de paquet), l’index Packages des paquets est régénéré.
Le serveur WAPT extrait de chaque paquet le certificat du signataire et l’ajoute dans le fichier ZIP Packages, dans le répertoire ssl. Chaque certificat est nommé avec sa fingerprint encodée en hexadécimal.
Lorsque le client WAPT effectue un update (mise à jour des paquets disponibles), il télécharge le fichier index Packages, qui contient à la fois les attributs signés de tous les paquets et les certificats des signataires.
Si le certificat du signataire des attributs d’un paquet est approuvé (ce qui signifie que ce certificat est signé par une Autorité de Certification ou que le certificat lui-méme est de confiance), ET que le certificat du signataire peut vérifier la signature des attributs, le paquet est ajouté à l’index des paquets disponibles, sinon il est ignoré.
Fonction de sécurité F2C : Restriction d’accès au répertoire d’installation de l’agent WAPT¶
Note
risques traités
Une entité non-autorisée modifie le comportement de l’agent WAPT.
Le répertoire d’installation C:\Program Files (x86)\wapt est accessible en lecture et modification :
Aux Administrateurs Locaux à travers un accès local au répertoire d’installation de l’agent WAPT.
Aux Administrateurs à travers le mécanisme de déploiement des mises à jour de l’agent WAPT.
Ni les Développeurs de Paquets, ni les Utilisateurs n’ont d’accès en écriture au répertoire d’installation de l’agent WAPT.
Fonction de sécurité F2D : Restriction totale d’accès au répertoire de stockage du couple clé privé / certificat de signature d’inventaire¶
Note
risques traités
Une entité non-autorisée falsifie une remontée d’inventaire.
Une entité non-autorisée usurpe l’identité d’une machine avec WAPT.
Aucun droit d’accès au répertoire C:\Program Files (x86)\wapt\private n’est accordé à aucun Utilisateur, quel qu’il soit. Seul l’agent WAPT a accès en lecture et écriture à ce répertoire.
Note
Le stockage du couple clé privée / certificat découle d’un choix technique qui consiste à dire que la machine détient seule toutes les informations qui la concernent.
Fonction de sécurité F3 : Sécurisation des communications entre les différents composants WAPT¶
Fonction de sécurité F3A : Signature des requêtes envoyées aux agents WAPT¶
Nouveau dans la version 1.5.
Note
risques traités
Une entité non-autorisée envoie des requêtes falsifiées aux agents WAPT.
Solution mise en place¶
Les commandes ci-dessous sont signées par le serveur WAPT avant d’être envoyées au travers de la Websocket à l’agent WAPT destinataire de la commande :
wapt-get install: ordonner à l’agent WAPT d’installer un paquet WAPT marqué MISSING sur la machine.wapt-get remove: ordonner à l’agent WAPT de supprimer un paquet WAPT.wapt-get forget: ordonner à l’agent WAPT d’oublier l’existence d’un paquet WAPT installé sur la machine sans le désinstaller.wapt-get update-status: ordonner à l’agent WAPT de renvoyer l’état de son inventaire actuel au serveur WAPT.wapt-get upgrade: ordonner à l’agent WAPT d’exécuter les paquets marqués NEED UPGRADE.wapt-get update: ordonner à l’agent WAPT de mettre à jour la liste des paquets disponibles.
L’ensemble des attributs de cette requête sont signés :
L”UUID du poste ;
L’action (ex: install);
Les arguments (ex: tis-firefox);
L’horodatage des requêtes.
Le certificate associé à la signature est également passé :
A la réception d’une requête par l’agent WAPT, il vérifie que la requête est correctement signée.
L’agent vérifie ensuite que la date fournie en argument ne dépasse pas une minute de décalage.
Enfin, l’agent vérifiera enfin que le certificat associé est autorisé à lancer des commandes.
Présentation des processus cryptographiques¶
Date |
sept. 20, 2024 |
Rédacteur |
Hubert TOUVET |
Applicable pour WAPT |
>= 1.5.0.17 |
Version du document |
1.5.0.17-0 |
Les processus cryptographiques sont utilisés dans les activités suivantes :
Signature et vérification des fichiers contenus dans un paquet.
Signature et vérification des attributs d’un paquet.
Signature et vérification des actions immédiates sur les client WAPT.
Signature des inventaires et statut des clients WAPT.
Authentification de la connexion Websockets du client WAPT sur le serveur.
Communication https entre les clients WAPT et le serveur WAPT.
Communications HTTPS entre la console WAPT et le serveur WAPT.
Communications HTTPS entre les clients WAPT et les dépôts WAPT.
Répertoires et fichiers référencés dans ce document¶
<WAPT>: répertoire d’installation de WAPT. Par défaut%Program Files (x86)%WAPT.<WAPT>wapt-get.ini: fichier de configuration du client WAPT (wapt-get et waptservice).<WAPT>ssl: répertoire par défaut pour les certificats de confiance des paquets et actions.<WAPT>sslserver: répertoire par défaut pour stocker les certificats https du serveur (pinning).<WAPT>\private: répertoire par défaut pour les certificats permettant de signer l’inventaire et les connexions Websocket.%LOCALAPPDATA%waptconsolewaptconsole.ini: fichier de configuration de la console et des actions de développement de l’outil wapt-get.%appdata%waptconsolessl: répertoire par défaut pour les certificats de confiance pour l’import de paquets depuis un dépot externe (c.à.d. les modèles de paquets).
Définition des Acteurs¶
Organisation
Une Organisation est le périmètre de responsabilité dans lequel est exploitée la solution WAPT.
Autorité de Certification
Un certificat d’Autorité est l’entité qui détient les clés qui ont signé les certificats des Développeurs de Paquets, des Déployeurs de Paquets et des serveurs HTTPS.
Administrateurs
Les Administrateurs sont en possession d’une clé RSA personnelle et d’un certificat signé par l”Autorité de Certification de l”Organisation ; ils ont aussi un identifiant et un mot de passe pour accéder à la console WAPT.
Postes clients WAPT
Les clients WAPT sont l’ensemble des appareils que les Administrateurs de l”Organisation peuvent gérer avec WAPT. Les clients peuvent être ou non un membre du dmaine Active Directory de l”Organisation.
Serveur WAPT
Le serveur WAPT est un serveur Linux / Nginx / PostgreSQL de l”Organisation qui gère l’inventaire et le status des Postes clients WAPT.
Par défaut, le serveur WAPT joue également le rôle de dépôt WAPT interne. Le serveur WAPT a un compte ordinateur dans l’Active Directory de l”Organisation.
Dépôts WAPT internes
Les dépôt internet WAPT sont un ou plusieurs serveur Linux / Nginx qui diffusent aux Postes clients WAPT en HTTPS des paquets WAPT signés.
Dépôts WAPT externes
Les dépôts WAPT externe sont des dépôts WAPT publics que les Développeurs de Paquets peuvent utiliser pour importer des paquets conçus par d’autres Organisations, sous condition d’en vérifier l’adéquation aux normes internes de sûreté et de sécurité ;
Serveur Active Directory
Le serveur Active Directory gérant le domaine AD de l”Organisation;
Synthèse des modules crypto mis en oeuvre par la solution WAPT¶
À faire
sfonteneau
Coté client WAPT (WAPT 1.5.0.12) :
module ssl standard de Python 2.7.13 linké sur OpenSSL 1.0.2j 26 Sep 2016 pour les connexions https entre les clients WAPT et serveur WAPT.
cryptography==1.9 linké sur openssl 1.1.0f pour toutes les opérations crypto RSA, génération de clés, de certificat X509, de signature et vérification.
kerberos-sspi==0.2 et requests-kerberos==0.11.0 pour l’authentification du client WAPT lors de son enregistrement initial sur le serveur.
pyOpenSSL==17.0.0 : pour récupérer la chaîne de certificats du serveur WAPT.
certifi==2017.4.17 : base pour les certificats d’Autorité Racine.
dll Openssl 1.0.2l pour la partie waptcommon.pas écrite avec la bibliothèque FPC Indy et la classe TIdSSLIOHandlerSocketOpenSSL.
Coté serveur WAPT :
nginx/1.10.2: configurée pour TLS1.2, chiffre “EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH”.
module ssl standard de python 2.7.5 linké sur OpenSSL 1.0.1e-fips 11 Feb 2013.
cryptography==1.9 linké sur OpenSSL 1.0.1e-fips 11 Feb 2013 pour toutes les opérations crypto RSA, X509, signature et vérification.
Gestion des clés et des certificat de l’Administrateur¶
Les paquets et actions de l”Administrateur sont signés pour n’autoriser que les Administrateurs de confiance à intervenir sur les postes.
L”Administrateur de la solution WAPT a en sa possession :
Une clé privée RSA de 2048 bits chiffrée par l’algorithme aes-256-cbc.
Un certificat X509 signé par une Autorité de Certification approuvée par l”Organisation.
Note
Le processus d’émission de ces clés, la signature du certificat, la distribution et la révocation sont à la charge de l”Organisation utilisant WAPT et sortent donc du périmètre fonctionnel de WAPT.
Cependant, pour facilement tester la solution, WAPT propose une fonction pour générer une clé RSA et un certificat X509 :
La clé RSA générée est de 2048 bits, chiffrée par l’algorithme aes-256-cbc et encodée en format PEM avec l’extension .pem.
Le certificat est soit autosigné, soit signé par une Autorité de Confiancedont on a à disposition la clé et le certificat en format PEM.
Si le certificat est autosigné, son attribut KeyUsage comporte le flag keyCertSign.
Si l”Administrateur est habilité par l”Organisation à signer des paquets contenant du code python (présence du fichier
setup.py), l’attribut du certificat extendedKeyUsage comporte le flag CodeSigning.Le certificat X509 est encodé et remis à l”Administrateur en format PEM avec l’extension .crt .
Validité du certificat de l’Administrateur¶
Jusqu’à la version 1.5.0.12 incluse, Le client WAPT ne gère pas la vérification de la révocation du certificat de l”Administrateur lors du processus de vérifcation des paquets, attributs et actions de l”Administrateur.
Il ne vérifie que les dates de validité (attributs notValidBefore / notValidAfter). Le certificat est valide si (Now >= notValidBefore et Now <= notValidAfter).
Gérer les clés et certificats du Client WAPT¶
Le client WAPT (waptservice) utilise des clés RSA et un certificat X509 pour interagir avec le serveur WAPT.
Le certificat du client WAPT est utilisé dans les situations suivantes :
Lors de la mise à jour du statut du poste sur le serveur. (update_server_status) : signature des informations.
Lors de la connexion Websocket du poste vers le serveur (waptservice) : signature de l’UUID du poste.
Émission initiale et mise à jour du certificat du client WAPT¶
A l’issu du processus d’installation de l’agent WAPT sur le Poste client, l’agent WAPT s’enregistre automatiquement auprès du serveur WAPT en émettant une requête https authentifiée par Kerberos qui utilise le TGT du compte machine.
L’agent WAPT utilise les API kerberos de Windows en s’appuyant sur les modules python kerberos-sspi et requests-kerberos .
Note
tette procédure fonctionne si et seulement si le Poste client est joint au domaine Windows pour lequel le serveur WAPT est configuré.
Si la clé et les certificats n’ont pas encore été générés, ou s’ils ne correspondent pas au FQDN actuel de la machine, l’agent WAPT génère une clé RSA et un certificat X509 autosigné avec les paramètres suivants :
La clé est de type RSA 2048 bits encodée en PEM et stockée dans le fichier
<WAPT>\private\<fqdn du poste>.pem.Le certificat généré a les attributs suivants :
Subject.COMMON_NAME* = <FQDN e l’appareil>.
Subject.ORGANIZATIONAL_UNIT_NAME = nom de l”Organisation enregistré la base de registre du client Windows.
SubjectAlternativeName.DNSName = <device FQDN>.
BasicConstraint.CA = True.
Validity = 10 ans.
Serialnumber = aléatoire;
Le certificat est sauvegardé dans le fichier
<WAPT>private<device FQDN>.crt.Note
Seuls le compte machine et les Administrateurs Locaux ont accès au répertoire
<WAPT>\privatecar des ACL spécifiques sont appliquées à l’installation de l’agent WAPT sur le poste.L’inventaire ou les mises à jour de status du client sont envoyés au serveur WAPT par requête https POST;
On authentifie la requête https POST en ajoutant deux headers http spécifiques :
X-Signature :
Encodage en JSON des informations BLOB d’inventaire ou de status.
signature du json avec la clé privée du client WAPT : hachage sha256 et padding PKCS#1 v1.5.
encodage de la signature en base64.
X-Signer: Subject.COMMON_NAME ou UUID du client WAPT.
Après avoir initialement authentifié le client WAPT avec Kerberos, le serveur reçoit le certificat envoyé par le client et il le stocke dans son inventaire, dans la table hosts (champ host_certificate en format PEM).
Note
Si le poste client WAPT est renommé, la paire de clés et le certificat sont recréés.
Lors de la tentative de mise à jour de status du client vers le serveur, la requête POST sera refusée, car la machine est enregistrée dans la base de données avec un autre certificat.
La machine tentera alors de se ré-enregistrer (register) avec authentification kerberos ; ainsi le nouveau certificat sera enregistré dans la base de données.
Communications HTTPS entre les clients WAPT et les dépôts WAPT¶
Communications Websockets entre les clients WAPT et le serveur WAPT¶
Pour permettre des actions immédiates sur les clients WAPT, le service WAPT déployé sur les clients tente d’établir et de maintenir une connexion Websocket vers le serveur WAPT.
Cette connexion s’effectue sur un connexion chiffrée avec le protocole TLS et utilise côté client le même bundle de certificat que la connexion HTTPS Client vers Serveur WAPT.
Communications entre la console WAPT et le serveur WAPT¶
Déployer des certificats d’autorité¶
Paramètre verify_cert de la section [global] du fichier %LOCALAPPDATA%waptconsolewaptconsole.ini :
verify_cert = 1
cette méthode ne fonctionnera bien que si le serveur https est configuré pour renvoyer son certificat et les certificats intermédiaires à l’initialisation de communication TLS.
verify_cert = <chemin vers fichier .pem>
vérifie le certificat du serveur https en utilisant le bundle de certificats indiqué. Tous les certificats de CA intermédiaires et root doivent être rassemblés dans un fichier au format .pem;
verify_cert = 0
ne pas vérifier le certificat du serveur https;
Conventionnellement, on stocke le bundle de l”Autorité de Certification approuvées dans le répertoire <WAPT>sslserver.
La console WAPT comporte une fonction pour faciliter la récupération initiale de la chaîne de certificats du serveur et la stocker au format .pem dans le fichier <WAPT>sslserver<FQDN serveur>.
Il est de la responsabilité de l”Administrateur de s’assurer que la chaîne ainsi récupérée est authentique.
Il est également possible de récupérer la chaîne de certificats du serveur et de renseigner le paramètre verify_cert avec la commande wapt-get enable-check-certificate.
Processus de signature d’un paquet¶
Le processus de signature du paquet est lancé lors des actions suivantes :
action
wapt-get.exe build-upload <directory>.action
wapt-get.exe sign-package <path-to-package-file.wapt>.commande shell
wapt-signpackage.py <WAPT-package-list>.sauvegarde d’un paquet host dans la console WAPT.
sauvegarde d’un paquet group dans la console WAPT.
import direct d’un paquet depuis un dépôt externe.
wizard de création de paquets à partir de MSI et de setup.
Paramètres initiaux¶
Fichier ZIP du paquet;
clé privée RSA du signataire encodée en format .pem et chiffrée (par l’algorithme aes-256-cbc de openssl si la clé a été créée dans la console WAPT) ;
certificat X509 du signataire correspondant à la clé privée ;
si le paquet à signer contient un fichier
setup.py, le certificat X509 doit avoir l’extension advanced Key Usage : codeSigning (1.3.6.1.5.5.7.3.3) ;
Signature des attributs du fichier control¶
Le fichier control d’un paquet décrit les métadonnées du paquet, en particulier son nom, sa version, ses dépendances et ses conflits. C’est la fiche d’identité du paquet.
Ces métadonnées sont primitivement utilisées par l’agent WAPT pour déterminer si un paquet doit être mis à jour, et quels autres paquets doivent être installés ou désinstallés préalablement.
Ces informations sont donc signées pour garantir aux Postes client leur intégrité et leur authenticité.
Etapes du processus :
Les attributs signed_attributes, signer, signature_date, signer_certificate sont ajoutés à la structure du fichier
control:signed_attributes : liste des noms d’attributs avec séparateur virgule (,) ;
signer : commonName de l’objet du certificat du signataire ;
signature_date : date et heure en cours (UTC) sous la forme “%Y-%m-%dT%H:%M:%S” ;
signer_fingerprint : empreinte
sha256du certificat encodée en hexadécimal obtenue par la fonction fingerprint de la classe cryptography.x509.Certificate.
Les attributs de la structure control sont encodés en JSON.
Le JSON BLOB résultant est signé avec un hachage sha256 et un remplissage PKCS#1 v1.5.
La signature est encodée en base64 et stockée dans le JSON dans l’attribut signature du fichier
control.
Signature des fichiers du paquet¶
Les attributs du fichier control sont signés et sérialisés en JSON. Le résultat est stocké dans le fichier
<WAPT>controldu ZIP du paquet.Le certificat X509 du signataire depuis le fichier est stocké dans le fichier
<WAPT>certificate.crtdu paquet WAPT.Les empreintes sha256 de tous les fichiers contenus dans le paquet WAPT sont codées en hexadécimal et stockées sous forme de liste JSON [(nom de fichier, hachage),] dans le fichier
<WAPT>manifest.sha256dans le paquet WAPT.Le contenu du fichier
<WAPT>manifest.sha256est signé avec la clé privée de l”Administrateur (clé RAS 2048 bits), avec un hachage sha256 et un remplissage PKCS#1 v1.5:La procédure de signature fait appel à la fonction sign de la classe cryptography.rsa.RSAPrivateKey.signer.
cryptography.rsa.RSAPrivateKey.signer repose sur les fonctions OpenSSL de EVP_DigestSignInit.
La signature est encodée en base64 et stockée dans le fichier
<WAPT>signature.sha256du paquet WAPT.
Vérifier la signature des attributs d’un paquet¶
La vérification a lieu :
Lors de la mise à jour de l’index des paquets disponibles sur le client WAPT à partir de l’index
Packagesdu dépôt.Lorsqu’une signature de paquet est vérifiée (installation, téléchargement) lorsqu’elle n’est pas en mode développement, c’est-à-dire si l’installation se fait à partir d’un fichier ZIP et non d’un répertoire de développement.
La vérification consiste à :
Lire les attributs du fichier control depuis le fichier
<WAPT>\controldu ZIP du paquet.Récupérer le certificat X509 du signataire depuis le fichier
<WAPT>\certificate.crtdu ZIP du paquet.Décoder l’attribut signature du control depuis le format base64.
Construire une structure JSON avec les attributs devant être signés (tels que définis dans la classe PackageEntry).
Vérifier si la clé publique du certificat du titulaire peut vérifier le hachage de la liste structurée des attributs JSON et la signature du fichier
control, en utilisant le hachage sha256 et le remplissage PKCS#1 v1.5.Vérifier si le certificat est de confiance (soit présent en tant que tel dans les certificats de confiance, soit signé par une Autorité de Certification de confiance).
Dans le cas où nous devons vérifier les attributs sans avoir le paquet WAPT à disposition, nous récupérons la liste des certificats des détenteurs potentiels de certificats à partir du fichier d’index Packages sur le dépôt WAPT. Les certificats sont nommés ssl/<hexadecimal formated certificate fingerprint>.crt.
Un attribut de la structure control du paquet indique l’empreinte du certificat du signataire du fichier control.
Vérifier la signature d’un paquet¶
La vérification a lieu :
Lors de l’installation d’un paquet sur un Poste client.
Lors de l’édition d’un paquet existant.
Lors de l’import d’un paquet depuis un dépôt externe (si option cochée dans la console).
La vérification consiste à :
Récupérer le certificat X509 du signataire depuis le fichier
<WAPT>\certificate.crtdu ZIP du paquet.Vérifier que le certificat a été signé par une autorité de confiance dont le certificat est présent dans le fichier
ssldu client WAPT.Vérifier la signature du fichier
<WAPT>\manifest.sha256avec la clé publique.
Signature d’une action immédiate¶
Depuis la console, les Administrateurs peut déclencher des actions directes sur le client WAPT, s’il est connecté au serveur par le mode Websockets.
La console WAPT signe ces actions avec la clé et le certificat de l”Administrateur avant de les envoyer au serveur WAPT en utilisant une requête HTTPS POST ; la requête est ensuite transmise aux clients WAPT ciblés.
Les actions possibles sont :
trigger_host_update.
trigger_host_upgrade.
trigger_install_packages.
trigger_remove_packages.
trigger_forget_packages .
trigger_cancel_all_tasks.
trigger_host_register.
Processus de signature pour des actions immédiates¶
L’action est définie par son nom et des attributs dépendants de l’action. Les attributs sont uuid, action, force, notify_server, et packages (pour les actions impliquant une liste de paquets).
Les attributs signed_attributes, signer, signature_date, signer_certificate sont ajoutés à la structure de l’action:
signed_attributes : liste des noms des attributs qui sont signés.
signer : commonName de l’objet du certificat du signataire.
signature_date : date et heure en cours (UTC) sous la forme “%Y-%m-%dT%H:%M:%S”.
signer_certificate : certificat X509 du signataire encodé en base64.
La structure est encodée en JSON.
La signature du JSON est calculée à partir de la clé privée RSA du signataire en utilisant un algorithme de hachage sha256 et un remplissage PKCS1 v1.5.
La signature est encodée en base64 et stockée dans le JSON dans l’attribut signature.
Vérifier la signature d’une action immédiate¶
Depuis la console, les Administrateurs peut déclencher des actions directes sur le client WAPT, s’il est connecté au serveur par le mode Websockets.
Les actions sont encodées en JSON, signées avec la clé et le certificat de l”Administrateur et relayées vers le client WAPT visé par le serveur WAPT.
Les actions possibles sont :
trigger_host_update.
trigger_host_upgrade.
trigger_install_packages.
trigger_remove_packages.
trigger_forget_packages .
trigger_cancel_all_tasks.
trigger_host_register.
L’action get_tasks_status ne demande pas d’authentification ssl.
Sur réception d’un évènement par la connexion Websocket du client WAPT :
Le certificat X509 du signataire de l’action est extrait du json (format PEM).
Le client WAPT teste si le certificat est un certificat de confiance, c’est-à-dire présent dans
<WAPT>sslou signé par une autorité de confiance (certificat de l’autorité présent dans<WAPT>ssl).Le client WAPT teste si le certificat peut vérifier la signature présente dans la structure JSON de l’action ce qui consiste en:
Extraire la signature encodée en base64 dans le json depuis l’attribut signature dans le fichier JSON;
Extraire la date de signature formatée sous la forme “%Y-%m-%dT%H:%M:%S” depuis l’attribut signature_date;
Vérifier que la date de signature n’est pas trop ancienne ou dans le futur de plus de 10 minutes;
Reconstruire une représentation json des attributs de l’action ;
Vérifier que la clé publique du certificat peut vérifier le JSON avec la signature en utilisant un algorithme de hachage sha256 et un remplissage PKCS1 v1.5.
Vérification du téléchargement complet d’un paquet¶
Pour chaque paquet, une somme md5 du paquet est calculée et disponible dans l’index Packages du dépôt.
Lors de l’installation d’un paquet, le client vérifie si le paquet est déjà disponible localement dans le répertoire <WAPT>\cache.
Si le fichier est présent, sa somme md5 est comparée avec la somme md5 présente dans l’index. Si elles diffèrent, le paquet en cache local est effacé.
Cette somme md5 ne sert qu’à s’assurer qu’un paquet a été téléchargé complètement.
La vérification de la signature du paquet sera utilisé à la place de la somme md5et d’être effectivement assuré de l’intégrité et de l’authenticité du paquet.