Microsoft continue de dévoiler les fonctionnalités de Windows 11 et cette fois-ci nous allons parler du mode "Focus Session". Il a pour objectif de vous aider à vous concentrer pour être plus productif, tout en intégrant Spotify nativement.
Grâce à Focus Session, vous allez pouvoir vous concentrer sur votre travail : vous définissez une durée pour la session, ainsi qu'une tâche à réaliser obtenue à partir de Microsoft To Do, et il sera même possible de sélectionner de la musique à partir de Spotify. L'interface de Focus Session intègre directement Spotify, reste à savoir si Microsoft proposera ses propres playlists ou si l'utilisateur pourra retrouver son contenu, ce qui devrait être le cas pour rendre l'expérience plus personnelle.
Au sein de Windows 10, il y a déjà quelque chose de semblable avec le mode "Concentration" accessible à partir du menu "Centre de notifications" (en bas à droite). Avec Windows 11, Microsoft semble vouloir aller un peu plus loin. Ce qui est sûr, c'est qu'une fois la "Focus Session" activée, les notifications des applications seront coupées pour éviter de vous perturber.
Personnellement, j'aime bien utiliser le mode "Concentration" sur Windows 10 pour éviter d'être perturbé par des notifications telles que l'arrivée d'un e-mail, lorsque j'ai besoin de me concentrer sur une tâche spécifique. À voir ce que donnera le mode "Focus Session" dans la pratique, mais il pourrait me plaire !
Voici le tweet officiel pour annoncer cette nouveauté :
L'équipe de recherche des vulnérabilités dans Microsoft Edge a annoncé l'arrivée d'un nouveau mode nommé "Super Duper Secure" pour le navigateur de Microsoft, dans le but de renforcer la sécurité.
Lorsque le mode "Super Duper Secure" sera actif dans Edge, le compilateur JavaScript JIT (Just-In-Time) v8 sera désactivé. JIT permet la compilation du code à la volée, ce qui permet notamment d'améliorer les performances.
Grâce à cette modification, il devient possible d'activer des fonctions de sécurité supplémentaires au niveau de Windows : la technologie CET (Control-flow Enforcement Technology) d'Intel qui est une protection contre les exploits, l'ACG (Arbitrary Code Guard) et le CFG (Control Flow Guard).
Johnathan Norman, le responsable de l'équipe de recherche de Microsoft Edge, affirme que près de la moitié des vulnérabilités associées à JavaScript V8 sont liées au processus JIT. Un processus qu'il juge très complexe et difficile à appréhender. Désactiver JIT permet de réduire de façon considérable la surface d'attaque, ce qui n'est pas négligeable.
Le fait d'utiliser Edge sans JIT impacte les performances du navigateur et il y aurait même une baisse des performances de 58%. Néanmoins, cela dépend du type de contenu consulté à partir du navigateur. Pour le moment, les développeurs de Microsoft vont continuer d'améliorer ce mode pour réduire au maximum l'impact sur les performances.
Pour tester ce nouveau mode dès à présent, il est nécessaire d'installer une version Preview de Microsoft Edge. Ensuite, il faut activer le mode "Super Duper Secure" dans les options avancées, à cette adresse :
edge://flags/#edge-enable-super-duper-secure-mode
Je pense qu'une perte au niveau des performances est acceptable si cela reste raisonnable et que la sécurité est réellement renforcée.
Une nouvelle attaque connue sous le nom de PetitPotam fait parler d'elle ces derniers jours. Cette attaque exploite la méthode de relais NTLM et permet à un attaquant de voler des identifiants Windows, ce qui peut lui permettre de prendre le contrôle d'un domaine Active Directory.
Le mois dernier, le chercheur en sécurité français Lionel GILLES, alias Topotam, a découvert une nouvelle attaque qui cible les machines Windows. Baptisée PetitPotam, cette attaque permet de forcer une machine Windows à s'authentifier sur un serveur malveillant qui joue le rôle de relais NTLM, en s'appuyant sur le protocole Microsoft Encrypting File System Remote (EFSRPC) . Cette attaque fonctionne également sur les contrôleurs de domaine, ce qui la rend particulièrement dangereuse.
Le serveur NTLM relais va rediriger la requête d'authentification et jouer le rôle d'intermédiaire, ce qui lui permet de récupérer des informations d'authentification, et au final de réaliser un dump des identifiants et de prendre le contrôle du domaine Active Directory.
Vous êtes vulnérable à l'attaque PetitPotam si vous utilisez un serveur avec le rôle ADCS (Active Directory Certificate Services), qui permet d'avoir une autorité de certification d'entreprise, avec l'un des deux rôles suivants :
Certificate Authority Web Enrollment
Certificate Enrollment Web Service
Concrètement, l'attaque PetitPotam tire profit d'un serveur ADCS qui ne serait pas bien configuré pour vous protéger contre les attaques basées sur l'utilisation d'un serveur relais NTLM.
Microsoft a publié sur son site Internet des informations pour vous expliquer comment configurer le serveur IIS de votre serveur ADCS pour vous protéger. La méthode décrite par Microsoft consiste à activer des fonctions pour renforcer l'authentification, notamment l'EPA (Extended Protection for Authentication), et l'obligation d'utiliser des connexions HTTPS.
Plutôt que d'appliquer cette configuration proposée par Microsoft, des chercheurs en sécurité ont trouvé une autre méthode qui consiste à appliquer un filtre au niveau de la machine, via netsh. Le chercheur en sécurité Craig Kirby explique que ce filtre netsh rpc bloque l'accès à distance à l'API MS-EFSRPC.
De son côté, Benjamin Delpy, le créateur de Mimikatz, explique comment mettre en place ce filtre, voici les instructions à appliquer sur votre serveur ADCS.
1 - Créer un fichier nommé "block_efsr.txt" (ou autre) et insérer le contenu suivant :
2 - Enregistrer le fichier sur le Bureau de votre session
3 - Importer les règles netsh à partir du fichier créé précédemment :
netsh -f %userprofile%\desktop\block_efsr.txt
4 - Vérifier que les filtres sont bien importés avec la commande suivante :
netsh rpc filter show filter
Concrètement, voici le nom des deux filtres créés : c681d488-d850-11d0-8c52-00c04fd90f7e et df1941c5-fe89-4e79-bf10-463657acf44d. Grâce à eux, le vecteur d'attaque de PetitPotam est bloqué et le serveur relais NTLM malveillant ne pourra plus tromper vos machines.
Pour finir, je tiens à préciser que cette vulnérabilité affecte toutes les versions de Windows Server, y compris lorsque le serveur est installé en mode core.
Dans ce tutoriel, nous allons voir comment configurer Nginx pour cacher le numéro de version dans le header HTTP ou sur les pages d'erreurs générées par le serveur Web.
Lorsque l'on configure un serveur Web, que ce soit avec Nginx ou Apache, l'applicatif se montre un peu trop bavard dans sa configuration par défaut. Si l'on regarde les en-têtes HTTP (Header HTTP) ou que l'on génère une page d'erreur, on peut facilement obtenir le numéro de version du serveur Nginx. Une information importante si l'on se place dans la peau d'un attaquant : le numéro de version peut permettre de savoir si le serveur est à jour ou non, et s'il n'est pas à jour, cela permet de rechercher d'éventuelles failles de sécurité associée à la version installée.
Le numéro de version est récupérable avec une simple requête CURL ou en générant une erreur sur le site Web avec un navigateur. Par exemple :
Je pars du principe que votre serveur Nginx est déjà en place. Si besoin, référez-vous à ce tutoriel : Installation de Nginx
II. Nginx et la directive server_tokens
Tout va se jouer dans le fichier de configuration de Nginx, que je vous propose de modifier avec votre éditeur de texte préféré. Pour ma part, ce sera avec nano, ce qui donne :
sudo nano /etc/nginx/nginx.conf
Pour ne plus afficher la version de Nginx, il faut ajouter la directive server_tokens au sein du bloc "http{ }". Cette directive devra avoir la valeur "off". En fait, soit vous l'ajoutez vous-même, soit vous décommentez la ligne existante et prête à l'emploi (en retirant le caractère "#") :
server_tokens off;
En image, cela donne :
Pour afficher de nouveau le numéro de version, il suffit de commenter la ligne ou d'indiquer "on" comme valeur. Une fois que la modification est effectuée : sauvegardez et fermez le fichier.
Redémarrez le service Nginx :
sudo systemctl restart nginx
Ensuite, rendez-vous dans votre navigateur et accédez à une page qui génère une erreur. Et là, vous verrez que c'est simplement précisé "nginx" mais que le numéro de version n'est plus spécifique : c'est top !
Grâce à cette modification, on peut savoir que le serveur est sous Nginx mais on ne connaît pas le numéro de version.
Dans ce tutoriel, nous allons voir comment configurer son site en HTTPS avec un certificat SSL gratuit Let's Encrypt en utilisant un serveur Web Nginx.
Mettre en place un site Internet sur un serveur Web et le rendre accessible en HTTP, c'est bien, mais c'est insuffisant : pour un site en production, il est fortement recommandé d'utiliser un certificat SSL et le protocole HTTPS pour sécuriser les connexions. D'autant plus qu'avec Let's Encrypt, on peut obtenir un certificat gratuitement en quelques minutes.
Je pars du principe que votre serveur Nginx est déjà en place avec un site accessible en HTTP. Pour ma part, il s'agit du site www.it-connect.tech et je vais reprendre comme point de départ, la configuration du précédent tutoriel sur l'installation de Nginx.
II. Installation de Certbot pour Nginx
Commençons par mettre à jour le cache des paquets et à installer les deux paquets (et leurs dépendances) nécessaires à l'utilisation de Certbot sous Debian, avec un serveur Web Nginx. Pour rappel, Certbot est un outil qui sert à effectuer des demandes de certificat Let's Encrypt.
III. Let's Encrypt : demander un certificat SSL pour Nginx
Certbot étant installé sur notre machine, nous allons effectuer une demande de certificat. Pour cela, on va spécifier que l'on utilise un serveur Web sous Nginx (--nginx) et on précise aussi le nom du domaine (-d www.it-connect.tech). Voici la commande complète :
sudo certbot --nginx -d www.it-connect.tech
Le processus est relativement rapide, je vous invite à saisir votre adresse e-mail lorsque ce sera demandé (Enter email address) : un e-mail sera envoyé à cette adresse dans le cas où le certificat ne parvient pas à se renouveler automatiquement et qu'il arrive à expiration. C'est toujours bon à prendre comme information...!
Certbot - Générer un certificat SSL via Let's Encrypt pour Nginx
Il vous sera demandé si vous souhaitez rediriger automatiquement le trafic HTTP vers HTTPS : ce qui me semble une bonne idée. Dans ce cas, indiquez "2" et appuyez sur entrée. On peut voir également les chemins vers le certificat et la clé privée associée.
Si tout se passe bien, vous avez le droit à un joli "Congratulations !". Dans ce cas, le certificat est déjà installé sur votre site Web car Certbot s'est occupé de configurer le bloc Server correspondant. La classe, n'est-ce pas ?
Allons-voir quelles sont les modifications apportées par Certbot dans le fichier de configuration de notre site...
sudo cat /etc/nginx/sites-enabled/it-connect.tech
Voici le contenu du fichier avec les modifications principales en jaune :
Intégration du certificat Let's Encrypt dans la configuration de Nginx
Concrètement, Certbot a déclaré le port 443 comme port d'écoute, ce qui correspond au HTTPS, à la fois pour toutes les adresses IPv4 du serveur, mais aussi toutes les adresses IPv6.
listen [::]::443 ssl ipv6only=on;
listen 443 ssl;
Il a également ajouté les chemins vers le certificat SSL (ssl_certificate) et la clé privée (ssl_certificate_key) obtenus suite à la génération du certificat Let's Encrypt.
ssl_certificate /etc/letsencrypt/live/www.it-connect.tech/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/www.it-connect.tech/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
Le fichier de configuration options-ssl-nginx.conf (include...) est chargé également et il contient les paramètres SSL/TLS, notamment les protocoles actifs.
Comme nous avons demandé à rediriger les flux HTTP vers HTTP, le fichier de configuration contient une règle de redirection au niveau du groupe Server pour la partie HTTP (listen 80). En gros, si l'on accède à l'adresse www.it-connect.tech ($host = www.it-connect.tech), il y a une redirection de type 301 (c'est-à-dire permanente) qui est déclenchée vers la même adresse, mais en HTTPS://.
if ($host = www.it-connect.tech) {
return 301 https://$host$request_uri;
} # managed by Certbot
Note : ces différentes options seraient à intégrer dans le fichier manuellement dans le cas où l'on utilise un autre certificat que Let's Encrypt, où il faut réaliser l'intégration soi-même.
Maintenant que l'on en sait un peu plus sur les modifications apportées par Certbot, il est temps de tester : est-ce que l'accès HTTPS sur notre site fonctionne bien ?
IV. Vérifier le certificat SSL
Rendez-vous sur le site ! Non pas en HTTPS directement, mais en HTTP, ce sera l'occasion de vérifier que la redirection HTTP vers HTTPS fonctionne bien, tant qu'à faire !
Ensuite, un beau cadenas devrait s'afficher pour nous indiquer que la connexion est sécurisée. Si l'on regarde le détail du certificat, on peut voir qu'il est émis par Let's Encrypt. C'est tout bon !
V. HTTPS : renouvellement automatique du certificat SSL
Je ne l'ai pas encore précisé, mais un certificat Let's Encrypt a une durée de validité assez courte : 90 jours. Néanmoins, il ne faudra pas le renouveler manuellement tous les 90 jours puisque Certbot va s'en occuper, tout seul comme un grand. Il a déjà fait le nécessaire sur notre machine en créant une tâche planifiée (cron).
Il suffit de regarder le contenu du fichier suivant pour se rassurer :
sudo nano /etc/cron.d/certbot
La tâche planifiée va s'exécuter de façon à renouveler le certificat avant qu'il expire.
Tâche planifiée pour renouveler le certificat SSL
Si vous souhaitez réaliser un essai, vous pouvez exécuter un "--dry-run" pour faire une simulation de renouvellement. Tout simplement, voici la commande à exécuter :
sudo certbot renew --dry-run
Vous devriez obtenir une sortie similaire à celle-ci :
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
** DRY RUN: simulating 'certbot renew' close to cert expiry
** (The test certificates below have not been saved.)
Congratulations, all renewals succeeded. The following certs have been renewed:
/etc/letsencrypt/live/www.it-connect.tech/fullchain.pem (success)
** DRY RUN: simulating 'certbot renew' close to cert expiry
** (The test certificates above have not been saved.)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Le message "Congratulations, all renewals succeeded." est rassurant puisqu'il indique que le certificat aurait été renouvelé correctement si cela avait été nécessaire. Maintenant, la tâche planifiée va s'occuper de gérer cette opération à notre place. En cas de soucis, souvenez-vous qu'un e-mail sera envoyé sur l'adresse précisée lors de la création du certificat.
Voilà, votre site Web sous Nginx bénéficie d'un certificat SSL Let's Encrypt et il est accessible en HTTPS.
