FreshRSS 
Abonnez-vous à notre chaîne YouTube pour ne manquer aucune vidéo !
L'article Windows 11 : quelles sont les nouveautés présentes sur la version bêta ? est apparu en premier sur Numerama.
Connexion
Abonnez-vous à notre chaîne YouTube pour ne manquer aucune vidéo !
L'article Windows 11 : quelles sont les nouveautés présentes sur la version bêta ? est apparu en premier sur Numerama.
Derrière l’acronyme DSI se cache la Direction du Système d’Information, une pièce maîtresse dans l'activité d'une entreprise dont l'objectif principal est de définir et piloter la stratégie IT. Notamment, choisir les bons outils et exploiter de manière efficiente ces outils. Ce poste indispensable dans les grandes entreprises n’est pourtant pas une évidence dans certaines PME. Dans certaines entreprises, cette notion de DSI n’existe pas et peut amener à se poser la question suivante : doit-on externaliser sa DSI pour assurer cette fonction ?
Le DSI doit gérer le système d’information dans son ensemble. Il a une vue transverse entre le système, le réseau, les applicatifs et les différents métiers de l’entreprise. Le DSI doit conseiller sa direction et les responsables des autres services pour prendre les bonnes orientations numériques, choisir les bons outils, et ensuite il doit s’assurer de l’accompagnement des utilisateurs. Pour la partie opérationnelle, il s’appuie sur une ou plusieurs personnes, en fonction de la taille de l’entreprise : ensemble, ils constituent le service informatique.
Par DSI externalisée, on entend s'appuyer sur un prestataire. Ce dernier vous proposera une prestation de DSI à temps partagé qui peut s’accompagner également par une prestation d’infogérance.
Premier constat : toutes les entreprises n’ont pas besoin d’un DSI à temps plein : la taille de l’entreprise ne le nécessite pas forcément et le volume de tâches n’est pas suffisant. Dans ce cas, il y a plusieurs options : laisser vacante la place de DSI (mauvaise idée), embaucher un administrateur système et réseau qui assurera également cette fonction de DSI, ou alors opter pour l'externalisation de la DSI. Ces dernières années, la DSI externalisé pour les PME est une tendance qui se confirme et qui est en constante progression.
Que l’infrastructure soit on-premise c’est-à-dire dans les locaux de l’entreprise, dans le Cloud ou en mode hybride, la fonction de DSI doit exister. Avec l'augmentation des attaques informatiques et les questions liées à la cybersécurité, la DSI est d'autant plus importante puisqu'elle va permettre de définir une stratégie vis-à-vis de cette problématique. Face à une telle problématique, il n'est pas question de rester réactif, mais il faut bien être proactif et prendre le taureau par les cornes, comme on dit.
Personnellement, je trouve que l'externalisation de la DSI est intéressante, car elle permet de mutualiser les expériences et de partager l'expertise. Un DSI à temps partagé interviendra auprès de plusieurs sociétés. De cette façon, il pourra accumuler de l'expérience sur des sujets divers et variés, ce qui en profitera directement à ses clients. Avec la DSI externalisée, il y a indirectement une expérience mutualisée qui permet de gagner en productivité.
Avec l’évolution des technologies, des pratiques et de la société, l’informatique est devenu incontournable même pour les PME : faire appel à un DSI à temps partagé permet à l’entreprise d’assurer la gestion de son SI tout en maîtrisant ses coûts. Cette ressource externe va permettre d'apporter son expertise, d’assurer une veille sur le SI de votre entreprise et de rester proactif : indispensable pour la sécurité de votre système d’information comme je le disais.
La fonction de DSI est associée à un salaire relativement élevé et toutes les entreprises ne peuvent pas se permettre d'embaucher un DSI à temps plein. C'est le nerf de la guerre, vous allez me dire... Grâce à l'externalisation de cette fonction, cela permet d'avoir en quelque sorte un DSI à la demande avec un contrat qui peut évoluer dans le temps avec le prestataire. Par ailleurs, et c'est très important, cela permet d'avoir un expert capable d'assurer cette fonction de DSI sans laisser la fonction vacante.
Externaliser sa DSI permet d'apporter une certaine maîtrise de ses coûts, donc c'est un levier intéressant pour optimiser ses dépenses tout en assurant une présence à ce poste clé.
L'externalisation de la DSI ne doit pas être systématique et perçue comme une solution miracle. Cela me semble pertinent principalement pour les PME où il n'est pas justifié d'embaucher une personne à temps plein.
Si la demande est trop forte au sein de l'entreprise, ce sera tout à fait cohérent d'embaucher un DSI à temps plein. Le fait d'intégrer la DSI permettra aussi de construire une équipe complète pour le service informatique et d'avoir un chef d'orchestre présent au quotidien.
Il faut trouver le juste milieu entre les coûts et les besoins réels de votre entreprise : où en est mon système d'information aujourd'hui ? Quelle est la charge de travail qui lui est associée ? Est-ce que j'utilise correctement mes outils ? Est-ce qu'il me manque des outils pour gagner en productivité ? Pour vous aider à répondre ces questions, il peut être intéressant de réaliser un audit pour faire avancer la réflexion, et notamment établir une charge de travail pour cette fonction de DSI. Ce qui devrait vous aider à faire le choix entre externaliser ou internaliser la DSI.
L'important à mon sens, c'est que la fonction "DSI" soit assurée par quelqu'un, soit un employé en interne, soit un prestataire. Le numérique est omniprésent et en constante évolution, on ne peut plus se permettre de mettre en place un système et de le laisser tourner en autonomie pendant des années sans s'en occuper, si ce n'est faire le strict minimum et le curatif. Le système d'information doit vivre, car les enjeux sont forts.
Pour ceux qui vont se laisser tenter par la DSI externalisée, reste à choisir son prestataire : ce n'est pas les prétendants qui manquent, je peux citer par exemple OTO Technology. Votre moteur de recherche favori ou votre réseau professionnel pourra vous aider à faire le bon choix.
The post Doit-on externaliser sa DSI ? first appeared on IT-Connect.
Abonnez-vous à notre chaîne YouTube pour ne manquer aucune vidéo !
L'article La pénurie de semi-conducteurs devrait vous préoccuper est apparu en premier sur Numerama.
Abonnez-vous à notre chaîne YouTube pour ne manquer aucune vidéo !
L'article Sur Chrome OS, Google vous soumettra des mises à jour plus souvent à l’avenir est apparu en premier sur Numerama.
Abonnez-vous à notre chaîne YouTube pour ne manquer aucune vidéo !
L'article Google laisse son IA construire des micro-processeurs : les possibilités sont infinies est apparu en premier sur Numerama.
Voitures, vélos, scooters... : la mobilité de demain se lit sur Vroom ! https://www.numerama.com/vroom/vroom//
L'article Fastly : comment une seule panne a-t-elle pu faire tomber toute une partie du web ? est apparu en premier sur Numerama.
Le DNS over HTTPS (DoH) est une norme qui a pour objectif de chiffrer les requêtes DNS entre votre machine et votre serveur DNS. Comment fonctionne-t-il ? Est-il fiable ? Est-ce que ce protocole permet de protéger ma vie privée ? Différentes questions se posent et dans ce premier article sur le sujet, je vais vous en parler.
Vidéo complète sur le sujet : de la théorie à la pratique avec la configuration des navigateurs et une démo sous Windows 10 avec une rapide analyse de trames.
Le DNS est l'un des protocoles les plus anciens et surtout, c'est un protocole indispensable que l'on utilise tous au quotidien. Pour rappel, il sert à traduire les noms de domaine en adresse IP, alors d'un point de vue des utilisateurs il facilite grandement l'utilisation d'Internet au quotidien. On retient le nom de domaine d'un site, et non son adresse IP sinon cela pourrait être compliqué.
Néanmoins, le protocole DNS a beau être précieux, il a une faiblesse majeure : il n'a pas été pensé pour être sécurisé (comme les autres protocoles de sa génération, en fait). Forcément cela pose des problèmes, d'autant plus que ces dernières années le respect de la vie privée est devenu un enjeu majeur, tout comme la sécurité des données au sens large.
Aujourd'hui, le protocole HTTP non sécurisé dispose d'une version sécurisée avec le HTTPS, les protocoles de messagerie disposent aussi de versions sécurisées, etc... Quid du protocole DNS ?
Psst... Si vous ne maîtrisez pas la notion de DNS, je vous propose de découvrir ma vidéo "Le DNS pour les débutants" :
Le résolveur DNS correspond au serveur DNS sollicité lorsque votre machine a besoin de traduire un nom de domaine en adresse IP. Une étape indispensable pour contacter le bon serveur et accéder à votre site préféré.
Concrètement, lorsque vous contactez un site Internet en saisissant son nom de domaine directement dans la barre d'adresse, votre machine va envoyer une requête DNS au résolveur DNS pour lui poser une question simple : "Peux-tu m'indiquer l'adresse IP correspondante au site it-connect.fr ?". Si la réponse est connue, le serveur va répondre : "L'adresse IP du site it-connect.fr est 1.2.3.4", et votre machine va se connecter sur ce serveur.
Pour obtenir cette réponse, le résolveur va regarder dans son cache s'il a déjà l'information et si elle est toujours valide. Dans le cas où il n'a pas l'information, il va contacter le serveur DNS faisant autorité pour la zone de notre domaine afin de l'obtenir.
Sur Windows, on peut obtenir facilement l'adresse IP correspondante à un nom de domaine grâce à l'outil natif "nslookup". Il existe aussi sous Linux, mais il y a d'autres alternatives. L'utilisation basique de cet outil consiste à préciser le nom de domaine à résoudre : le résolveur DNS configuré sur votre machine (votre carte réseau) sera sollicité.
nslookup www.france.fr
Cet échange entre votre machine et le résolveur DNS s'effectue en clair sur le réseau.
Lorsqu'un échange s'effectue en clair sur le réseau, cela signifie que le contenu de la requête, c'est-à-dire le contenu du message, est lisible. Autrement dit, il n'est pas protégé par du chiffrement.
Si un attaquant intercepte cette requête, il pourrait la consulter, la modifier et vous retourner une réponse falsifiée dont l'objectif serait de vous orienter vers un site Internet malveillant. Ce site malveillant pourrait être une copie du site sur lequel vous souhaitez accéder dans le but de récupérer vos identifiants de connexion, par exemple. Dans ce cas, nous parlerons d'une attaque de l'homme du milieu (man in the middle) où "l'homme du milieu" est représenté par l'attaquant puisqu'il se situe entre vous et le résolveur DNS.
Par défaut, le protocole DNS n'a pas de mécanisme pour s'assurer de l'authenticité de la réponse : qu'est-ce qui me garantit que je vais bien consulter le bon site Internet ? Autrement dit, le serveur DNS peut renvoyer n'importe quelle adresse IP, le client DNS lui fera confiance.
Cet exemple (il y en a d'autres) met en évidence ce besoin de sécuriser les échanges entre votre machine et le résolveur DNS.
Au-delà de la problématique autour de la sécurité des échanges, il y a une autre question que l'on peut se poser : quel résolveur DNS doit-on utiliser ? Est-ce qu'il y a des résolveurs DNS plus fiables que d'autres ?
Prenons un exemple. Lorsque vous êtes chez vous et que vous utilisez la configuration par défaut de votre Box, vous utilisez les serveurs DNS de votre fournisseur d'accès à Internet (FAI). À première vue, ces résolveurs DNS sont fiables et, éventuellement, on peut dire qu'ils sont neutres. Mais ce n'est pas le cas.
Dans le cas où une décision de justice ordonne le blocage d'un site spécifique (ce qui est déjà arrivé pour des dizaines de sites de streaming tels que Allostream et Time2watch), les serveurs DNS des FAI ne répondront plus aux requêtes lorsqu'un client DNS demande l'adresse IP correspondante à un domaine bloqué. Pourtant le site existe et il est en ligne. On parle alors de résolveurs DNS menteurs.
En alternative, nous avons bien sûr les DNS de Google notamment le fameux "8.8.8.8" que certains connaissent surement. Disons que Google n'est pas réputé pour respecter la vie privée des utilisateurs donc si on peut en trouver un autre, ce n'est pas plus mal. Utiliser le DNS de Google, cela veut dire que l'on autorise Google à garder l'historique de nos requêtes DNS et potentiellement, à l'exploiter. Mais alors, quel résolveur DNS choisir ?
En parlant du DNS de Google, il y a d'ailleurs une histoire assez incroyable à ce sujet. En 2014, la Turquie avait décidé de bloquer Twitter et YouTube. Pour contourner cette censure, les internautes turcs utilisaient les DNS de Google. Pour faire passer le message, il y avait même des inscriptions sur les bâtiments pour diffuser l'adresse du DNS de Google. Le gouvernement a contre-attaqué en demandant aux FAI que les DNS de Google soient bloqués en redirigeant les requêtes vers des sites mis en place par les FAI.
Comme alternative à Google, il y a depuis 2018, le résolveur DNS du géant Cloudflare que vous pouvez utiliser en utilisant l'adresse IP "1.1.1.1". Il se veut rapide et respectueux de la vie privée, je pense que c'est un bon choix, mais il reste américain. Dans le doute, vous pouvez vous tourner vers le résolveur DNS Quad9, exploité par la Fondation Quad9 basée en Suisse et accessible à l'adresse IP 9.9.9.9 (d'où le nom Quad9). Je reviendrai plus en détail sur le choix du résolveur DNS au moment d'en choisir un à utiliser avec le protocole DNS over HTTPS : tous les résolveurs ne sont pas compatibles.
En fait, ce qu'il faut retenir c'est que le résolveur DNS n'est pas là pour sécuriser le protocole DNS, mais il a un rôle à jouer dans le respect de la vie privée : en quelque sorte, vous devez avoir confiance en votre résolveur DNS.
Pour vous convaincre que le résolveur DNS a un rôle à jouer dans le respect de la vie privée, lisez ce qui suit... Si vous utilisez toujours le même résolveur et que celui-ci garde un historique de vos requêtes DNS, ce dernier pour facilement retracer l'ensemble des sites sur lesquels vous vous rendez. Votre adresse IP publique (qui est un peu comme votre adresse postale sur Internet) sera liée à un ensemble de noms de domaine, ce qui permettra de dresser un profil type. Par exemple si l'adresse IP 3.4.5.6 demande l'adresse IP correspondant au site it-connect.fr, puis openclassrooms.com, puis pole-emploi.fr. On peut deviner que vous recherchez un emploi dans l'informatique et que vous êtes sans emploi, étudiant ou en reconversion professionnelle (simple exemple).
Pour répondre à la question "comment sécuriser les échanges DNS ?", il y a plusieurs pistes à explorer. Plusieurs termes reviennent souvent : DNSSEC, DNS over TLS, DNS over HTTPS, voire même DNSCrypt. Dans le cadre de la présentation de DNS over HTTPS, je vais m'intéresser aux trois premiers cités.
Le DNSSEC (Domain Name System Security Extensions) est un protocole de communication qui a pour objectif d'apporter une couche de sécurité au protocole DNS. Les ingénieurs de l'IETF l'ont créé dans les années 1990.
Par l'intermédiaire de signatures numériques, le propriétaire d'une zone DNS va pouvoir signer les données des enregistrements DNS. C'est bien le contenu de la zone qui est signé et sécurisé, non pas les requêtes DNS. L'objectif étant d'authentifier le serveur qui répond à la requête DNS, mais aussi de s'assurer de l'intégrité de la réponse (pour être sûr qu'elle n'a pas été modifiée).
Cette méthode s'appuie sur de la cryptographie à clé publique où chaque zone dispose d'une paire de clés publique-privée. La clé privée reste secrète tandis que la clé publique sera publiée dans la zone directement. C'est intéressant, car cela va permettre à un résolveur DNS de vérifier l'authenticité des données de la zone DNS grâce à la clé publique et à la vérification des signatures. Dans le cas où l'authentification des données est réussie, le résolveur DNS retourne la réponse au client DNS, alors que si la signature est incorrecte, une erreur est renvoyée au client DNS. Cela peut signifier qu'il s'agit d'une attaque.
Concrètement, DNSSEC va permettre de lutter contre différentes attaques, et particulièrement l'empoisonnement du cache DNS, qui consiste à envoyer de fausses informations à un résolveur DNS qui cherche à résoudre un nom. Cette fausse information sera ensuite envoyée aux clients DNS. On dit que le cache est empoisonné, car il contient de fausses informations.
Pour que le mécanisme de protection de DNSSEC soit pleinement efficace, il faut que l'ensemble de la chaîne soit signée pour créer une chaîne de confiance. En fait, si l'on prend l'exemple du domaine "it-connect.fr", il faut appliquer DNSSEC sur la zone "it-connect.fr", mais également sur la zone ".fr" qui correspond à son domaine de premier niveau (ccTLD, gTLD, etc.). Rassurez-vous, c'est le cas pour toutes ces zones de premiers niveaux.
Pour activer le DNSSEC sur un domaine, au niveau de votre hébergeur ce n'est pas plus compliqué que de cocher une case dans les options de votre domaine. Par exemple chez OVH, il y a une option nommée "Délégation sécurisée - DNSSEC". Sachez également que DNSSEC peut être activé pour sécuriser la zone DNS d'un annuaire Active Directory.
Le DNSSEC est un premier pas en avant puisqu'il permet de s'assurer que le contenu de la réponse que l'on reçoit est authentique, qu’elle est saine et qu'elle correspond bien à notre requête. Néanmoins, il n'apporte pas de réponse à la problématique suivante : comment chiffrer les échanges DNS entre la machine et le résolveur DNS ?
Le DNS over TLS (DoT) est une norme qui a pour objectif de chiffrer le trafic DNS et permettre de sécuriser les échanges entre une machine et un résolveur DNS. Grâce à ce chiffrement, les attaquants (ainsi que les FAI) ne peuvent pas lire les données du trafic DNS, ni le modifier : une excellente protection contre les attaques de type "homme du milieu".
Le protocole TCP est utilisé pour établir la connexion par l'intermédiaire du port 853. Il s'agit d'un port dédié et cela peut s'avérer contraignant si le port est bloqué par le pare-feu qui se situe en sortie de votre réseau. Les paquets DNS sont chiffrés avec le protocole TLS pour sécuriser leur transmission.
Le DNS over HTTPS (DoH) est également une norme et elle est similaire au DNS over TLS. Clairement, son objectif est de chiffrer les échanges entre la machine qui effectue la requête DNS et le résolveur DNS en lui-même.
Là où il est différent, c'est dans son fonctionnement. Le protocole HTTPS est utilisé pour établir la connexion, ce qui implique que l'on utilise un port standard et qui sera celui du HTTPS : le port 443. Le trafic DNS quant à lui sera encapsulé au sein de la connexion HTTPS, tout en sachant que cette connexion bénéficie du chiffrement via TLS.
L'intérêt du DNS over HTTPS en comparaison du DNS over TLS, c'est qu'il utilise un protocole et un port standard : le HTTPS/443. Ce qui va lui permettre de passer plus facilement au travers des pare-feux, mais aussi de noyer les requêtes DNS dans la masse de trafic HTTPS.
Note : Le DNS over HTTPS correspond à la RFC 8484
Le DoH est probablement plus intéressant pour améliorer le respect de la vie privée des utilisateurs. Par contre, le trafic est difficilement identifiable, ce qui complique la tâche des administrateurs.
Comme nous venons de le voir, le DoH permet de chiffrer les échanges DNS. Par contre, le résolveur DNS que l'on utilise sera toujours en mesure de savoir ce qu'on lui a demandé comme requête DNS : la requête n'est pas anonyme, elle est envoyée depuis notre machine.
Si l'on veut vraiment aller jusqu'au bout des choses, non seulement il faut utiliser le DNS over HTTPS pour sécuriser les échanges DNS, mais il faut aussi choisir un résolveur DNS dans lequel nous avons confiance. Un résolveur DNS respectueux de la vie privée, en fait. Le DoH n'empêchera pas le serveur DNS de mentir comme c'est le cas lorsqu'un FAI bloque un site suite à une décision de justice, et il n'empêchera pas non plus le résolveur DNS de collecter les données sur les requêtes DNS émises par les clients DNS.
Un bon résolveur DNS est un résolveur DNS qui n'applique pas de censure (à part éventuellement contre les sites malveillants) et qui ne collecte pas de données liées à l'utilisation. S'il est massivement utilisé c'est encore mieux, comme ça votre trafic sera noyé dans la masse. Les résolveurs DNS de Cloudflare et Quad9 sont compatibles DoH et ils me semblent pertinents, avec une petite préférence pour le second qui est basé en Europe (Suisse). Si vous en connaissez un, n'hésitez pas à partager l'information.
La théorie est posée, maintenant il reste à voir comment utiliser DoH sur son ordinateur, sa tablette ou son smartphone.
La bonne nouvelle, c'est que dans les prochains articles, nous verrons comment utiliser le DNS over HTTPS avec différents navigateurs (Firefox, Chrome, Edge ou encore Brave), mais aussi sur Windows 10.
The post Sécurité DNS – DoH : Qu’est-ce le DNS over HTTPS ? first appeared on IT-Connect.
Voitures, vélos, scooters... : la mobilité de demain se lit sur Vroom ! https://www.numerama.com/vroom/vroom//
L'article Pourquoi certaines fonctionnalités de macOS 12 ne seront pas disponibles sur les machines Intel ? est apparu en premier sur Numerama.
Voitures, vélos, scooters... : la mobilité de demain se lit sur Vroom ! https://www.numerama.com/vroom/vroom//
L'article Mettez à jour Windows 10 sans tarder, des failles sont activement exploitées est apparu en premier sur Numerama.
Abonnez-vous à notre chaîne YouTube pour ne manquer aucune vidéo !
L'article macOS 12 Monterey : quels sont les ordinateurs compatibles ? est apparu en premier sur Numerama.
Abonnez-vous à notre chaîne YouTube pour ne manquer aucune vidéo !
L'article macOS Monterey : quelles sont les principales nouveautés ? est apparu en premier sur Numerama.
Voitures, vélos, scooters... : la mobilité de demain se lit sur Vroom ! https://www.numerama.com/vroom/vroom//
L'article iPadOS 15 : les 5 principales nouveautés annoncées par Apple pour ses tablettes est apparu en premier sur Numerama.
Voitures, vélos, scooters... : la mobilité de demain se lit sur Vroom ! https://www.numerama.com/vroom/vroom//
L'article Le MacBook Air M1, avec un SSD de 512 Go et 16 Go de RAM, a droit à 145 euros de réduction est apparu en premier sur Numerama.
Abonnez-vous à notre chaîne YouTube pour ne manquer aucune vidéo !
L'article iOS 15, macOS Monterey, iPadOS 15, watchOS 8, maison connectée : le récap’ des annonces Apple est apparu en premier sur Numerama.
Abonnez-vous à notre chaîne YouTube pour ne manquer aucune vidéo !
L'article Apprenez ces raccourcis clavier tout bêtes pour écrire des emojis sur Mac ou Windows est apparu en premier sur Numerama.
Lorsque l'on administre des serveurs distants en Linux ou BSD, on peut avoir besoin de se connecter à un serveur distant SSH depuis son PC en Windows.
Cela permet une connexion et communication sécurisée afin de prendre le contrôle d'un serveur, routeur ou d'une machine sur votre LAN.
Cet accès à distance en SSH se traduit par un un shell ligne de commandes.
Dans ce tutoriel, vous trouverez plusieurs méthodes et clients SSH pour se connecter en SSH depuis un Windows.
SSH est un protocole de communication chiffré et sûr.
Il permet à un administrateur d'ouvrir un terminal sur une machine distante afin de passer des commandes.
L'article suivant détaille le fonctionnement de SSH :
Ainsi pour pouvoir vous connecter en SSH :
L'authentification SSH peut se faire de deux manières :
PuTTY est un client SSH gratuit pour Windows.
Ce dernier vous permet de vous connecter à n'importe quel serveur SSH.
Il gère pas mal d'options ainsi qu'une liste de machines.
PutTTY supporte aussi l'authentification par clés SSH.
On utilise PuTTygen pour créer la paire de clés SSH.
Au final cela génère un fichier PPK qui est la clé privée à mettre dans les propriétés de la connexion.
Pour cela, rendez-vous dans le menu Connection > SSH > Auth.
Enfin il existe d'autres clients SSH pour Windows, notamment MobaXterm qui est beaucoup plus moderne :
Windows 10 fournit un client SSH depuis la version 1803.
Il est installé par défaut, mais si vous devez le réinstaller :
ssh <user>@<host>ssh [email protected]La commande SSH de Windows est la même que Linux, reportez-vous donc au paragraphe suivant pour plus d'informations sur son utilisation.
MobaXterm est un client qui permet de se connecter en SSH, RDP.
Il gère aussi les transferts de fichiers en SFTP ou FTP.
Le tutoriel suivant vous guide pour vous connecter en SSH avec ce client :
Bitvise est un client SSH, SFTP et RDP pour Windows.
Il offre toutes les fonctionnalités d'un client SSH classiques :
cygwin est un utilitaire sur Windows qui permet l'accès à l'ensemble des bibliothèques Linux.
On peut ouvrir un terminal et passer des commandes.
Il est alors possible d'installer le client SSH sur Windows et de se connecter avec depuis un terminal Cygwin.
Voir aussi ce tutoriel :
ssh <user>@<hote>Plus de détails sur son utilisation :
L’article Comment se connecter en SSH à un serveur distant depuis Windows est apparu en premier sur malekal.com.
Microsoft Edge va prochainement mettre en avant le protocole HTTPS. La fonctionnalité Automatic HTTPS est actuellement en test. Explication. A l’image de Chrome, Edge travaille pour un Web plus sécurisé en encouragement l’adoption du HTTPS. La dernière Preview d’Edge 92 dévoile l’approche utilisée par Microsoft. Le navigateur est actuellement en test au travers d’un canal ...
The post Microsoft Edge 92, quel est le but de la fonction Automatic HTTPS ? appeared first on GinjFo.
Dans le dernier bulletin d'actualité du CERT-FR, l'ANSSI fait un retour d'expérience sur les campagnes de signalement de vulnérabilités qu'elle mène auprès d'organisations privées ou publiques en France.
En effet, depuis qu'un texte de loi a été publié en 2018, l'ANSSI assure un service de veille active des vulnérabilités critiques. Ainsi, l'Agence effectue des scans automatisés envers des organisations françaises de tout type et peut également servir de relais entre un chercheur indépendant ayant trouvé une vulnérabilité et une organisation.
Par exemple, lors de la parution d'une nouvelle vulnérabilité critique, telle que la CVE-2019-19781 ayant impactées les services Citrix en 2019, l'ANSSI a effectué des scans réseau sur l'Internet français. Ceux-ci sont lancés sur un ensemble d'adresse IP relatives à des organisations françaises et l'ANSSI peut alerter les propriétaires des services vulnérables relevés. Pour cette vulnérabilité spécifique, par exemple, l'ANSSI fournis les chiffres suivants :
Le 3 janvier 2020, l’ANSSI avait pu identifier 870 adresses IP vulnérables à la CVE-2019-19781 affectant certains produits Citrix. En janvier 2021, 134 adresses IP étaient encore vulnérables à la CVE-2019-19781. En 2020, l’ANSSI a pu constater 15 incidents de sécurité affectant des entités publiques et privées importantes dont l’origine était attribuée à la vulnérabilité CVE-2019-19781.
Il arrive cependant à l'ANSSI ou aux chercheurs indépendants que le contact avec le propriétaire d'un actif vulnérable soit difficile à établir. Ainsi, l'ANSSI dans son RETEX fournis quelques conseils afin d'être facilement joignable :
Les informations d’enregistrement des noms de domaine doivent être maintenues à jour auprès du registraire.
L'une des première source d'information est en effet la base WHOIS, qui contient l'identité et les contacts des propriétaires d'un nom de domaine. La base WHOIS est consultable via la commande Linux WHOIS ou via de nombreux sites web (https://viewdns.info/whois/). Aujourd'hui, les hébergeurs proposent par défaut l'anonymisation des informations présentées dans l'enregistrement WHOIS, cela à des fins de protection de la vie privée. Si l'option est intéressante pour les personnes physiques, elle ne doit pas être utilisée par les entreprises. Dans d'autres cas, les informations présentes dans cette base sont obsolètes, par exemple : la personne ayant souscrit au nom de domaine n'est plus dans l'entreprise.
Voici en exemple le contenu d'un enregistrement WHOIS correctement rempli :
Il est donc conseillé de faire régulièrement (disons une fois par an) le tour de l'ensemble des informations WHOIS des noms de domaine appartenant à l'entreprise afin d'être certains que ces informations sont toujours valides.
Les certificats x509 utilisés doivent mentionner les bonnes informations concernant le propriétaire (il est déconseillé d’utiliser des certificats auto-signés tout comme les certificats proposés par défaut lors de l’installation du logiciel ou du matériel).
Les informations contenues dans les certificats publics sont également utilisables pour identifier le propriétaire d'un actif. Voici un exemple avec le site whatsapp.net, dont le propriétaire est l'entreprise Facebook :
Là encore, ces informations peuvent s'avérer fausses ou obsolètes. Pour une entreprise, il est conseillé de mettre des informations à jour et correspondant à la réalité, rien ne sert de mettre une fausse organisation ou adresse, etc. Un attaquant saura multiplier les sources pour trouver des informations valides.
Les adresses de contact doivent être consultées régulièrement par leurs propriétaires.
De toute évidence, ces adresses mails seront publiques et donc utilisées pour du spam ou des annonces commerciales. Néanmoins, il reste important de ne pas indiquer des adresses mails "poubelles" car leur publication garde un intérêt certains : être averti et contacté facilement en cas de découverte d'une vulnérabilité (entre autre).
Le destinataire doit être à même de juger de l’importance de la communication.
Autrement dit, l'adresse mail, postale ou le numéro du contact indiqué dans ces différentes sources doit avoir compétence à évaluer une alerte de sécurité. Si vous indiquez l'adresse mail du PDG de la boite, il n'aura peut être pas le temps ou le savoir nécessaire pour apprécier une telle alerte. Il est préférable d'indiquer le contact du/de la DSI, RSSI ou même une mailing-list regroupant plusieurs personnes compétentes, le SOC/CERT si vous en avez un, reste la meilleur option.
Enfin, je rajoute à ces différentes propositions l'utilisation du fichier /.well-known/security.txt, il s'agit d'un standard proposé par différents chercheurs en sécurité permettant de trouver facilement les bons contacts pour un signalement de vulnérabilité. Son fonctionnement est à l'image du fichier robots.txt pour les crawlers automatisés (Bing, Google, etc.). Un générateur automatique du fichier est même proposé : https://securitytxt.org/
Voici un exemple :
Enfin, l'ANSSI dans son RETEX nous parle également de la prise en compte du signalement, le fameux "on fait quoi maintenant ?". C'est là que les procédures internes de l'entreprise doivent être utilisés, notamment concernant la gestion des alertes et des incidents, ce qui implique qu'elles soit définies à l'avance et non pas improvisées lorsqu'un signalement arrive :). Dans le cas où vous passez totalement ou partiellement par un infogérant, il faut espérer que des clauses particulières concernant la sécurité soient présentes dans votre contrat. Si ce n'est pas le cas, je vous oriente vers ce guide : Maîtriser les risques de l'infogérance
Si vous êtes un chercheur en sécurité ayant découvert une vulnérabilité, je vous conseille d'essayer de faire correspondre votre situation à l'un de ces deux cas de figure :
Attention, l'ANSSI ne sera surement intéressée que par des vulnérabilités conséquentes sur des entités importantes, pas la peine de leur signaler une XSS sur un blog de jardinage
Si vous ne rentrez dans aucun de ces cas de figure, mon avis est généralement de ne pas remonter de vulnérabilités, notamment lorsque l'on s'attaque à des environnement de production, en opposition à des applications que l'on peut installer en local comme un Owncloud, un Firefox, ou autre. Il m'est arrivé de croiser des chercheurs pour lesquels la poursuite pénale n'était pas loin, aussi louables étaient leurs intentions, certaines entreprises ont une philosophie encore très vintage. A vos risques et périls donc.
Dernier bulletin du CERT-FR : Retour d’expérience sur les campagnes de signalement de vulnérabilités
The post Comment faciliter la remontée de vulnérabilités ? first appeared on IT-Connect.Le scan de ports réseaux ou balayage de ports est une méthode qui consiste à énumérer les ports ouverts ou actifs d'une cible.
Le but est surtout de lister les ports ouverts afin de connaître les applications et services en cours de fonctionnement.
Cela permet de trouver des applications vulnérables pour pirater d'un ordinateur ou serveur ou encore obtenir d'autres informations sur le système (version de l'OS, etc).
Il s'agit donc de la première action à mener lors d'un test de pénétration dans le cadre de découverte de la cible.
Il s'agit d'énumérer les services réseaux utilisés, obtenir des informations sur ces derniers puis par la suite mener des attaques contre ces derniers.
Ce tutoriel vous donne toutes les explications autour du scan de ports.
Mais aussi comment effectuer un port scan et enfin quelques outils présentés et comment s'en protéger.
Enfin le sujet étant vaste et complexe, nous simplifions au maximum.
L'introduction précédente résume à peu prêt l'intérêt du port scan.
Voici un rappel très rapide : un port est comme une porte et une application ouvre un port en écoute afin que tout ordinateur puisse s'y connecter.
Par exemple, un serveur WEB passe le port 80 et 443 en écoute,afin que les navigateurs WEB des clients puissent s'y connecter.
Ici ion utilise un logiciel qui va se tester chaque port d'une cible pour vérifier son état et ainsi lister les ports en écoute.
Pour cela,
Le port scan peut se faire de 1 à 65535 de manière incrémentale ou sur des ports aléatoires.
A lire sur le sujet :
Le port scan peut aussi cibler des services réseaux connus utilisant des ports standard, exemple :
Lors d'une tentative d'accès à un port, le système peut retourner ou non des informations sur l'état du port.
C'est cet état qui permet de donner des informations sur les applications en cours de fonctionnement sur l'ordinateur ou serveur ciblé.
Pour simplifier, on retiendra quatre états différents lors d'un port scan :
Enfin, le port scan peut être fait depuis internet vers une cible, par exemple, vous pouvez scanner votre adresse IP publique.
Mais aussi dans un réseau local (LAN) pour lister tous les ordinateurs de ce dernier puis les serveurs réseaux qui tournent sur chaque poste.
Il existe de multiples applications sur Linux et Windows pour effectuer des balayages de ports réseaux.
Il existe de multiples autres programmes qui permettent d'effectuer ce type de port scan et scan du réseau local.
Notamment Advanced IP Scanner pour Windows.
Ce dernier permet d'énumérer très facilement les machines et hôtes d'un réseau LAN.
On obtient donc la liste des hôtes avec leurs adresses IP et adresse MAC.
Nmap (Network Mapper) est un utilitaire le plus connus et renommé qui existe en ligne de commandes ou avec une interface graphique (Zenmap).
Pour installer Nmap sur Linux :
sudo apt-get install nmap #Pour les distributions basés sur Debian
yum install nmap #Pour les distributions basés sur RedhatPour Windows :
Pour exemple pour énumérer les ports ouverts d'un PC distant avec des informations sur la version du service réseau :
En ligne de commandes, on peut lister les ports standard et obtenir des informations sur les versions.
Dans cet exemple environ 1000 ports scannés et 993 ports filtrés.
Ainsi, ci-dessous, on sait que le serveur est potentiellement sur une Debian avec les versions de Nginx et OpenSSH.
nmap -sV www.adresse.tldEt bien sûr on retrouve la même chose avec le nmap pour Windows.
En haut vous pouvez spécifier la ou les cibles ou en bas saisir directement les commandes Nmap.
Nmap propose beaucoup d'options pour scanner un seul port ou encore jouer sur le mode de connexion ou protocole pour contourner des filtrages des firewall.
Dans les exemples précédents, il s'agit d'un scan TCP, on peut faire la même chose en UDP, dans le cas où des applications écoutent sur ces ports.
Pour aller plus loin, on peut alors de scanner toutes les adresses IP d'un réseau local LAN, afin d'obtenir la liste des ordinateurs et serveurs présents puis effectuer un scan de port sur chacun afin de lister les services réseaux en écoute.
Il s'agit d'une découverte du réseau.
Nmap fait très bien cela, en indiquant un subnet ou masque de sous réseau complet.
Ainsi les noms des ordinateurs sont très rapidement récupérés.
nmap 192.168.1.0/24
nmap 192.168.1.*Puis un scan de ports est possible sur chaque adresse IP :
Enfin on peut dessiner la topologie du réseau.
Les ordinateurs du réseau local (LAN) ne sont pas accessible depuis internet.
En effet c'est le principe du NAT mais on peut avoir des exceptions avec les transferts de ports du routeur vers un ordinateur du LAN.
Ainsi, si vous effectuez un port scan d'internet vers votre adresse IP publique.
Dans ce cas, le scan de port cible votre routeur/box.
Il existe des services WEB qui permettent d'effectuer ces scans, en voici quelque uns :
Pour récupérer votre adresse IP publique, suivez ce tutoriel : Comment trouver l'adresse IP publique ou locale
Lire aussi la page : La notion de port ouvert et la sécurité et Lister les connexions établies sur Windows
Cette page liste notamment quelques programmes qui permettent de lister les applications en écoute et donc ports ouverts sur Windows.
Si une application est en écoute, cela signifie qu'on peut s'y connecter et éventuellement utiliser des vulnérabilités afin de pirater l'ordinateur ou le serveur.
Les recommandations basiques sont donc :
Côté serveur :
Rien vraiment à faire, en général, les routeurs et box possèdent des protections contre les ports scans.
Vous pouvez vous identifier sur l'interface de gestion de votre routeur/box et configurer le filtrage des services.
Le Browser Port scan permet d'effectuer un scan de port de votre PC depuis une page WEB.
En plus d'énumérer les ports ouverts, il est possible de lister les machines de votre réseau.
L'article suivant explique le principe et comment s'en protéger.
Enfin les articles suivants expliquent comment vérifier si un port est ouvert en effectuant un scan de ports :
L’article Comment faire un scan de ports réseaux ou balayage de ports réseaux est apparu en premier sur malekal.com.
