I. Présentation

Aujourd’hui, on a deux versions majeures de PowerShell qui se battent en duel, parfois même sur nos machines : la version Windows PowerShell, appelée également PowerShell Desktop, et la version PowerShell Core, qui en est aujourd’hui à la version 7.1.3.

Plutôt bizarre, non ? Et bien non, ça s’explique.

Du coup, je vous sens un peu confus. Pourquoi deux versions sont-elles maintenues en parallèle par Microsoft ? Quelles sont les différences entre ces deux versions ? Et surtout laquelle faut-il choisir et préférer ?

On vous dit tout dans cet article !

II. Prérequis

• Avoir Windows PowerShell / PowerShell Desktop d’installé sur votre poste. Si vous êtes sur les dernières versions de Windows 10 ou Windows Server, bonne nouvelle, vous possédez déjà la version 5.1.
• Installer PowerShell Core. Rendez-vous sur https://aka.ms/powershell pour installer la dernière version.

III. Comment vérifier sa version de PowerShell ?

Avant toute chose, comment savoir quelle version de PowerShell vous avez sur votre machine ?

Suivez les instructions ci-dessous, ou regardez la vidéo de Florian à ce sujet :

C’est plutôt simple en fait :

Si vous utilisez la version de PowerShell intégrée à votre Windows 10 ou votre serveur, vous utilisez PowerShell Desktop version 5.1.

Si vous avez installé PowerShell Core sur votre poste de travail, vous vous retrouverez avec deux versions de PowerShell : le PowerShell Desktop 5.1 intégré, et le PowerShell Core, qui est un exécutable séparé.

Comme vous le voyez, je dispose des deux versions de PowerShell sur mon PC :

• Windows PowerShell, aussi appelée l'édition Desktop. Sa version actuelle est la 5.1.
• PowerShell 7 (x64), aussi appelée l'édition Core. Actuellement à la version 7.1.3.

Comment en être sûr en ouvrant un terminal ? Vérifiez la variable $PSVersionTable, et votre terminal révèlera tous ses secrets :

$PSVersionTable

Sur l'image ci-dessus, on peut voir que PowerShell intégré au système est bien en édition Desktop, version 5.1.

Ce terminal est quant à lui en édition Core, version 7.1.3

IV. PowerShell Core va-t-il remplacer PowerShell Desktop ?

À terme, PowerShell Core devrait prendre le pas sur Windows PowerShell (PowerShell Desktop), et être installé à sa place par défaut dans les systèmes Windows.

C’est en tout cas l’ambition de Microsoft, mais aucun calendrier ni aucune roadmap n’a été partagé pour le moment à ce sujet.

Pas de panique donc, tous vos scripts et votre automatisation sur PowerShell Desktop ne va pas s’arrêter du jour au lendemain. 

PowerShell 7 dispose d’un support Long Term Servicing (LTS), c’est à dire 3 ans de support à compter du 03 Décembre 2019, ce qui nous emmène à Février 2022 (oui ok, ça ne fait pas exactement 3 ans, mais c'est l'information communiquée par Microsoft à ce jour).

 

V. Quelles sont les principales différences entre PowerShell 5.1 et PowerShell 7 ?

Les éditions Desktop et Core de PowerShell ont quelques différences fondamentales. Voici la liste des plus importantes et plus impactantes, la première étant bien sûr la compatibilité des systèmes d’exploitation.

A. Systèmes d’exploitation compatibles

• PowerShell 5.1

Alors là, pas de miracle, l’édition Desktop de PowerShell, actuellement en version 5.1, n’est compatible qu’avec le monde Windows. That’s it folks !

Pour le détail, le voici :

Version de Windows	Configuration requise
Windows Server 2019	Installé par défaut
Windows Server 2016	Installé par défaut
Windows Server 2012 R2	Installer Windows Management Framework 5.1
Windows Server 2012	Installer Windows Management Framework 5.1
Windows 10, version 1607 & supérieure	Installé par défaut
Windows 10, version 1507, 1511	Installer Windows Management Framework 5.1

Et si vous souhaitez consulter la configuration requise pour les versions précédentes, c’est ICI que ça se passe.

• PowerShell 7+

L’édition Core de PowerShell est une édition Cross-Platform. Autrement dit, il est maintenant possible d’installer PowerShell sur Linux ou MacOS.

Oui oui, vous avez bien lu ! 

En plus des systèmes d’exploitation clients & serveurs Windows listés ci-dessus, vous pouvez maintenant installer PowerShell 7 sur :

• MacOS version 10.13+
• Red Hat Enterprise Linux (RHEL)
• CentOS version 7 (il s’agit de la version LTS)
• Fedora Linux 30+
• Debian 9
• Ubuntu LTS 16.04+
• Alpine Linux 3.8+

À noter que même si ce n’est pas officiellement pris en charge par Microsoft, vous trouverez des packages pour Arch Linux & Kali Linux, gracieusement mis à disposition par la communauté.

B. Répertoire d’installation

Sur Windows, le répertoire d’installation de Windows est le plus souvent C:\WINDOWS. Mais ce n’est pas obligatoire. Du coup, il existe une variable d’environnement qui contient le chemin d’installation du dossier WINDOWS. Il s’agit de la variable %SYSTEMROOT%, également appelable %WINDIR%.

Ces variables d’environnement sont accessibles dans PowerShell en exécutant :

$env:SystemRoot

ou encore :

$env:WINDIR

Pourquoi je vous en parle ? Car cette variable va apparaître dans les répertoires d’installation de PowerShell.

Version	Chemin de l’exécutable
PowerShell x64 (édition Desktop v5.1)	%SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe
PowerShell 7 (edition Core)	C:\Program Files\PowerShell\7\pwsh.exe

Pour obtenir à coup sûr le chemin de votre exécutable PowerShell, vous pouvez exécuter cette commande :

(Get-Process -id $PID).Path

C’est infaillible !

Le chemin pour PowerShell édition Desktop (version 5.1) est :

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

Le chemin pour PowerShell édition Core (version 7 et supérieure) est :

C:\Program Files\PowerShell\7\pwsh.exe

C. Répertoire d’installation des modules

Quand vous installez des modules PowerShell, ceux-ci vont se stocker par défaut dans un répertoire, en local sur votre poste. Et je vous le donne dans le mille, la localisation du répertoire a évolué entre PowerShell 5.1 et PowerShell 7.

Voyez par vous-même :

PowerShell 5.1	PowerShell 7
$env:SystemRoot\system32\WindowsPowerShell\v1.0\Modules	$env:ProgramFiles\PowerShell\7\Modules

Comment le vérifier ? Ouvrez votre terminal préféré et exécutez la commande suivante :

Get-ChildItem "$PSHOME\Modules"

Ci-dessous, voici le résultat pour l'édition Desktop de PowerShell. Les modules s'installent par défaut dans le répertoire C:\Windows\System32\WindowsPowerShell\v1.0\Modules.

Et voici le résultat pour l'édition Core. Les modules s'installent par défaut dans le répertoire C:\Program Files\PowerShell\7\Modules.

D. Localisation du profil

Votre profil PowerShell n’est plus ni moins qu’une suite d’instructions (codées en PowerShell) que vous pouvez exécuter de manière automatique à chaque fois que vous lancez un nouveau terminal pour, par exemple, customiser votre terminal.

Et comme précédemment, la localisation de ce profile a changé entre PowerShell 5.1 et PowerShell 7.

PowerShell 5.1	PowerShell 7
$HOME\Documents\WindowsPowerShell	$HOME\Documents\PowerShell

Comment s’en assurer ? En vérifiant le contenu de la variable $profile :

$profile

Dans l'édition Desktop, le profil est stocké dans le fichier C:\Users\<votre-nom-utilisateur>\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1

Dans l'édition Core, le profil est stocké dans C:\Users\<votre-nom-utilisateur>\Documents\PowerShell\Microsoft.PowerShell_profile.ps1

E. Politique de mise à jour

Microsoft va se limiter aux corrections des bugs critiques sur PowerShell édition Desktop version 5.1, et il n’y aura plus d’autres mises à jour de prévues.

Toute nouvelle fonctionnalité et mise à jour se fera sur l’édition Core, ainsi que les corrections de bugs non critiques.

L’avenir de PowerShell se fait donc clairement du côté de l’édition Core.

F. Notification en cas de nouvelle version

Au démarrage de PowerShell 7, PowerShell interroge les services en ligne de Microsoft pour vérifier s’il existe une nouvelle mise à jour. Si c’est le cas, vous obtiendrez une notification directement dans votre terminal, avec un lien pour le mettre à jour.

À noter qu’il est possible de modifier le comportement de cette notification de mise à jour en modifiant la valeur de la variable d’environnement :

$Env:POWERSHELL_UPDATECHECK

Plus d’infos ici.

G. Environnement de développement

Pour l’édition Desktop, vous avez le choix : soit utiliser PowerShell ISE, votre environnement de développement installé par défaut sur postes de travail & serveurs, soit utiliser VS Code, by Microsoft.

Je vous recommande clairement d’utiliser le second, déjà parce que c’est l'éditeur recommandé pour PowerShell 7+, mais également parce que vous pourrez installer de nombreux plugins vous facilitant la vie, coder également dans d’autres langages, utiliser des fonctionnalités avancées de versioning de code comme Git, etc.

H. Nouvelles fonctionnalités PowerShell Core

Vous souhaitez connaître en détail les nouveautés de PowerShell 7 ? Retrouvez l’information complète et à jour dans cet article de Microsoft.

Personnellement, les nouveautés que j’apprécie le plus sont la parallélisation de pipeline (ForEach-Object -Parallel), l’affichage des erreurs simplifiées, et l’opérateur de condition Null, qui permet de vraiment simplifier ses conditions & tests dans ses scripts.

VI. PowerShell Core ou PowerShell Desktop : lequel choisir ?

Maintenant que vous avez bien en tête les différences entre la version Desktop et la version Core, vous allez me dire :

« Ok, mais concrètement, lequel choisir ? »

« Je suis débutant sur PowerShell, quelle version choisir ? » PowerShell Core (version 7). Les futures fonctionnalités ne seront publiées par Microsoft que sur la version Core.

« J’ai déjà développé des scripts & automatisé des tâches d’administration sur mes serveurs, quelle version choisir ? » Restez sur le moment sur PowerShell 5.1 : certains de vos scripts peuvent ne pas être compatibles en l’état avec PowerShell Core. Il faudra peut-être faire des corrections au cas par cas.

« J’utilise des modules particuliers ou des fonctionnalités .NET dans mes scripts, quelle version choisir ? » Vérifiez que les modules et fonctionnalités .NET que vous utilisez sont compatibles avec PowerShell Core : tout ne l’est pas. Dans le doute, restez sur PowerShell 5.1.

« J’ai migré tout ou partie de mon infrastructure dans le cloud (Azure, Office 365), quelle version choisir ? » Adoptez l’édition Core, pour profiter des dernières fonctionnalités.

 

VII. Migrer ses scripts de PowerShell Desktop vers PowerShell Core

Avant de vous lancer dans une refonte complète de vos scripts, commencez par vérifier si les modules que vous utilisez sont compatibles avec l’édition Core de PowerShell.

Pour cela, Microsoft tient à jour cette page, pour indiquer les modules testés par leurs soins : https://docs.microsoft.com/fr-fr/powershell/scripting/whats-new/module-compatibility?view=powershell-7.1 .

Le module que vous utilisez n’est pas dedans ? Pas de panique ! Microsoft a pensé à vous.

Un nouveau paramètre est apparu dans PowerShell 7 pour la fonction Import-Module : le fameux "-UseWindowsPowerShell".

Import-Module -UseWindowsPowerShell <ModuleName>

Concrètement, ce commutateur va créer un module proxy dans PowerShell 7, qui va utiliser un processus « Windows PowerShell » (ou PowerShell édition Desktop 5.1) pour exécuter les cmdlets contenues dans ce module.

Il ne vous reste plus qu’à tester ! 

VIII. Conclusion

Toujours pas convaincu pour faire de PowerShell votre meilleur ami ? Laissez-moi dans ce cas vous expliquer pourquoi vous ne pouvez plus passer à côté, dans le prochain article.

Alors au final, vous êtes plutôt team Desktop ou team Core ?

The post Windows PowerShell VS PowerShell Core : Quelles différences ? Lequel choisir ? first appeared on IT-Connect.

Le gestionnaire de paquets de Microsoft, WinGet, va bénéficier de nouvelles commandes qui vont lui permettre d'accueillir de nouvelles fonctionnalités bienvenues, notamment pour désinstaller un paquet.

Windows Package Manager alias WinGet est un gestionnaire de paquets en ligne de commande qui s'installe sur Windows 10 et qui permet d'installer facilement des logiciels. Finalement, c'est un outil dans le même esprit que le célèbre Chocolatey, ou encore les gestionnaires de paquets sous Linux.

Microsoft a publié la version 0.3 de WinGet et celle-ci introduit de nouvelles fonctionnalités expérimentales qui vont améliorer grandement ce gestionnaire de paquets. En effet, jusqu'ici il n'était pas possible de désinstaller un paquet à l'aide de WinGet, mais seulement de procéder à l'installation et la mise à jour d'un logiciel.

Au sein de cette version, WinGet bénéficie de deux nouvelles commandes :

winget list

Cette commande permet de lister tous les programmes installés sur la machine, tandis que la commande ci-dessous sert à désinstaller n'importe quel logiciel présent sur la machine. Il est à noter que même si une application n'a pas été installée directement par WinGet, elle peut être désinstallée grâce à cette nouvelle commande.

winget uninstall <nom du logiciel>

Pour installer cette nouvelle version preview, il faut être membre du programme Insider de Microsoft ou sinon il faut récupérer le package d'installation sur GitHub directement. Ensuite, il faudra activer l'utilisation des fonctionnalités expérimentales au sein de WinGet.

Pour effectuer cette opération, il faut exécuter la commande ci-dessous après avoir installé WinGet :

winget settings

Cette commande va permettre d'ouvrir le fichier de configuration au format JSON et vous permettre d'activer les fonctionnalités expérimentales que vous souhaitez.

"experimentalFeatures": {
  "experimentalCmd": true,
  "experimentalArg": true,
  "experimentalMSStore": true,
  "list": true,
  "uninstall": true,
  "export": true
}

Ce qui donne :

En complément, Microsoft a publié sur GitHub le fichier ADMX qui va permettre de piloter WinGet par GPO sur les postes clients. Ces paramètres vont permettre de spécifier si WinGet peut être utilisé ou non, s'il est autorisé ou non d'activer des fonctionnalités expérimentales, etc.

Tutoriel Winget sous Windows 10

Source

The post Windows 10 : WinGet va bénéficier d’une commande pour désinstaller un paquet first appeared on IT-Connect.

Suite au démantèlement du malware Emotet par l'agence Europol, le malware Emotet va s'auto-détruire des machines infectées, et cela à l'échelle mondiale.

En janvier dernier, l'agence Europol annonçait le démantèlement du malware Emotet : ce botnet était à l'origine de nombreuses attaques depuis 6 ans. Les forces de l'ordre de huit pays s'étaient mobilisées pour venir à bout d'Emotet ! La France a participé à cette action, ainsi que les États-Unis, l'Allemagne, le Canada, le Royaume-Uni, la Lituanie, les Pays-Bas et l'Ukraine. Grâce à cette intervention, les autorités avaient pris le contrôle de l'infrastructure d'Emotet.

Désormais, il va s'auto-détruire des machines sur lesquelles il est en place grâce à un module de désinstallation déployé en janvier dernier par les autorités. Concrètement, toutes les machines infectées ont une version modifiée du fichier EmotetLoader.dll et l'objectif est que le malware se désinstalle automatiquement à partir du 25 avril 2021.

Deux chercheurs en sécurité de chez Malwarebytes, Jérôme Segura et Hasherezade, ont pu analyser le module de désinstallation déployé par les autorités. Il s'avère qu'il va supprimer plusieurs éléments liés à Emotet directement : les services Windows associés et les clés de Registre, puis le processus se termine.

La Bundeskriminalamt, c'est-à-dire l'Office fédéral de police criminelle d'Allemagne, est à l'origine de la création et du déploiement de cet outil de désinstallation pour Emotet. Pour le déploiement, les autorités se sont appuyées sur l'infrastructure de serveurs Command & Control utilisée par Emotet. Ensuite, les communications se sont faites vers une autre infrastructure montée par les autorités elles-mêmes dans le but de centraliser la collecte des preuves sur une infrastructure indépendante.

Il est important de confirmer que ce module déployé sur les machines infectées n'empêche pas l'installation de malwares additionnels et indépendants d'Emotet. En tout cas, il permet à la machine d'être libérée du botnet Emotet : la machine ne pourra plus être contrôlée par cet intermédiaire.

Source

The post Le malware Emotet va s’auto-détruire des machines infectées first appeared on IT-Connect.

Quelques utilisateurs de Windows 10 ont rencontré des problèmes de performances sur les jeux vidéos suite à l'installation de deux mises à jour : KB5000842 et KB5001330.

Ces deux mises à jour correspondent à des correctifs déployés en mars et avril 2021, à destination de Windows 10 et plus particulièrement des versions suivantes : Windows 10 version 2004, 20H2 et 21H1.

Microsoft a confirmé qu'il y avait bien des soucis avec les jeux : instabilité, baisses de performances notamment des chutes de framerate, plantages intempestifs.... Cela vient s'ajouter aux problèmes rencontrés par de nombreux utilisateurs où la machine plantait complètement pour afficher un écran bleu.

De son côté, Nvidia recommande aux utilisateurs de désinstaller la mise à jour KB5001330 pour ne plus être embêtés. Microsoft quant à lui, précise que ce dysfonctionnement va être corrigé automatiquement sur les machines en s'appuyant sur la fonctionnalité Known Issue Rollback (KIR) de Windows Update. L'objectif de cette fonctionnalité est de rétablir le bon fonctionnement d'une machine dans le cas où des dysfonctionnements sont détectés.

La résolution à ce problème poussée par Microsoft va se déployer automatiquement sur les machines, dans un délai de 24 heures : un délai qui est désormais passé. La fonctionnalité KIR est supportée par Windows 10 depuis la version 2004.

Suite à cette modification apportée par Microsoft, ce - nouveau - bug qui fait suite à une mise à jour devrait être de l'histoire ancienne pour les utilisateurs. Ces derniers temps, les mises à jour de Windows 10 sont la source de nombreux problèmes.... On a tous hâte que cela s'arrête !

Source

The post Màj Avril 2021 : Microsoft corrige les problèmes de performances avec les jeux first appeared on IT-Connect.

Depuis la semaine dernière, le ransomware Qlocker s'attaque massivement aux NAS QNAP dans le but de chiffrer les données à l'aide d'une solution simple, mais redoutable : 7-Zip. Résultat, en 5 jours, Qlocker a généré plus de 260 000 dollars de gains.

Le ransomware Qlocker s'attaque massivement aux NAS QNAP

Pour rappel, cette attaque repose sur l'exploitation d'une faille critique, désormais corrigée par QNAP, mais pas encore installée sur tous les appareils. QNAP estime que c'est la vulnérabilité CVE-2020-36195 qui est exploitée pour exécuter le ransomware Qlocker. D'ailleurs, il y a eu plusieurs failles critiques patchées par QNAP ces derniers jours : nous vous recommandons de réaliser l'installation des correctifs au plus vite.

En complément : Sécuriser son NAS QNAP

De nombreux ransomwares s'appuient sur des mécanismes complexes pour chiffrer les données, dans le but de les rendre efficaces et robustes. De la même manière, les rançons demandées sont généralement élevées, voire très élevées : de quelques dizaines de milliers de dollars à plusieurs dizaines de millions de dollars.

Qlocker quant à lui fonctionne différemment : pour chiffrer les données et les rendre inaccessibles, il s'appuie sur un outil que l'on connait tous : 7-Zip. Ensuite, le montant de la rançon est différent également : 0.01 Bitcoin, ce qui correspond à 500 euros environ. 

Ce montant faible se justifie par le fait que Qlocker s'attaque plutôt aux particuliers et aux PME qui s'appuient sur QNAP pour la gestion de leurs données. Concrètement, un particulier ne paiera jamais 10 000$ pour récupérer ses données, alors que pour 500$, même si on s'en passerait bien, on peut se laisser tenter.

Résultat : en seulement 5 jours, Qlocker a déjà rapporté plus de 260 000 dollars aux hackers qui sont derrière cette attaque. Compte tenu du montant de la rançon, on peut considérer qu'il y a environ 500 victimes qui ont pris la décision de payer la rançon.

Malheureusement, comme les utilisateurs paient la rançon, cela encourage les hackers à poursuivre cette campagne d'attaque. Il faut s'attendre à de nouvelles victimes dans les semaines à venir !

Pour la petite histoire, il y a eu une lueur d'espoir la semaine dernière quant à la possibilité de récupérer ses données gratuitement. Un chercheur en sécurité nommé Jack Cable a découvert un bug au sein du site qui sert à payer la rançon, ce qui permettait d'obtenir une clé de déchiffrement Qlocker sans payer. Quelques heures plus tard, les hackers ont corrigé ce bug, et donc, ce n'est malheureusement plus possible. Malgré tout, il a pu sauver de la galère 50 personnes !

If anyone's dealing with the QLocker QNAP NAS ransomware, feel free to DM me. I can help recover data. #qlocker @QNAP_nas

— Jack Cable (@jackhcable) April 22, 2021

<script async src="https://platform.twitter.com/widgets.js" charset="utf-8">

Source

The post QNAP – Qlocker : déjà 260 000 dollars de gains en 5 jours pour ce ransomware first appeared on IT-Connect.