PROJET AUTOBLOG


IT-Connect

Site original : IT-Connect

⇐ retour index

Linux : configuration d’un espace de stockage sécurisé avec SFTP

mercredi 29 septembre 2021 à 10:00

I. Présentation

Dans ce tutoriel, je vais vous expliquer comment mettre en place un système de stockage de fichier sécurisé par l’isolation de chaque utilisateur et le chiffrement des connexions. Autrement dit, nous allons permettre à différents utilisateurs de bénéficier d’un espace de stockage dédié et isolé sur notre serveur, au travers d’une connexion SFTP.

SFTP (pour Secure File Transfert Protocol) est un protocole de transfert de fichier sécurisé qui utilise SSH. Un des gros avantages de FTP est qu’il est simple à déployer et à utiliser ; à l’inverse, il est par nature non sécurisé dans le sens où tout passe en clair sur le réseau, y compris les mots de passe !

SFTP quant à lui, assure un chiffrement dès l’authentification, il permet ainsi d’assurer la sécurité des accès et des données qui transitent. En revanche, il nécessite plus de travail de mise en place et bien que nativement prit en charge dans Windows 10 depuis l’ajout du support OpenSSH, il est plus aisé d’utiliser un logiciel tel que WinScp ou Filezilla. Pour la sauvegarde, vous pouvez utiliser FullSync qui gère les connexions SFTP.

Pour ce tuto, j’ai utilisé un serveur Rocky Linux en installation minimale (pas besoin de plus) et le client OpenSSH de Windows pour la connexion SSH, mais vous pouvez utiliser un logiciel tiers comme PuTTY par exemple.

Bien entendu, ce tuto est reproductible sur CentOS, AlmaLinux ou Oracle Linux tel quel. Pour les utilisateurs de Debian, des notes viennent indiquer les changements de commandes et/ou de chemins de fichiers.

II. Préparation du serveur

A. Configuration du réseau

La première chose à faire bien entendu est d’adresser notre serveur en statique. Comme il s’agit d’un serveur de fichier, il n’est pas concevable de le laisser en dynamique au risque de voir son IP changer !

La gestion des adresses IP sur Linux varie en fonction de la distribution. Par chance sur CentOS, il existe un utilitaire qui permet de faire cela en un rien de temps : NetworkManager TUI

Il suffit donc de taper la commande :

[root@sftp ~]# nmtui

Un menu nous permet alors de définir notre adresse IP en statique. Dans un premier temps, sélectionnez « Modifier une connexion »

Puis de sélectionner l’interface correspondante (pour moi c’est facile, il n’y en a qu’une, mais attention si vous en avez plusieurs) et choisir « Modifier… »

Dans la fenêtre suivante, il faut vous rendre dans « CONFIGURATION IPv4 » pour le changer en « Manuel » puis sélectionner « Afficher ».

Ici, mon réseau étant en 192.168.1.0/24, je choisis l’adresse 192.168.1.100. Bien entendu, vous faites comme vous le souhaitez tant que votre adresse reste dans votre plage.

Au passage, vérifiez bien que la case « Connecter automatiquement » est bien cochée, cela vous évitera des déconvenues…

Note : les utilisateurs de Debian n’auront pas la chance d’avoir ce menu. Pour ceux-ci ou les aficionados de la ligne de commande, je vous laisse suivre les excellents tutos sur ifconfig ou iproute2 en fonction de vos systèmes.

Une fois tout ceci validé, un petit redémarrage des services réseau pour la prise en compte des modifications :

[root@sftp ~]#systemctl restart network
# Sous Debian : 
systemctl restart networking

Et pour valider le changement, on va afficher le résultat de la commande ip a.

Notre serveur est bien adressé, on peut passer à la suite.

B. Vérification de la présence du service SSH

Toutes les distributions Linux viennent avec un client SSH ; la plupart avec un serveur SSH, mais celui-ci n’est pas forcément installé par défaut. Ou encore, il m’arrive également de sauter l’étape correspondante lors de l’installation donc on va déjà vérifier qu’il est bien installé :

[root@sftp ~]#systemctl status sshd

Voici le retour pour moi :

Le service est bien installé et même actif.

Si vous avez un retour de ce genre :

Unit sshd.service could not be found

Pas de chance, c’est que le service n’est pas présent ! Mais pas de panique, on peut l’installer à tout moment grâce à la commande magique :

[root@sftp ~]#yum install -y sshd

Yum est le gestionnaire de paquet pour toutes les distributions dérivées de Red Hat comme le son Rocky, Alma et CentOS, cette commande appelle donc l’installation d’OpenSSH ; l’option « -y » permet d’éviter le prompt de validation.

Note : les utilisateurs de Debian avertis auront ici compris qu’il faut utiliser le gestionnaire de paquet Debian « apt ». La commande devient donc apt-get install -y sshd

C. Mise à jour du système

Donc avant tout, on va déjà se connecter, sur mon PC Windows, j’ouvre une fenêtre PowerShell et utilise la commande suivante :

ssh florian@192.168.1.100

Si la fonctionnalité SSH n'est pas installée sur votre machine Windows, suivez ce tutoriel : le client SSH sous Windows.

Où « florian» est le nom d’utilisateur (à remplacer bien entendu par le vôtre). Une fois connecté, une petite mise à jour, ça ne fait pas de mal surtout maintenant que le serveur n’est pas encore entré en production. Mais pour cela, il faut se connecter en root avec la commande « su ».

[florian@sftp ~]$ su
Mot de passe :

Au passage, vous pouvez constater que ma machine s’appelle « sftp », bien entendu, cela n’a aucune influence sur la suite du programme, vous pouvez la nommer comme vous voulez.

Une fois ceci fait, tapez la commande « yum update » :

[florian@sftp ~]$ su
Mot de passe :
[root@sftp florian]# yum update

Dépendances résolues.

Là je n’en ai pas beaucoup, mais cela peut être différent chez vous, donc prévoir un petit temps pour compléter toutes les mises à jour.

Note : les systèmes Debian nécessitent deux étapes pour faire une mise à jour de paquets. D’abord la commande apt-get update pour la mise à jour des dépôts puis apt-get upgrade pour la mise à jour des paquets

III. Mise en place du service

Ce qu’il y a de bien avec SFTP, c’est qu’on peut utiliser ce qu’on appelle une prison chroot (chroot jail). L’appel système « chroot » permet de changer le répertoire racine d’un processus ou d’un utilisateur. On parle de prison, car, lorsqu’il est utilisé, l’utilisateur (ou le processus) à l’impression d’être à la racine du système et donc de n’avoir aucun répertoire au-dessus de celui dans lequel il se trouve.

Cela a ses avantages, car il permet, dans un contexte multi-utilisateur, de ne faire apparaître à l’utilisateur uniquement SES répertoires, il ne pourra pas afficher ceux du voisin. Autre avantage, même si un utilisateur se fait piquer son mot de passe, le voleur n’ira pas bien loin et ne pourra corrompre la totalité du serveur.

On va ajouter à cela l’impossibilité pour un utilisateur d’ouvrir un shell sur le serveur. De base, SFTP est une « variante » de SSH donc en théorie, l’utilisateur pourra ouvrir une ligne de commande, mais ça, on ne veut pas !

Vu qu’on va pas mal manipuler les fichiers de configuration, je vais vous éviter l’utilisation de vi, j’aimerais que ce tuto soit reproductible par le plus grand nombre. On va donc installer nano, pour cela, on se connecte en root puis on tape la commande :

[root@sftp ~]#yum install -y nano

Pour Debian, l’éditeur nano est présent nativement. Pour vous en assurer, vous pouvez utiliser la commande « nano --version ».

Une fois l’installation terminée, l’éditeur de texte est prêt à l’emploi.

A. Empêcher la connexion de root via SSH

Ici, les utilisateurs Debian sont chanceux, l’implémentation de sshd dans cette distribution empêche d’office la connexion de root.

Il est indispensable de ne pas autoriser la connexion de cet utilisateur en SSH. Il faudra alors se connecter avec un utilisateur « lambda » et utiliser le compte root seulement quand nécessaire. Pour mettre cela d’aplomb, il faut aller modifier le fichier /etc/ssh/sshd_config avec nano.

[root@sftp ~]#nano /etc/ssh/sshd_config

Ce qui nous intéresse, ce sont ces lignes :

#Authentication:
#LoginGraceTime 2m
PermitRootLogin yes

On va tout simplement supprimer le « yes » de la dernière ligne pour le transformer en « no ». Une fois fait, on enregistre (Ctrl+o) et on quitte (Ctrl+x). Pour que cela soit pris en compte, on redémarre SSH :

[root@sftp ~]#systemctl restart sshd

B. Configuration SFTP

La première étape est de créer un groupe d’utilisateurs qui pourront se connecter en SFTP. Il sera ainsi plus facile de les gérer le cas échéant.

[root@sftp ~]#groupadd sftp

Encore une fois, le nom « sftp » est celui que j’ai choisi pour mon groupe, vous pouvez l’appeler comme vous voulez.

La seconde étape consiste à créer un répertoire qui va servir de « home » aux utilisateurs sftp :

[root@sftp ~]#mkdir /sftp

Je choisis de le mettre à la racine « / » pour plus de facilité, notamment pour les scripts de sauvegardes. Bien entendu, vous pouvez le mettre où vous le souhaitez.

Là encore, vous le nommez comme vous le souhaitez. L’important est de lui donner les bons droits. En effet, il est IMPÉRATIF de donner la propriété à root ainsi que les droits d’écriture. Rappelez-vous il s’agit de faire croire à l’utilisateur qu’il est à la racine, dont seul root à les droits d’écriture. SI on tape la commande « ls -al / », on constate ceci :

drwxr-xr-x. 2 root root 6 20 juin 03:46 sftp

Ce n’est pas bon, car seul root doit avoir les droits complets (lecture, écriture, exécution r-w-x) or ici, les autres utilisateurs ont également les droits d’exécution. Pour modifier cela, il faut taper la commande :

[root@sftp ~]# chmod 750 /sftp

Les droits sous Linux pouvant être représenté par des chiffres (octal):

Et chaque bloc représente un utilisateur (propriétaire-groupe-autres). Donc à partir de là, 750 octroie les droits complets au propriétaire, lecture et exécution au groupe et rien aux autres.

Maintenant que la base est là, on va retourner dans la modification du fichier sshd_config :

[root@sftp ~]#nano /etc/ssh/sshd_config

Ce qui nous intéresse ici, ce sont les dernières lignes :

override default of no subsystems
Subsystem sftp /usr/libexec/openssh/sftp-server
 
Example of overriding settings on a per-user basis
Match User anoncvs
X11Forwarding no
AllowTcpForwarding no
PermitTTY no
ForceCommand cvs server

Il est nécessaire de les modifier de la sorte (les explications viennent après) :

override default of no subsystems
Subsystem sftp internal-sftp
 
Example of overriding settings on a per-user basis
Match Group sftp
X11Forwarding no
AllowTcpForwarding no
PermitTTY no
PermitTunnel no
ForceCommand internal-sftp -d /upload
ChrootDirectory /sftp/%u

Bien, décortiquons tout ça :

- Subsystem sftp internal-sftp va indiquer au démon sshd d’utiliser les commandes intégrées

- Match Group sftp va appliquer les lignes qui suivent à tous les utilisateurs faisant partie du groupe « sftp »

- X11Forwarding no va interdire la transmission de l’affichage entre le serveur et le client (ici nous n’avons pas d’interface graphique, mais il vaut mieux l’activer si d’aventure on en rajoute une)

- AllowTcpForwarding no va interdire les redirections TCP

- PermitTTY no va interdire l’utilisation du shell

- PermitTunnel no va interdire l’utilisation des commandes SSH pour créer des tunnels chiffrés

- ForceCommand internal-sftp va obliger les utilisateurs à n’utiliser QUE les commandes SFTP, l’option « -d /upload » va spécifier le répertoire dans lequel l’utilisateur arrive au moment de la connexion, ceci pour éviter qu’il n’arrive à sa racine, car il n’aura pas les droits d’écriture (voir plus bas)

- ChrootDirectory /sftp/%u va indiquer au démon que les utilisateurs doivent croire que la racine est /sftp/nomdelutilisateur

Il ne nous reste qu’à enregistrer et fermer, puis redémarrer sshd.

IV. Création des utilisateurs

On va créer maintenant notre premier utilisateur « john» avec une seule ligne de commande :

[root@sftp ~]#useradd -s /usr/bin/false -d /sftp/john -G sftp john

- L’option « -s » spécifie le shell à utiliser, on ne veut pas qu’il en utilise donc on lui indique un « faux » shell (en fait, c’est plutôt une commande qui ne fait rien et se termine avec un code d’erreur)

- L’option « -d » indique quel répertoire sera celui de l’utilisateur

- L’option -G ajoute l’utilisateur au groupe (ici sftp)

N’oubliez pas de lui affecter un mot de passe :

[root@sftp ~]#passwd john

Attention, par défaut, le répertoire « john » aura des permissions uniquement pour l’utilisateur john (et root bien entendu). Comme indiqué plus haut, pour que SFTP puisse fonctionner, il est obligatoire d’avoir des droits réglés sur 750 avec root en tant que propriétaire.

Il faut donc modifier le propriétaire du dossier. J’en profite pour déclarer « sftp » comme groupe propriétaire également et modifie les droits :

[root@sftp ~]#chown root:sftp /sftp/john
[root@sftp ~]#chmod 750 /sftp/john

On ne peut pas s’arrêter ici, car l’utilisateur « john » pourra bien se connecter, mais en aucun cas uploader quoi que ce soit. Il faut donc lui créer un répertoire dans lequel il pourra à loisir uploader des fichiers, créer d’autres répertoires, etc.

Rappelez-vous, lors de la configuration du service, on a spécifié  « ForceCommand internal-sftp -d /upload » donc le répertoire qui sera utilisé par l’utilisateur doit s’appeler « upload ».

[root@sftp ~]#mkdir /sftp/john/upload
[root@sftp ~]#chown john:john /sftp/john/upload
[root@sftp ~]#chmod 750 /sftp/john/upload

V. Tester le bon fonctionnement

Pour le test, j’utilise WinSCP que j’aime beaucoup, mais vous pouvez utiliser Filezilla sans problème. Pour rappel, Windows 10 permet l’utilisation de sftp nativement, mais en ligne de commande, WinSCP ou FileZilla ont l’avantage de représenter l’arborescence à la manière d’un Explorer ce qui facilite grandement la manipulation de fichiers et répertoires.

Il est fort probable qu’a la première connexion, vous ayez un message de ce type. Normal, le serveur est inconnu, donc le logiciel ne peut comparer sa clé à une autre en mémoire. Cliquer sur « Oui » pour continuer le processus de connexion.

Comme promis, nous arrivons immédiatement dans le répertoire « upload » où l’utilisateur a les droits d’écriture (répertoire courant en haut à gauche) :

Si on remonte d’un cran, on arrive à ce résultat :

Vous constaterez qu’il est bien indiqué « racine » en haut à gauche en guise de répertoire actuel, alors que nous savons bien que c’est faux ! D’ailleurs, si vous essayez de remonter dans l’arborescence, vous ne pourrez pas.

Comme annoncé également, il sera impossible de créer ou uploader quoi que ce soit dans le répertoire courant, mais dans « upload » pas de soucis, notre utilisateur pourra faire ce qu’il veut.

Et qu’en est-il de la connexion par SSH ?

ssh john@192.168.1.100
john@192.168.1.100's password:

PTY allocation request failed on channel 0
This service allows sftp connections only.
Connection to 192.168.1.100 closed.

Le message est on ne peut plus clair, seules les connexions et commandes sftp sont autorisées pour cet utilisateur. En revanche, pas de soucis pour mon utilisateur « florian » qui lui peut encore se connecter.

VI. Montage automatique du répertoire SFTP

Pour une utilisation ponctuelle ou une cible de sauvegarde, les étapes ci-dessus suffisent largement. En revanche, si on veut utiliser le répertoire sftp comme lecteur réseau par exemple, il est nécessaire de « monter » ce répertoire dans le système de fichier actuel pour l’utiliser comme s’il était directement attaché à notre machine.

Pour cela, il existe SSHFS, disponible sur toutes les distributions Linux et même sur Windows !

Note : je ne préconise pas de montage permanent ni sous Linux ni sous Windows. La création d’un tel serveur de fichier est à des fins de sécurité, or un montage permanent va à l’encontre de ce principe, surtout si l’utilisateur n’as pas de mot de passe de session par exemple.

A. Utilisation de SSHFS sous Linux

Retrouvez notre tutoriel dédié à SSHFS à cette adresse : Tutoriel SSHFS - Sinon, en résumé voici les étapes à suivre.

Pour tous ceux équipés d’une distribution desktop, rien de plus simple, il suffit d’installer le paquet sshfs sur leur machine à l’aide de la commande :

# Sur Debian
apt install -y sshfs

# Sur CentOS et dérivés
yum install -y sshfs

Une fois l’installation faite, il faut créer un répertoire qui « accueillera » notre montage, ici, je décide que ce sera un dossier nommé sftp que je crée dans mon répertoire user :

mkdir /home/flo/sftp

Maintenant, il ne me reste plus qu’a utiliser la commande qui va bien :

sshfs [utilisateur@]serveur:[dossier distant] point_de_montage [options]

Soit dans mon cas :

sshfs john@192.168.1.100:/upload /home/flo/sftp
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
john@192.168.1.100's password:

Une fois le mot de passe rentré, nous pouvons naviguer dans notre répertoire en local.

Note : n’oubliez pas que pour john, son répertoire est à la racine d’où le chemin « /upload » dans la commande sshfs. Si vous indiquez le VRAI chemin (/sftp/john/upload), cela ne fonctionnera pas !

Il est possible de monter ce répertoire en permanence via le fichier fstab en ajoutant la ligne :

john@192.168.1.100:/upload /home/flo/sftp fuse.sshfs defaults 0 0

La commande est identique à deux exceptions prêtes :

Note : si vous voulez vraiment faire un montage automatique, il sera obligatoire de vous authentifier par clé. Le montage par fstab via une authentification par mot de passe n’est pas possible.

B. Utilisation de SSHFS sous Windows

SSHFS est également disponible sur Windows, un grand merci à Bill Zissimopoulos (billziss-gh) pour les deux installateurs disponibles sur GitHub qu’il faudra d’ailleurs récupérer :

Une fois l’installation de ces deux paquets, l’ajout du lecteur réseau est aussi simple qu’un partage SMB directement dans l’explorateur :

\\sshfs\john@192.168.1.100

Ici, pas besoin de spécifier de chemin, comme pour les connexions manuelles, l’utilisateur sera immédiatement « propulsé » dans son dossier « upload »

Si tout est OK, vous aurez la demande du mot de passe :

Et le répertoire est monté. Je vous invite grandement à lire le manuel de SSHFS-Win pour voir toutes les possibilités offertes par ce merveilleux utilitaire.

VII. Conclusion

Notre serveur est prêt, vous pouvez maintenant créer d’autres utilisateurs selon le modèle de john et constater qu’ils ne peuvent connaitre l’existence des autres, et encore moins accéder à leurs dossiers.

Nous avons donc vu comment mettre en place un serveur de fichier sécurisé, avec chiffrement des données échangées et isolation des utilisateurs par « enfermement » dans une racine virtuelle.

Avec les possibilités de montage sur Linux ou Windows, cela offre un réel plus, notamment si vous avez plusieurs « clients » que vous souhaitez leur offrir un espace personnel sécurisé pour leurs fichiers sensibles ou encore leurs sauvegardes.

The post Linux : configuration d’un espace de stockage sécurisé avec SFTP first appeared on IT-Connect.

WAPT Enterprise 2.1 et WAPT Discovery : quelles sont les nouveautés ?

mercredi 29 septembre 2021 à 09:09

Pour ce quatrième trimestre 2021, l'éditeur Tranquil IT nous réserve plusieurs nouveautés, avec d'une part la sortie de WAPT Enterprise 2.1 et d'autre part le lancement de WAPT Discovery. Faisons le point sur les changements à venir.

Avant d'aller plus loin, un petit rappel : qu'est-ce que WAPT ? Il s'agit d'une solution française, certifiée par l'ANSSI, qui a pour objectif de gérer le cycle de vie des logiciels sur votre parc informatique, de l'installation, à la configuration, aux mises à jour et jusqu'à la désinstallation.

En mars dernier, Tranquil IT a mis en ligne WAPT 2.0, une nouvelle version majeure de son logiciel. L'occasion de passer sur Python 3 (puisque Python 2.7 n'est plus supporté), mais aussi d'intégrer l'interconnexion avec GLPI et une gestion avancée des droits d'accès.

Plus récemment, je vous rappelle qu'une faille de type élévation de privilèges a été découverte et qu'un correctif est déjà disponible. Si vous utilisez déjà WAPT et que vous souhaitez bénéficier du correctif, vous devez installer la version WAPT Enterprise 2.0.0.9450 ou WAPT Community 1.8.2.7373.

Les nouveautés WAPT Enterprise 2.1

Tout d'abord, WAPT Enterprise 2.1 va bénéficier d'une console un peu plus moderne et plus agréable à utiliser, grâce à l'intégration de nouveautés pour que la console soit plus pratique au quotidien.

Au-delà de quelques nouveautés esthétiques, comme le remplacement de toutes les icônes de la console ou le réagencement de certains onglets, les développeurs ont travaillé sur quelques fonctionnalités, parmi lesquelles :

En complément, un nouvel onglet nommé "Développement de paquets WAPT" est disponible en version preview, dans l'objectif de remplacer, à terme, l'éditeur de paquet PyScripter. Pour le moment, certaines fonctionnalités comme le debuging ou l'autocomplétion ne sont pas disponibles.

Enfin, il y a une nouveauté qui me semble particulièrement intéressante, c'est la prise en charge de l'authentification Kerberos. Grâce à cette nouveauté, si vous souhaitez vous connecter à la console ou à WAPT Self Service, il n'est plus nécessaire de se réauthentifier (si l'on est déjà connecté sur Windows avec sa session du domaine).

Voici un aperçu de WAPT Enterprise 2.1.

WAPT Discovery : la version gratuite et limitée à 300 postes

Tranquil IT a décidé d'arrêter de contribuer au développement de la version WAPT Community au profit d'une nouvelle version gratuite, mais non libre : WAPT Discovery. La bonne nouvelle, c'est que cette version gratuite sera basée sur WAPT Enterprise et donc sur Python 3. Elle bénéficiera également des dernières optimisations de la version 2.1 WAPT Enterprise.

Au niveau des limitations de cette version gratuite, il faut savoir qu'elle sera limitée à la gestion de 300 postes et qu'elle ne supportera pas macOS et Windows XP.

Si vous l'attendez avec impatience, sachez que WAPT Discovery sera disponible courant octobre !

Le planning de la fin d'année

En complément, Tranquil IT prépare un nouveau forum pour faciliter les échanges liés à WAPT Discovery et WAPT Enterprise, tandis que le forum actuel passera en lecture seule. Voici un résumé des changements à venir :

Avec cette phase de transition qui est enclenchée, la fin d'année s'annonce chargée chez Tranquil IT !

Si vous souhaitez découvrir WAPT, suivez ce lien : Découvrir WAPT

Source : communiqué de presse

The post WAPT Enterprise 2.1 et WAPT Discovery : quelles sont les nouveautés ? first appeared on IT-Connect.

Windows 11 : le Microsoft Store est ouvert aux magasins d’applications tiers

mercredi 29 septembre 2021 à 08:03

Microsoft vient d'assouplir la politique du Microsoft Store de Windows 11 pour permettre l'intégration de magasins d'applications tiers, en plus des applications en elle-même.

Au-delà de la refonte graphique, le Microsoft Store de Windows 11 va bel et bien s'ouvrir un peu plus, et il sera prêt pour le 5 octobre prochain, date à laquelle sortira Windows 11. D'ailleurs, Microsoft précise que dans les prochains mois, ce nouveau Microsoft Store sera également disponible sur Windows 10.

Dans ce nouveau communiqué, Microsoft affirme avoir reçu des centaines de demandes d'enregistrement d'applications depuis le mois de juin. Parmi ces applications, nous retrouvons Discord, Zoom, VLC, TeamViewer, Adobe Acrobat DC, LibreOffice ou encore Visual Studio Code. Dans le même temps, de nouveaux navigateurs viennent d'intégrer le Microsoft Store : Opera et Yandex Browser.

Avec Windows 11 et ce nouveau magasin d'applications, la firme de Redmond veut mettre en place "un magasin ouvert pour une plateforme ouverte". Pour s'ouvrir aux autres et les inciter à venir s'installer dans le Microsoft Store, Microsoft a allégé sa politique. Cela va permettre aux utilisateurs de télécharger directement le magasin d'Epic Games Store et le magasin d'Amazon, à partir du Microsoft Store. Nous verrons par la suite si d'autres magasins tiers viennent s'ajouter à cette liste.

Pour la partie Android, l'Amazon AppStore sera lié au Microsoft Store car si vous recherchez une application Android pour l'installer sur Windows 11, le Store de Windows s'appuiera sur celui d'Amazon.

Source

The post Windows 11 : le Microsoft Store est ouvert aux magasins d’applications tiers first appeared on IT-Connect.

Ce nouveau module Exchange atténue automatiquement les failles critiques

mercredi 29 septembre 2021 à 07:33

Depuis plusieurs mois, c'est compliqué pour Microsoft Exchange d'un point de vue la sécurité à cause, notamment, des vulnérabilités ProxyShell et ProxyLogon. Pour aider ses clients, Microsoft a intégré un nouveau module à Exchange qui mettra en place automatiquement les mesures d'atténuation lorsqu'une nouvelle faille de sécurité est dévoilée.

Ce nouveau composant se nomme "Microsoft Exchange Emergency Mitigation" (EM) et il s'appuie sur l'outil Microsoft Exchange On-premises Mitigation Tool (EOMT) dévoilé en mars dernier pour aider les utilisateurs à se protéger contre les failles ProxyLogon.

Microsoft Exchange Emergency Mitigation va permettre d'appliquer sur votre serveur de messagerie les mesures d'atténuation, de protection, lorsqu'une nouvelle faille critique voit le jour. L'idée n'est pas de vous protéger définitivement, mais temporairement, en attendant que vous ayez le temps d'installer le correctif de sécurité. Cela est valable aussi quand Microsoft n'a pas encore sorti le correctif, afin de vous protéger. La firme de Redmond veut laisser un peu plus de temps aux administrateurs, grâce à ce nouveau composant Exchange.

Le composant EM peut appliquer trois types d'atténuation :

Reste à voir quels seront les effets de bords lorsque le service décidera de stopper un service pour vous protéger... Microsoft précise bien que cela peut réduire les fonctionnalités de votre serveur Exchange, donc qu'une atténuation sera mise en place seulement en cas de détection d'une faille critique avec un risque élevé.

Sachez tout de même qu'Exchange EM peut être désactivé et qu'en aucun cas il ne remplacera l'installation des mises à jour de sécurité. Pour le désactiver, vous pouvez utiliser une commande PowerShell comme l'explique Microsoft dans sa documentation. De la même manière, PowerShell sera utile pour lister les atténuations actives sur votre ou vos serveurs Exchange :

Get-ExchangeServer | fl name, MitigationsApplied

Pour bénéficier de Microsoft Exchange Emergency Mitigation, vous devez utiliser Exchange Server 2016 ou Exchange Server 2019, et avoir installé le patch cumulatif (CU) de Septembre 2021.

Source

The post Ce nouveau module Exchange atténue automatiquement les failles critiques first appeared on IT-Connect.

VMware vCenter – CVE-2021-22005 : un exploit circule sur le Web !

mardi 28 septembre 2021 à 17:44

Je crois qu'il est temps d'en remettre une couche au sujet de la faille de sécurité critique qui touche les serveurs VMware vCenter en version 6.7 et 7.0 : un exploit prêt à l'emploi circule sur le Web, ce qui facilite grandement les attaques !

Comme je l'expliquais dans un précédent article au sujet de cette vulnérabilité CVE-2021-22005, elle peut être exploitée par quelqu'un qui est capable de contacter le serveur vCenter sur le réseau (port 443), peu importe la configuration qui est en place sur le serveur vCenter, et sans être authentifié.

Quant à l'exploit prêt à l'emploi et qui circule sur Internet, il permet d'exploiter cette vulnérabilité et de mettre en place un reverse shell sur le serveur distant, ce qui n'était pas le cas avec l'exploit initial. De quoi permettre l'exécution de code arbitraire, au bon vouloir de l'attaquant.

Initialement, la vulnérabilité touchait le service Analytics de vCenter, mais suite aux informations publiées par un dénommé WVU, il serait possible de passer par le composant Customer Experience Improvement Program, qui est actif par défaut. On pourrait presque parler de deux failles de sécurité différentes, comme le suggère l'analyste du CERT/CC, Will Dormann.

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

Désormais, des groupes de hackers ont pu construire un code d'exploit fonctionnel et prêt à l'emploi pour compromettre facilement les serveurs vCenter, à partir des informations publiées par le chercheur Jang.

Retenez que, n'importe qui capable de joindre un serveur vCenter non patché, peut le compromettre à cause de cette faille de sécurité. Quand on sait qu'il y a des serveurs vCenter accessibles sur une adresse IP publique, voire même indexés dans Google, ce n'est pas rassurant pour les entreprises concernées.

Pour protéger vos serveurs VMware vCenter, vous devez viser les versions suivantes :

Source

The post VMware vCenter – CVE-2021-22005 : un exploit circule sur le Web ! first appeared on IT-Connect.