Présentation des principes de sécurité dans WAPT¶
Date |
janv. 09, 2024 |
Rédigé par |
Hubert TOUVET, Vincent Cardon |
S’applique à WAPT |
>= 2.3.0.13180 |
Version du document |
2.3.0.0-0 |
Hash Git |
40a015e1c03eda179f15236aed38d61c4ca9d0d6 |
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é.
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 Utilisateur est un individu équipé d’une machine avec l’agent WAPT (Enterprise et Discovery).
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 (Enterprise and Discovery).
Administrateur Local
Utilisateur disposant des droits d’administration locaux sur les postes équipés de WAPT (Enterprise et Discovery).
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é) :
disponibilité ;
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é de l’authentification :
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 environnement.
Les hypothèses suivantes sur l’environnement 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 bibliothèques et tous les outils nécessaires à l’installation de WAPT sont considérés comme sûrs.
Hypothèse H4 : Les paquets WAPT sont construits de manière sûre¶
Il est de la responsabilité de l”Administrateur et du :ter:`Déployeur de Paquet`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.
Les Administrateurs sont également responsables d’écrire et d’incorporer des scripts setup.py sûrs dans les paquets WAPT.
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
Les risques évités sont :
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 ;
Lors de l’enregistrement, le poste client génère une paire de clés RSA dans le répertoire privé local et envoie au serveur une demande de signature de certificat avec le ticket kerberos.
Si le ticket Kerberos est valide, le Serveur WAPT enregistre le client dans sa base de données, signe le CSR, stocke le certificat dans sa base de données et le renvoie au client.
Si un appareil est déjà enregistré, il peut se ré-enregistrer sans ticket kerberos en utilisant le certificat signé de son serveur actuel.
Si l’authentification kerberos échoue ou n’est pas disponible, le serveur envoie un statut non autorisé, et le client peut demander à l’administrateur local d’entrer les informations d’identification d’un compte du serveur WAPT ayant le privilège admin ou le privilège register_host.
L’authentification du compte est effectuée côté serveur en utilisant les mécanismes admin, passwd ou ldap.
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
Les risques évités (notamment MITM) sont :
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
Les risques évités sont :
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
Les risques évités sont :
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
Les risques évités sont :
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.
Fonction de sécurité F2B : Signature des attributs du fichier control¶
Nouveau dans la version 1.4.
Note
Les risques évités sont :
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
Les risques évités sont :
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.
Les restrictions d’accès au dossier wapt reposent sur le mécanisme ACL standard du système d’exploitation et sont appliquées pendant l’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
Les risques évités sont :
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
Les risques évités sont :
Une entité non-autorisée envoie des requêtes falsifiées aux agents WAPT.
Solution mise en place¶
Les commandes suivantes, entre autres, sont signées par la Console WAPT avant d’être envoyées aux agents WAPT ciblés via le Serveur WAPT et les Websockets :
wapt-get install: demande à l’agent WAPT d’installer un paquet WAPT marqué MISSING sur la machine.wapt-get remove: demander à l’agent WAPT de supprimer un paquet WAPT.trigger package forget : demande à l’agent WAPT d’oublier l’existence d’un paquet WAPT précédemment installé sans supprimer le logiciel ou la configuration.
wapt-get update-status: demander à l’Agent WAPT de renvoyer l’état de son inventaire actuel au Serveur WAPT.wapt-get upgrade: demander à l’Agent WAPT d’exécuter les paquets marqués NEED UPGRADE.trigger host update : demander à l’agent WAPT de mettre à jour la liste des paquets disponibles, et de vérifier si le client doit installer, mettre à niveau ou supprimer les paquets WAPT, en fonction de l’arbre des dépendances des paquets WAPT.
Tous les attributs des demandes d’action immédiate 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 serveur¶
L’authentification kerberos est :
admin : le nom d’utilisateur et la dérivation du hachage pbkdf2-sha256 du mot de passe sont stockés dans la configuration du Serveur WAPT. Il s’agit du principal mécanisme d’authentification de l’Administrateur WAPT.
passwd : noms d’utilisateurs secondaires supplémentaires et hash des mots de passe sont stockés dans un fichier de style
htpasswdcôté serveur.ldap : si le hash passwd n’est pas défini dans le fichier
htpasswd, un serveur ldap peut être déclaré et utilisé comme mécanisme d’authentification pour les comptes secondaires du serveur wapt. Les comptes ldap valides sont définis par un DN de base ldap et une liste ldap de groupes.session : lors de l’authentification initiale à l’aide d’un des mécanismes admin, passwd ou ldap, un cookie de session peut être utilisé comme substitut à l’authentification ultérieure du serveur. Le cookie de session a une durée de vie par défaut de 12h.
Matrices de couvertures¶
Menaces et biens sensibles¶
La matrice suivante présente la couverture des menaces sur les biens sensibles (les lettres D, I, C et A représentent respectivement les besoins de Disponibilité, Intégrité, Confidentialité et Authenticité) :
B1. Communications |
B2. Données d’inventaire |
B3. Logs |
B4. Configuration |
B5. Postes clients |
B6. Authentification |
|
|---|---|---|---|---|---|---|
M1. Installation de logiciel mlaveillant |
I,C |
I |
||||
M2. Altération de configuration |
I |
|||||
M3. Accès illégitime |
I,C |
D |
I,C |
I |
I,C |
|
M4. Ecoute réseau |
C |
C |
||||
M5. Altération réseau |
I,A |
I,A |
Menaces et fonctions de sécurité¶
La matrice suivante présente la couverture des menaces par les fonctions de sécurité :
F1. Authentification des contrôles d’accès |
F2. Protection des données |
F3. Communications sécurisées |
F4. Signature des paquets |
|
|---|---|---|---|---|
M1. Installation de logiciel mlaveillant |
|
|
|
|
M2. Altération de configuration |
|
|
||
M3. Accès illégitime |
|
|||
M4. Ecoute réseau |
|
|||
M5. Altération réseau |
|
|
