PROJET AUTOBLOG


IT-Connect

Site original : IT-Connect

⇐ retour index

Retbleed : une baisse des performances de 70% sur les VM Linux sous VMware ESXi

mardi 13 septembre 2022 à 09:21

VMware alerte ses utilisateurs de la solution VMware ESXi sur la baisse des performances constatées sur les machines virtuelles avec le noyau Linux 5.19. Cette baisse peut atteindre 70% lorsque les mesures d'atténuation contre la faille de sécurité Retbleed sont activées.

Chez VMware, l'équipe chargée d'analyser les performances a constaté une baisse importante sur les machines virtuelles ESXi allant jusqu'à 70% sur le compute, 30% sur le réseau et 13% sur le stockage. Ces chiffres sont le résultat de la comparaison des performances entre une VM Linux avec le noyau 5.18 et une VM Linux avec le noyau 5.19. Cette dégradation des performances très importante est directement liée à la vulnérabilité "Retbleed" et à la mise en place des mesures d'atténuation pour se protéger contre cette faille de sécurité.

VMware a constaté qu'en désactivant les mesures d'atténuation liées à la vulnérabilité Retbleed, cela a rétabli les performances de la VM Linux. Pour être plus précis, ceci implique de configurer l'option "spectre_v2=off" dans les paramètres de démarrage du noyau. Ce paramètre se gère sur la VM Linux en elle-même. Néanmoins, le fait de retirer cette sécurité expose la machine à des attaques, en fonction du modèle de processeur (voir ci-dessous).

Qu'est-ce que la vulnérabilité Retbleed ?

Découverte en juillet 2022, la faille de sécurité Retbleed touche les processeurs et elle permet à un attaquant d'extraire des informations sensibles, comme le hash du mot de passe root, par exemple. En fait, cette vulnérabilité est liée à la célèbre faille Spectre et elle permet de contourner Retpoline, une solution visant à protéger des attaques spectres de type 2. On peut dire que Retbleed est une faille de type Spectre.

Au niveau des processeurs impactés par Retbleed, il y a les modèles Intel Core de la génération 6 (Skylake - 2015) à la génération 8 (Coffee Lake - 2017), ainsi que les processeurs AMD Zen 1, Zen 1+ et Zen 2 sortis entre 2017 et 2019. Autant vous dire qu'il n'est pas rare de croiser des serveurs avec ces générations de processeurs.

Ici, c'est l'exemple de VMware qui est cité, mais c'est certain qu'il y a un impact sur les performances sur les autres plateformes.

Source

The post Retbleed : une baisse des performances de 70% sur les VM Linux sous VMware ESXi first appeared on IT-Connect.

sources.list : un fichier indispensable pour déclarer les sources de paquets sous Debian

mardi 13 septembre 2022 à 07:15

I. Présentation

Dans ce tutoriel, nous allons étudier et manipuler le fichier "sources.list" d'une machine sous Debian ou Ubuntu. Mais au fait, qu’est-ce que le fichier « sources.list » ?

Ce fichier se situant dans « /etc/apt/sources.list » est un document texte référençant toutes les sources utilisées par l’utilitaire APT pour télécharger les paquets. Par défaut, des dépôts sont déjà renseignés dans ce fichier, mais vous pouvez ajouter d'autres sources (notamment dans le dossier "/etc/apt/sources.list.d/"). Grâce aux entrées ajoutées par défaut, quand on effectue "apt-get install <nom du paquet>", on peut télécharger et installer un paquet s'il est disponible dans les dépôts officiels pour la version actuelle du système. Pour fonctionner, APT a besoin d'une liste de sources de paquets.

Version initiale de l'article : 5 octobre 2011.

II. La syntaxe du fichier /etc/apt/sources.list

Le fichier "/etc/apt/sources.list" est le référentiel principal sur lequel s'appuie le gestionnaire APT pour télécharger les paquets. Néanmoins, ce n'est pas le seul fichier utilisé par le système puisqu'il y a le répertoire "/etc/apt/sources.list.d/" qui contient aussi d'autres fichiers pouvant permettre de charger d'autres sources (faisant références à des dépôts supplémentaires). C'est intéressant afin d'éviter de modifier le fichier principal, bien que ce soit parfois nécessaire.

Note : Les fichiers à l'intérieur du répertoire "/etc/apt/sources.list.d/" doivent utiliser l'extension ".list".

La bonne pratique convient d'utiliser le fichier "/etc/apt/sources.list" pour les dépôts officiels et d'utiliser le répertoire "sources.list.d" pour les autres dépôts.

Sur une machine Debian 11, voici le contenu du fichier /etc/apt/sources.list :

cat /etc/apt/sources.list

Debian - Fichier sources.list

On peut voir que ce fichier utilise une syntaxe particulière, mise en évidence sur l'exemple ci-dessus grâce aux différentes couleurs. Pour être plus précis, on peut déterminer la syntaxe de ce fichier comme suit :

deb http://<url du dépôt>/<répertoire d'accès> <archive> <composant>

Prenons cette ligne pour exemple :

deb http://ftp.fr.debian.org/debian/ bullseye main

On peut dire qu'elle définit la source de paquets correspondante à l'adresse "http://ftp.fr.debian.org/debian/" sur le serveur "ftp.fr.debian.org", en utilisant l'archive "bullseye" qui est le nom de code de Debian 11 (on peut considérer qu'ici on indique le nom de la distribution), et en ciblant le composant "main".

Cette ligne commence par "deb" tandis que d'autres lignes commencent par "deb-src". Il s'agit du type d'archive. Voici l'explication fournie sur le wiki de Debian : "Le premier mot sur chaque ligne, deb ou deb-src, indique le type d'archive. Deb indique que l'archive contient des paquets binaires (deb) qui sont les paquets précompilés que nous utilisons généralement. Deb-src indique les paquets sources qui sont les programmes Linux originaux sources plus le fichier de contrôle de Debian (.dsc) et le diff.gz contenant les changements nécessaires pour l'empaquetage du programme."

Pour le champ "archive", il faut savoir que :

Pour le champ "composant", il faut savoir :

Note : un dépôt est également appelé repository en anglais.

Pour éditer le contenu du fichier sources.list, il convient de bénéficier des autorisations "sudo" (ou d'utiliser le compte "root") et d'utiliser un éditeur de texte (nano, vi, etc.).

III. Le dossier /etc/apt/sources.list.d/

Comme je le disais, le répertoire "/etc/apt/sources.list.d" peut contenir d'autres fichiers dans le but de déclarer des dépôts non officiels, c'est-à-dire qui ne sont pas liés à Debian directement, mais qui permettent de récupérer des paquets pour Debian. C'est le cas de CrowdSec, Docker, etc...

Par exemple, pour installer CrowdSec sur Debian, on ajoute le fichier suivant :

/etc/apt/sources.list.d/crowdsec_crowdsec.list

Ce fichier contient le contenu ci-dessous, qui reprend les principes évoqués précédemment. Toutefois, il est à noter la présence de la clé GPG qui sert à vérifier la signature des paquets :

deb [signed-by=/usr/share/keyrings/crowdsec_crowdsec-archive-keyring.gpg] https://packagecloud.io/crowdsec/crowdsec/debian/ bullseye main
deb-src [signed-by=/usr/share/keyrings/crowdsec_crowdsec-archive-keyring.gpg] https://packagecloud.io/crowdsec/crowdsec/debian/ bullseye main

IV. Mettre à jour la liste des paquets

Lorsque vous ajoutez un nouveau dépôt dans le fichier "sources.list" (ou dans "sources.list.d"), il est important de mettre à jour le cache du gestionnaire APT. Sinon, il ne prendra pas en compte votre nouveau dépôt ou le changement que vous venez d'effectuer pour rechercher un paquet. Pour cela, exécutez la commande suivante :

sudo apt-get update

Sachez que la commande "apt-get update" ira lire le fichier principal ainsi que les fichiers ".list" situés dans le répertoire "sources.list.d".

V. Les commandes apt-cache et apt-key

Pour finir, sachez qu'il y a deux commandes supplémentaires à connaître pour visualiser la configuration actuelle de sa machine. Tout d'abord, la commande ci-dessous permet de visualiser la liste des dépôts déclarés et la priorité associée à chaque fois.

apt-cache policy

Debian - apt-cache policy - Exemple

Enfin, la commande ci-dessous permet d'afficher la liste des clés GPG déclarées sur votre système avec plusieurs informations, dont la date d'expiration et l'émetteur.

apt-key list

VI. Conclusion

Le fichier sources.list est un fichier essentiel sous Debian et même si on ne le modifie pas tous les jours, c'est important de savoir comment il fonctionne et de connaître son rôle au sein du système. Vous l'aurez compris, il est indispensable au bon fonctionnement du gestionnaire de paquets APT.

The post sources.list : un fichier indispensable pour déclarer les sources de paquets sous Debian first appeared on IT-Connect.

Lecteur réseau : comment créer un script de connexion avec net use ?

mardi 13 septembre 2022 à 07:00

I. Présentation

Ce tutoriel a pour but de vous apprendre à créer un script de connexion pour les utilisateurs utilisant votre domaine Active Directory. L'objectif de ce script est de donner accès à des lecteurs réseau qui se mappent automatiquement au lancement de la session, grâce à ce script. Pour cela, une commande DOS est utilisée, c’est la commande « net use ».

De nos jours, les scripts de connexion basés sur les commandes "net use" sont encore utilisés, et ils continuent de fonctionner, mais je vous recommande d'utiliser une stratégie de groupe pour effectuer cette opération. Ce tutoriel est là pour aider les personnes qui souhaitent toujours utiliser la méthode "net use" mais aussi pour vous informer de l'existence de cette "nouvelle méthode".

À ce sujet, vous pouvez lire cet article :

Version initiale de l'article : 20 juin 2011.

II. Syntaxe de net use

La commande net use s'utilise assez simplement. Voici un exemple :

net use X: \\Nom_du_serveur\Dossier_partagé

Ou

net use X: \\IP_du_serveur\Dossier_partagé

Pour être plus précis, voici des informations supplémentaires sur les paramètres :

Dans un même script, vous pouvez ajouter plusieurs lignes "net use", en veillant à utiliser une lettre différente à chaque fois sinon cela ne fonctionnera pas. Bien qu'il existe des options de "net use" pour préciser un identifiant et un mot de passe, il est totalement déconseillé de recourir à cette méthode : les informations seront visibles en clair dans le script, et ce dernier est accessible en lecture par les machines de votre domaine Active Directory.

Remarque : Cela est à écrire dans un fichier Bloc-notes et doit être enregistré avec l’extension ".bat" ou ".cmd".

III. Où stocker le script de connexion ?

Notre nouveau script de connexion doit être mis en place sur le serveur contrôleur de domaine Active Directory. Il y a un répertoire fait pour stocker les scripts de connexion, directement au sein du répertoire SYSVOL. Le fait que ce soit dans le répertoire partagé SYSVOL va assurer que les scripts seront répliqués entre vos différents contrôleurs de domaine.

Voici un exemple de chemin local, où vous devez adapter selon votre nom de domaine :

C:\Windows\SYSVOL\nom_du_domaine\scripts

IV. Active Directory et le script d'ouverture de session

Le script doit être indiqué dans le profil de tous les utilisateurs qui vont l’utiliser. À partir de la console "Utilisateurs et ordinateurs Active Directory", accédez aux propriétés de l’utilisateur puis indiquez le script en indiquant le nom précisément, comme ceci :

Active Directory - Script d'ouverture de session

Il est n'est pas utile de préciser le chemin réseau ou le chemin complet, car nous avons mis notre script dans le répertoire "scripts" de SYSVOL. Si vous devez effectuer cette opération sur de nombreux utilisateurs situés dans la même OU (ou la même racine), vous pouvez utiliser PowerShell.

La commande ci-dessous détermine le script de connexion "script.bat" pour tous les utilisateurs sous la racine "OU=Personnel,DC=it-connect,DC=local" de l'Active Directory.

Get-ADUser -Filter * -SearchBase "OU=Personnel,DC=it-connect,DC=local" | Set-ADUser –scriptPath "script.bat"

Si vous décidez de franchir le pas et de ne plus utiliser les scripts de connexion, sachez que vous pouvez aussi utiliser PowerShell pour supprimer la valeur en masse. Ainsi, le champ "Script d'ouverture de session" sera vide. Dans ce cas, voici la commande à utiliser (toujours en ciblant la même OU dans cet exemple) :

Get-ADUser -Filter * -SearchBase "OU=Personnel,DC=it-connect,DC=local" | Set-ADUser -Clear scriptPath

V. Suppression des lecteurs réseaux

Les lecteurs réseau peuvent être supprimés au démarrage de la session, pour être immédiatement recréés selon l’ordre d’exécution dans le script. Cela permet de repartir de zéro, c'est-à-dire avec aucun lecteur réseau de connecté. C'est assez fréquent de procéder ainsi pour être sûr qu'il n'y ait pas un ancien lecteur qui reste mappé, par exemple.

Voici la ligne à ajouter au tout début de votre script :

net use * /delete /yes

À la suite de cette ligne, ajoutez vos lignes "net use" permettant d'ajouter le(s) lecteur(s), comme nous l'avons vu précédemment.

The post Lecteur réseau : comment créer un script de connexion avec net use ? first appeared on IT-Connect.

EvilProxy : un service tout-en-un pour faire du phishing et contourner le MFA !

lundi 12 septembre 2022 à 17:01

Vous l'ignorez peut-être, mais l'activation de l'authentification à double facteurs sur un compte ne vous protégera pas de toutes les attaques, notamment des tentatives de phishing. Le nouveau service proposé par les pirates informatiques et baptisé EvilProxy en est la preuve ! Mais, qu'est-ce que c'est EvilProxy ? A quoi ça sert ?

Les chercheurs en sécurité de chez Resecurity ont fait la découverte d'un nouveau service baptisé EvilProxy et publié sur différents forums sur le Dark Web. Utilisé dans le cadre d'attaques de type phishing, EvilProxy s'appuie sur les principes de fonctionnement du reverse proxy et de l'injection de cookies pour contourner l'authentification à double facteurs.

On peut dire que la session de la victime est "proxifiée", car l'utilisateur, sans s'en rendre compte, va interagir avec un serveur proxy malveillant qui sert d'intermédiaire pour le site Web cible, ce qui va permettre à EvilProxy de récolter les identifiants et le code 2FA saisit sur la page de connexion. EvilProxy est capable de générer des liens de phishing qui renvoient vers des pages falsifiées (des copies du site d'origine) dans le but de compromettre les identifiants et il est compatible avec de nombreux services comme Apple iCloud, Facebook, GoDaddy, GitHub, Google, Dropbox, Instagram, Microsoft, NPM, PyPI, RubyGems, Twitter, Yahoo, etc.

EvilProxy, un service PhaaS disponible par abonnement

EvilProxy est un service de type phishing-as-a-service (PhaaS) proposé sous la forme d'un abonnement pour une période de 10, 20 ou 31 jours. Par exemple, on peut obtenir un accès à ce kit pour 400 dollars pour 1 mois, pour ensuite obtenir un accès via le réseau TOR en ayant au préalable effectué le paiement : cette étape indispensable s'effectue par l'intermédiaire de Telegram, après avoir échangé avec une personne à l'origine du projet EvilProxy. Autant dire que l'accès à l'outil est soumis à la validation des cybercriminels. Selon les options choisies, le prix de l'abonnement peut augmenter, car si l'on veut s'attaquer à des comptes Google, le coût peut atteindre 600 dollars par mois.

Nous pouvons voir aussi qu'au-delà de cibler des services comme Facebook, Google ou Microsoft, EvilProxy donne aussi la possibilité de cibler des accès NPM, PyPI, Github, etc... Ce qui peut être très puissant ! Si un attaquant obtient un accès non autorisé à un compte PyPI, il peut injecter du code malveillant dans un programme populaire et infecter de nombreuses personnes... Ce n'est pas seulement les utilisateurs lambda qui sont ciblés, mais également les développeurs, les devops, etc.

L'authentification à double facteur, oui, mais avec une clé de sécurité c'est encore mieux pour se protéger contre les attaques de ce type.

Source

The post EvilProxy : un service tout-en-un pour faire du phishing et contourner le MFA ! first appeared on IT-Connect.

Signer un script PowerShell avec un certificat auto-signé

lundi 12 septembre 2022 à 10:00

I. Présentation

Dans ce tutoriel, nous allons apprendre à signer un script PowerShell à partir d'un certificat auto-signé : une méthode facile à mettre en œuvre et qui permet de s'assurer que personne n'a effectué de modification dans votre script. En effet, si le script est modifié, alors il refusera de s'exécuter, car la signature ne sera plus correcte.

Précédemment, nous avons vu comment signer un script PowerShell à partir d'un certificat obtenu auprès d'une autorité de certification (ADCS). Je vous recommande cette méthode pour la production, car le certificat utilisé sera automatiquement reconnu par les serveurs et postes de travail de votre système d'information. A contrario, le script auto-signé doit être déployé manuellement sur les machines, et même s'il peut fonctionner en production et qu'il apporte un minimum de sécurité, il est plutôt recommandé pour les environnements de tests.

Au final, pour signer un script PowerShell, il y a trois manières d'obtenir un certificat :

Cette signature numérique va permettre de signer le code et d'assurer son intégrité : s'il est modifié, il faudra le signer de nouveau, sinon il ne pourra pas s'exécuter.

Pour bien comprendre l'intérêt de la signature de scripts PowerShell, je vous recommande aussi de lire cet article :

II. New-SelfSignedCertificate : générer un certificat auto-signé

Pour générer un certificat auto-signé sous Windows, nous pouvons utiliser le cmdlet New-SelfSignedCertificate. Ce certificat peut être stocké dans le magasin personnel de l'utilisateur ou de l'ordinateur (disponibilité globale sur la machine). Nous allons le stocker dans le magasin de l'ordinateur, ce qui correspond au chemin suivant : "Cert:\LocalMachine\My".

Voici la commande à utiliser pour générer un certificat auto-signé :

# Création d'un certificat auto-signé
$SelfSignedCert = New-SelfSignedCertificate -Subject ScriptPowerShell -Type CodeSigningCert -CertStoreLocation Cert:\LocalMachine\My -FriendlyName "Signer scripts PowerShell" -NotAfter (Get-Date).AddYears(5)

Les informations sur le certificat sont stockées dans la variable $SelfSignedCert, car nous allons importer ce certificat au sein de d'autres magasins de notre machine. Sinon, voici quelques informations supplémentaires sur les paramètres :

Vous pouvez lister les certificats de type "CodeSigningCert" présents dans le magasin personnel de votre ordinateur avec cette commande :

Get-ChildItem -Path Cert:\LocalMachine\My -CodeSigningCert

Vérifier la présence du certificat de signature de code

Logiquement, le certificat fraîchement créé doit apparaître dans la liste des résultats.

Pour que la signature numérique soit reconnue, ou plutôt que toute la chaîne soit reconnue, nous devons ajouter ce certificat dans deux autres magasins : "Autorités de certification racine de confiance" et "Éditeurs approuvés". Sinon, le script ne pourra pas s'exécuter avec la politique d'exécution "AllSigned".

Toujours en PowerShell, cette opération s'effectue avec les lignes suivantes :

# Ajouter le certificat dans "Autorités de certification racine de confiance"
# Créer un objet pour représenter le magasin de certificat LocalMachine\Root
$rootStore = [System.Security.Cryptography.X509Certificates.X509Store]::new("Root","LocalMachine")
# Ouvrir le magasin en lecture et écriture 
$rootStore.Open("ReadWrite")
# Ajouter le certificat dans le magasin, grâce au contenu de la variable $SelfSignedCert
$rootStore.Add($SelfSignedCert)
# Fermer le magasin de certificats
$rootStore.Close()

# Ajouter le certificat dans "Éditeurs approuvés"
# Créer un objet pour représenter le magasin de certificat LocalMachine\TrustedPublisher
$publisherStore = [System.Security.Cryptography.X509Certificates.X509Store]::new("TrustedPublisher","LocalMachine")
# Ouvrir le magasin en lecture et écriture 
$publisherStore.Open("ReadWrite")
# Ajouter le certificat dans le magasin, grâce au contenu de la variable $SelfSignedCert
$publisherStore.Add($SelfSignedCert)
# Fermer le magasin de certificats
$publisherStore.Close()

On aurait pu utiliser la commande Import-Certificate, mais cela implique de l'exporter au format CER au préalable. Si vous ouvrez une console MMC, que vous ajoutez le composant "Certificats" pour l'ordinateur local, vous verrez le certificat à trois emplacements comme sur l'exemple ci-dessous.

Script PowerShell - Certificat auto-signé - Console MMC

III. Set-AuthenticodeSignature : signer le script PowerShell

Le cmdlet Set-AuthenticodeSignature permet de signer des scripts PowerShell, peu importe la nature du certificat. Commençons par stocker le chemin du script à signer dans une variable :

$PathScriptToSign = "C:\TEMP\Script.ps1"

Pour information, ce script contient une seule ligne qui écrit une phrase dans la console :

Write-Host "Ce script est exécuté sur la machine $($env:COMPUTERNAME)"

Ensuite, la variable $PathCertToUse va contenir le chemin vers le certificat, au sein du magasin personnel de l'ordinateur. Dans cette commande, vous devez adapter le nom du certificat à moins que vous utilisiez le même que moi ("ScriptPowerShell").

$PathCertToUse = "Cert:\LocalMachine\My\" + (Get-ChildItem -Path Cert:\LocalMachine\My -CodeSigningCert | Where{ $_.Subject -eq "CN=ScriptPowerShell" }).Thumbprint

Cette variable contiendra la valeur suivante (si ce n'est que l'empreinte sera différente chez vous) :

Cert:\LocalMachine\My\CF5F933794EE29B1E4B9FDE63D30E8131915571D

Maintenant, il ne reste plus qu'à signer le script, à condition que le chemin vers le script soit valide, tout comme le chemin vers le certificat, d'où la condition "if" dans le code ci-dessous. Si les deux chemins sont valides, on signe le script à l'aide des informations du certificat stockées dans la variable $DataCertToUse.

if((Test-Path $PathScriptToSign) -and ($PathCertToUse -ne "Cert:\CurrentUser\My\")){
  Write-Host "Le script $PathScriptToSign va être signé avec le certificat ($PathCertToUse)"
  $DataCertToUse = Get-Item -Path $PathCertToUse
  Set-AuthenticodeSignature -FilePath $PathScriptToSign -Certificate $DataCertToUse -TimestampServer "http://timestamp.comodoca.com/authenticode"
}

Le script est bien signé, avec le statut "Valid" grâce au fait que l'on ait importé le certificat dans "Autorités de certification racines de confiance" et "Éditeurs approuvés". Sinon, nous aurions eu le statut "UnknownError" (qui n'empêche pas le script d'être signé).

Signer un script PowerShell - Certificat auto-signé

Voici quelques informations supplémentaires sur la commande Set-AuthenticodeSignature :

Si l'on regarde le contenu du script PowerShell, on peut voir qu'il y a un nouveau bloc nommé "SIG" correspondant à la signature numérique :

Script PowerShell - Signature intégrée dans le script

Note : si vous supprimez le bloc SIG de votre script, la signature est retirée et le script redevient non signé.

Dans les propriétés du fichier, l'onglet "Signatures numériques" donne des informations sur la signature :

Script PowerShell - Signature numérique

Avec PowerShell et le cmdlet Get-AuthenticodeSignature, nous pouvons également obtenir des informations sur la signature :

Get-AuthenticodeSignature -FilePath "C:\TEMP\Script.ps1" | fl

Le script est signé, nous allons essayer de l'exécuter.

IV. Exécuter un script PowerShell signé

Pour être certain que notre machine autorise uniquement l'exécution des scripts signés, nous pouvons modifier la politique d'exécution sur "AllSigned", comme ceci :

Set-ExecutionPolicy AllSigned

Suite à cette modification, la machine locale autorisera uniquement l'exécution des scripts signés. Si j'utilise cette politique d'exécution et que j'exécute "Script.ps1" avant qu'il soit signé, nous pouvons constater que l'exécution est bloquée :

Politique AllSigned - Exécution du script avant la signature

Par contre, suite à la signature effectuée via notre certificat, cela fonctionne !

Politique AllSigned - Exécution du script après signature

Attention, si vous utilisez ce script signé sur un autre machine, la signature numérique ne sera pas reconnu si le certificat n'est pas importé (ce qui impose des manipulations supplémentaires) ! C'est une contrainte de l'utilisation d'un certificat auto-signé.

Dans la pratique, à partir du serveur qui contient le script, nous pouvons exporter le certificat (pour générer le fichier C:\TEMP\ScriptPowerShell.cer) :

$PathCertToUse = "Cert:\LocalMachine\My\" + (Get-ChildItem -Path Cert:\LocalMachine\My -CodeSigningCert | Where{ $_.Subject -eq "CN=ScriptPowerShell" }).Thumbprint
Export-Certificate -Cert $PathCertToUse -Type CERT -FilePath C:\Temp\ScriptPowerShell.cer

Ensuite, le fichier "ScriptPowerShell.cer" doit être copié sur l'hôte distant. Une fois que c'est fait, dans "C:\TEMP\", par exemple, il faut l'importer dans les trois emplacements :

# Importer le certificat dans le magasin personnel de l'ordinateur local
Set-Location Cert:\LocalMachine\My\
Import-Certificate -FilePath "C:\temp\ScriptPowerShell.cer"

# Importer le certificat dans "Autorités de certification racine de confiance"
Set-Location Cert:\LocalMachine\Root\
Import-Certificate -FilePath "C:\temp\ScriptPowerShell.cer"

# Importer le certificat dans "Éditeurs approuvés"
Set-Location Cert:\LocalMachine\TrustedPublisher\
Import-Certificate -FilePath "C:\temp\ScriptPowerShell.cer"

Une fois que c'est fait, il sera possible d'exécuter le script signé, car la signature peut maintenant être reconnue par cette machine. Par ailleurs, vous devez garder à l'esprit qu'à chaque modification du script, il faudra le signer à nouveau avec votre certificat autosigné.

V. Conclusion

Nous venons de voir comment signer et exécuter un script PowerShell sur une machine Windows à partir d'un certificat auto-signé ! Gardez à l'esprit que vous devez vérifier le contenu des scripts PowerShell téléchargés à partir d'Internet, que ce soit un script signé ou non.

Maintenant, c'est à vous de vous exercer ! 🙂

The post Signer un script PowerShell avec un certificat auto-signé first appeared on IT-Connect.