Dans une étude présentée mardi 18 avril, l’UFC-Que choisir dénonce des offres très haut débit « au rabais » et une fracture numérique persistente. L’association demande aux pouvoirs publics d’agir.
VMware Workstation Pro propose différents modes pour connecter la machine virtuelle au réseau. Quand on débute, ce n'est pas évident de comprendre la différence entre ces types de réseau virtuel : quelles sont les différences ? comment fonctionne chaque mode ? C'est ce que nous allons voir dans ce tutoriel, pour que les réseaux virtuels avec VMware Workstation Pro n'aient plus de secrets pour vous.
Un tour dans les propriétés réseau d'une machine virtuelle permet de visualiser les différents modes d'accès réseau disponibles : Bridged, NAT, Host-only, Custom et LAN Segment. Avec autant de choix, il y a de quoi répondre à de nombreux besoins !
Ce tutoriel est disponible au format vidéo :
Commençons par étudier le mode "NAT", car lorsqu'une machine virtuelle est créée dans VMware Workstation Pro, elle est configurée en mode NAT par défaut. En même temps, cela se comprend, car avec ce mode, la VM peut accéder à Internet, via la même connexion que l'hôte physique, sans pour autant obtenir une adresse IP sur votre réseau local.
Ceci est possible, car VMware Workstation Pro, au même titre que VirtualBox, intègre un serveur DHCP qui va attribuer une adresse IP à votre machine virtuelle. Autrement dit, le serveur DHCP de votre réseau local (un routeur, une box Internet, ou un autre serveur), ne sera pas sollicité. Lorsque ce mode est utilisé, VMware crée un réseau local virtuel et isolé du reste de vos machines physiques.
L'inconvénient de ce mode, c'est que vous ne pouvez pas accéder aux services de votre machine virtuelle (RDP, site Web, etc...) à partir d'une autre machine de votre réseau local. C'est compréhensible, car c'est le principe du NAT et VMware, au sein de ce réseau virtuel, va jouer le rôle de routeur pour que la VM accède au réseau local puis à Internet. Toutefois, au sein des paramètres de VMware Workstation, nous pourrons créer une règle de redirection de port pour contourner cette limite.
Comme le montre le schéma ci-dessous, lorsque deux machines sont connectées en mode "NAT", elles peuvent communiquer ensemble, mais aussi accéder au réseau local de la machine physique ainsi qu'à Internet. Lorsqu'une machine virtuelle en mode NAT accède au réseau local ou à Internet, elle partage l'adresse IP de l'hôte physique. Par contre, elles sont isolées du réseau local grâce au principe du NAT, ce qui est avantageux.
Pour connecter une machine en mode NAT, il suffit de définir sa carte réseau virtuelle sur le mode "NAT: Used to share the host's IP address".
Pour modifier la configuration du réseau NAT de VMware Workstation, il faut accéder au menu suivant : Edit > Virtual Network Editor.
C'est ici que vous pouvez configurer les réseaux virtuels, mais aussi en créer des nouveaux même s'il ne peut y avoir qu'un seul réseau NAT. Pour changer la configuration, il faudra sélectionner "NAT" et cliquer sur "Change Settings". Ce qui implique d'avoir les droits d’admin.
Ici, on voit clairement le sous-réseau IP utilisé par le réseau NAT : 192.168.145.0/24. En changeant les valeurs dans la zone surlignée en jaune ci-dessous, vous pouvez choisir un autre réseau IP. En cliquant sur "DHCP Settings", vous pouvez adapter l'étendue DHCP associée à ce réseau. Enfin, pour désactiver le serveur DHCP de VMware sur le réseau NAT (ce qui sera utile si vous souhaitez tester un serveur DHCP sur une VM), décochez l'option "Use local DHCP service to distribute IP address to VMs".
Pour créer une règle de redirection de ports, par exemple pour qu'un serveur Web hébergé sur une VM en mode NAT soit accessible depuis le réseau local, il faut cliquer sur "NAT Settings" et créer une nouvelle règle dans la section "Port Forwarding". La règle ci-dessous va permettre de rediriger le port 8080 (pour les connexions sur l'hôte physique) vers le 80 de la machine virtuelle qui a l'adresse IP 192.168.145.128. Attention, si le serveur Web change d'adresse IP, il faudra réadapter la règle, donc il peut s'avérer intéressant d'utiliser des adresses IP fixes.
En sélectionnant le mode "Bridged" que l'on peut appeler le mode "Accès par pont", la machine virtuelle aura un accès à votre réseau, au même titre que votre ordinateur physique. De ce fait, si elle est configurée en DHCP, elle va solliciter le serveur DHCP de votre réseau local pour obtenir une adresse IP et accéder au réseau local.
Avec un accès en mode Bridged, la VM pourra contacter les autres machines connectées au réseau et elle pourra être contactée par les autres machines de ce réseau, contrairement au mode NAT où ce n'était pas possible (à moins de créer une ou plusieurs règles de redirection de ports).
Au sein des paramètres de la machine virtuelle, il suffit de cocher le mode "Bridged : Connected directly to the physical network" pour utiliser l'accès par pont. L'option "Replicate physical network connection state" n'est pas obligatoire, mais permet à la VM de renouveler son adresse IP lorsque la machine physique change de réseau ou de carte.
Dans le Virtual Network Editor de VMware, on peut voir que la carte Bridged est en mode "Auto-bridging". Il s'agit d'un mode automatique où le pont va être monté avec la carte utilisée par l'hôte physique. Par exemple, si votre machine physique accède au réseau local en WiFi, VMware va établir le pont avec l'interface WiFi de votre PC. À la place de "Automatic", vous pouvez choisir une carte manuellement ou choisir les cartes utilisables par VMware Workstation en cliquant sur "Automatic Settings".
Vous pouvez créer plusieurs réseaux virtuels Bridged, mais chaque réseau Bridged doit être associé à une interface physique différente. Sinon, VMware Workstation affiche une erreur lors de la création d'un nouveau réseau Bridged. Autrement dit, on pourrait associer un réseau Bridged à l'interface filaire de la machine physique et associer un second réseau Bridged à l'interface WiFi de cette même machine physique.
Continuons à explorer les différents modes d'accès au réseau, en s'intéressant au mode "Host-Only". Lorsqu'une machine virtuelle est connectée en mode "Host-Only", elle peut contacter l'hôte physique où est installé VMware Workstation. Si d'autres machines virtuelles sont connectées sur ce même réseau Host-Only, elles peuvent communiquer entre elles. Par contre, la machine virtuelle ne peut pas accéder à votre réseau local, ni même à Internet. Le réseau Host-Only est isolé, si ce n'est qu'il permet de contacter la machine physique.
Ce qui donne la représentation suivante, où j'attire votre attention sur l'absence de lien entre la carte réseau host-only et la carte physique de la machine :
Dans les paramètres d'une machine virtuelle, la connexion réseau "Host-only : a private network shared with the host" doit être sélectionné pour utiliser ce mode.
Il y a aussi un serveur DHCP, sur un sous-réseau différent du mode NAT, qui est actif sur le réseau Host-only de VMware. Ce sous-réseau peut être personnalisé, le serveur DHCP désactivé ou activé, sur le même principe que ce que l'on a vu précédemment. À savoir, via le Virtual Network Editor. En cliquant sur le bouton "Add network", on peut créer un second réseau host-only.
La connexion réseau "LAN Segment" va permettre de créer un réseau virtuel isolé, où les communications seront possibles uniquement entre les machines virtuelles connectées sur un même réseau interne. De ce fait, une VM connectée à un réseau interne ne peut pas communiquer avec l'hôte physique VMware, ni avec le reste du réseau où est connecté cet hôte physique, ni même avec Internet.
Ce mode d'accès réseau est intéressant pour reproduire un vrai réseau puisque l'on isole totalement ce réseau virtuel des autres réseaux. Par exemple, on peut installer et tester son propre serveur DHCP sans risquer de perturber le réseau local de production, ni même être perturbé par le serveur DHCP de votre box, de votre entreprise, ou celui de VMware. On peut aussi le faire en mode NAT, mais il faut désactiver le DHCP de VMware, alors que là, ce n'est pas nécessaire. Avec ce mode, c'est à vous de gérer le plan d'adresse IP au sein du réseau virtuel, soit par l'intermédiaire d'un serveur DHCP ou via des adresses IP fixes.
VMware Workstation Pro autorise la création de plusieurs réseaux "LAN segments". Ce qui permet de créer une multitude de réseaux virtuels isolés les uns des autres. Dans les paramètres d'une machine virtuelle, il convient de sélectionner le mode "LAN segment" et il faut choisir un segment réseau virtuel. Par défaut, il n'en existe pas. Ce qui implique de cliquer sur "LAN Segments..." puis sur "Add" pour créer un nouveau segment et le sélectionner. Ensuite, une autre machine qui doit se connecter sur le même réseau virtuel, devra être associé au même LAN Segment.
Afin de permettre aux machines virtuelles connectées au LAN Segment "LAN_VM" (déclaré sur l'image ci-dessus) d'accéder à Internet malgré tout, on peut imaginer un scénario avec une VM faisant office de routeur. C'est un scénario très intéressant à reproduire dans un lab puisque l'on positionne son propre routeur/pare-feu (VM 3) pour permettre les communications vers l'extérieur, de la même façon qu'on le fait avec un réseau réel.
Dans cet exemple, la VM 3 a une carte réseau configurée dans le LAN Segment "LAN_VM" ainsi qu'une carte réseau configurée en mode NAT afin de permettre aux machines du réseau interne d'accéder à Internet. La VM 3 peut être un pare-feu PfSense ou OPNsense, mais aussi sous Linux ou Windows en activant les fonctions de routage.
Lorsque l'on configure l'adaptateur réseau d'une machine virtuelle VMware Workstation, on voit qu'il y a le mode "Custom: Specific virtual network". Ce mode permet de choisir directement l'adaptateur VMware sur lequel vous souhaitez vous connecter.
Chaque adaptateur peut être associé à un réseau virtuel, soit en NAT, Host-only ou en Bridged. Pour utiliser les modes de connexion que je viens de citer, il suffit de faire son choix dans les propriétés de la VM. Toutefois, si l'on crée plusieurs réseaux Host-only ou Bridged, par exemple, il faudra utiliser le mode "Custom" pour choisir le bon réseau virtuel.
En fait, les noms que l'on voit apparaître dans la liste "Custom" correspondent aux noms et réseaux virtuels déclarés dans le Virtual Network Editor de VMware Workstation. On peut le constater facilement :
On a besoin de s'appuyer sur la connexion réseau "Custom" pour choisir un réseau spécifique lorsque l'on a créé une multitude de réseaux virtuels sur son instance VMware Workstation.
Nous venons d'évoquer les différentes modes de connexion réseau accessible pour les machines virtuelles sous VMware Workstation Pro. Il reste une possibilité que je n'ai pas encore évoquée, c'est le fait de déconnecter la machine du réseau en décochant l'option "Connect at power on" dans les options de l'adaptateur réseau de la VM. Ainsi, on peut "simuler" une déconnexion réseau comme si on débranchait le câble réseau de la machine virtuelle.
Pour conclure, voici un tableau récapitulatif qui, pour chaque mode de connexion réseau, vous montre quels sont les flux possibles :
Il ne vous reste plus qu'à vous exercer !
The post Comprendre les différents types de réseaux de VMware Workstation Pro first appeared on IT-Connect.
Vous le savez, Kali est un Linux spécialisé pour la cybersécurité, qui permet de faire de l’analyse de vulnérabilité, du test d’intrusion, de l’analyse de paquets réseau, du reverse engineering et tout un tas d’autres trucs. Si vous êtes un pentester, vous l’utilisez probablement et vous savez que la création de VM Kali Linux pour chaque mission peut être une tâche un poil relou !
Heureusement, un nouveau projet open source baptisé Kali-automation-install va vous faciliter grandement la vie. Cet outil permet en effet de créer automatiquement une VM Kali Linux avec tous les outils nécessaires pré-installés dessus, le tout en utilisant un simple script bash qui peut être rapidement et facilement modifié. Cela permet de répondre à vos besoins spécifiques sur chacune de vos missions d’expert ;-).
Ce projet a été développé par sKillseries, un habitué du monde offensif cyber et permet aussi de configurer Kali en français pour qu’il fonctionne avec les deux hyperviseurs les plus courants : VirtualBox et VMware.
Pour l’utiliser, vous devrez d’abord installer packer ainsi que l’hyperviseur de votre choix (J’ai choisi Virtualbox pour l’exemple).
Connexionapt install packer virtualbox virtuabox-ext-packEnsuite, vous pouvez modifier les variables qui sont dans le fichier kali-var.json pour personnaliser votre VM Kali Linux.
{
"iso_url": "<Lien de Téléchargement Kali-Linux>",
"iso_checksum": "<SHA256Checksum de l'ISO>
}Enfin, une fois ces modifications faites, vous pourrez initier la création de la VM avec une seule commande directement depuis votre terminal ou vos propres scripts.
packer build -var-file=kali-vars.json config-virtualbox.jsonVous pouvez même le faire en mode headless si vous le souhaitez (sans interaction) en ajoutant le paramètre suivant au fichier json de votre hyperviseur.
"headless": "1",Vous trouverez toutes les infos sur ce projet sur sa page Github.
Il vous est peut-être déjà arrivé de configurer chez vous (ou ailleurs) un réseau WiFi, de connecter votre ordinateur avec le mot de passe par défaut ou un mot de passe que vous avez configuré, d’aller sur Internet pendant des mois voire des années… puis au moment de connecter un nouvel ordinateur, de vous demander […]
L'article Retrouver le mot de passe du WiFi sur lequel vous êtes connecté est apparu pour la première fois sur Byothe.fr.
Sur votre PC Windows, lorsque vous utilisez la connexion Internet de votre domicile (Fibre, ADSL) ou celle d’un réseau cellulaire (5G, 4G), vous utilisez par défaut les serveurs DNS de votre fournisseur d’accès Internet (FAI). Cependant, ces serveurs DNS ne sont pas les meilleurs que vous pouvez utiliser. Savez-vous que vous pouviez accélérer la vitesse de navigation, améliorer la sécurité et...
Suite à plusieurs mises à jour de l'application MyCanal sur notre téléviseur tournant sous Android TV, foireuse pour la première, changeant le mode de connexion et étant incomplète pour la seconde, je me suis mis en tête de trouver une alternative pour regarder les chaines de la TNT en direct.
Molotov me plaisait moyennement, je trouve son interface austère et n'ai jamais été convaincu.
Il y a bien les applications de chaque chaîne, MyTF1, 6Play, ArteTV, Pluto, ... mais ce n'est pas pratique du tout, devoir changer d'application en fonction de ce qu'on regarde, en plus de devoir créer un compte pour chacune d'entre elles.
Etant chez Free en tant que fournisseur d'accès à Internet, j'ai regardé si je ne pourrais pas configurer le flux m3u qu'ils mettent à disposition des abonnés, mais la qualité est moindre et l'intégration dans une application sur la tv n'était pas optimale. Finalement, en naviguant sur le site de Free, un nom m'a attiré, l'oeil, OQEE. Après vérification de ce qui était proposé, et notamment que c'était bien disponible pour mon abonnement (Freebox Révolution), je l'ai installée et ai tenté de regarder la TV par ce biais.
Et là, c'est le drame !
Et oui, vu que je n'utilise pas le player tv de Free, et qu'en plus j'ai un routeur UniFi Dream Machine pour gérer mon réseau domestique, je n'avais pas configuré l'IPv6, n'en ayant pas le besoin. Nous allons voir ensemble comment configurer la Freebox et l'UDM pour disposer d'une connectivité IPv6 sur votre réseau.
Dans mon cas, le routeur UniFi est un UDM (UniFi Dream Machine) mais la configuration que je vais décrire s'applique également à l'UDM Pro ou à l'USG / USG Pro.
Nous allons en premier lieu récupérer l'adresse IPv6 de l'interface WAN de l'UDM. Pour cela, connectez-vous en SSH à votre routeur et utilisez la commande ip addr | grep "global dynamic" -B2 -A3.
Nous allons renseigner cette adresse dans la page de configuration de la Freebox. Connectez-vous sur http://mafreebox.freebox.fr, lancez les "Paramètres de la Freebox" et choisissez "Configuration IPV6". Il faut coller l'adresse IPv6 de l'UDM dans le second Next Hop uniquement pour déléguer un préfixe. Notez également le préfixe associé, nous allons en avoir besoin pour la suite de la configuration sur l'UDM.
Sur votre contrôleur UniFi, rendez-vous dans "Settings", "Internet" et choisissez de configurer l'accès WAN.
Basculez les réglages avancés en manuel, activez le DHCPv6 pour la connection IPv6, et configurez une taille de délégation de préfixe de 64. Appliquez les changements.
Passons maintenant à la configuration de l'IPv6 pour le réseau local. Toujours dans l'interface du contrôleur UniFi, rendez-vous cette fois dans la partie "Networks" et choisissez de configurer le réseau local.
Si les réglages avancés ne sont pas déjà activées en manuel, c'est le moment de le faire ! Descendez en bas pour configurer l'IPv6, et choisissez de configurer le type d'interface sur "Static". Renseignez en tant que "IPv6 Gateway" le préfixe IPv6 du second "Next Hop" de la Freebox.
Activez le RA (Router Advertisement), qui permet aux périphériques sur le réseau de configurer leur route par défaut automatiquement.
Activez également le DHCPv6, la plage d'adresses se renseignera en se basant sur le préfixe du sous-réseau.
A partir de ce moment, votre réseau est configuré pour fonctionner en IPv6 aussi bien qu'en IPv4, dépendant si les périphériques en sont capables ou non.
Pour vérifier que c'est bien le cas, vous pouvez exécuter un ping en IPv6 ou un nslookup pour résoudre un nom de domaine en IPv6.
guillaume ~ % ping6 google.fr
PING6(56=40+8+8 bytes) 2a01:e0a:99e:ec1:e01e:2d:d5ef:60a1 --> 2a00:1450:4007:809::2003
16 bytes from 2a00:1450:4007:809::2003, icmp_seq=0 hlim=116 time=4.214 ms
16 bytes from 2a00:1450:4007:809::2003, icmp_seq=1 hlim=116 time=4.979 ms
16 bytes from 2a00:1450:4007:809::2003, icmp_seq=2 hlim=116 time=5.454 ms
16 bytes from 2a00:1450:4007:809::2003, icmp_seq=3 hlim=116 time=5.165 ms
--- google.fr ping6 statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 4.214/4.953/5.454/0.459 msguillaume ~ % nslookup -query=AAAA google.fr
Server: 2a01:e0a:99e:ec1::
Address: 2a01:e0a:99e:ec1::#53
Non-authoritative answer:
google.fr has AAAA address 2a00:1450:4007:81a::2003Bon très bien, la connectivité IPv6 fonctionne bien depuis un ordinateur, il reste à tester à nouveau l'application OQEE depuis la TV sous Android TV.
Mince, ça ne fonctionne toujours pas !! Après quelques recherches, et en discutant de ce problème avec un ami, il me dit qu'il a déjà eu le même besoin et avait rencontré le même problème, et qu'il y a un bug dans le firmware UniFi qui fait que le RA n'est pas bien activé, et qu'il faut le forcer à l'aide d'un script.
Le prérequis pour mettre en place ce script est d'avoir installé les scripts udm-utilities de bootschiken, et configuré les "On-Boot-Script".
Si ce n'est pas déjà fait, il vous faudra suivre le tutoriel suivant :
DomoPiHexamusPour configurer ce nouveau script dans le but d'activer le RA correctement sur votre réseau local, accédez en SSH à l'UDM et rendez-vous à l'emplacement habituel des scripts personnalisés avec la commande cd /mnt/data/on_boot.d.
Créez un premier fichier de configuration avec la commande vi ipv6-ra.conf et éditez-le afin d'y coller le contenu suivant :
#
# Generated automatically by ubios-udapi-server
#
# Configuration of DHCP Server 'net_LAN_br0_192-168-1-0-24_IPV6'
no-dhcp-interface=lo
interface=br0
enable-ra
ra-param=br0,high,0
domain=local
dhcp-range=set:net_LAN_br0_192-168-1-0-24_IPV6,IPV6:IPV6::IP,IPV6:IPV6::IP,ra-only,64,86400
dhcp-option=tag:net_LAN_br0_192-168-1-0-24_IPV6,option6:dns-server,[::]Vous pouvez vérifier le contenu du fichier créé par UniFi avec la commande cat /run/dnsmasq.conf.d/dhcp*IPV6.conf. Nous avons seulement rajoutés l'option ra-only dans la configuration DHCPv6.
Le deuxième fichier à créer est le script qui sera exécuté au démarrage de l'UDM. Créez-le avec la commande vi ipv6-ra.sh et collez-y le contenu suivant :
#!/bin/sh
cp /mnt/data/on_boot.d/ipv6-ra.conf /run/dnsmasq.conf.d/dhcp.dhcpServers-net_LAN_br0_192-168-1-0-24_IPV6.conf
start-stop-daemon -K -q -x /usr/sbin/dnsmasqRendez le script exécutable avec la commande chmod +x ipv6-ra.sh et exécutez-le tout de suite avec la commande ./ipv6-ra.sh pour appliquer la configuration.
On redémarre la TV pour forcer une reconnexion au réseau, et on se rend dans les paramètres réseaux pour vérifier qu'elle a bien récupérée une adresse IPv6.
Oui ! C'est bon cette fois !
Lançons OQEE et surtout tentons de visionner une chaîne en direct pour valider le bon fonctionnement :
C'est bon, on peut confirmer que ça fonctionne correctement !
Merci d'avoir lu cet article jusqu'au bout, j'espère qu'il vous aura servi pour configurer votre réseau local en IPv6, et potentiellement pour ceux qui pourraient être concernés, à vous permettre de regarder les chaînes de télévision avec l'application OQEE de Free.
Si vous avez des questions ou simplement souhaitez échanger avec nous, n'hésitez pas à laisser des commentaires ou à venir sur notre groupe Telegram.
Les DNS publics de OpenNIC et de FDN fournissent un bon compromis face aux DNS menteurs de Orange ou de Free.On entend souvent parler d'UPnP (Universal Plug and Play) comme étant un protocole représentant une faille de sécurité béante permettant de changer la configuration du NAT d'à peu près n'importe quel routeur, dans cet article nous détaillerons le fonctionnement de ce protocole afin de mieux comprendre son fonctionnement et la vulnérabilité qu'il représente.
Avant toute chose, il est important de savoir qu'UPnP est un protocole destiné à être utilisé dans les réseaux domestiques et de petites entreprises (les réseaux dits SOHO, Small Office Home Office). Il n'est donc bien souvent pas présent sur les routeurs moins grand publics.
UPnP a été créé afin de faciliter la découverte des différents services sur un réseau, comme les imprimantes, un partage de fichier en réseau etc. Quand un appareil se connecte à un réseau utilisant UPnP, tous ces services sont détectées automatiquement.
Avec UPnP, chaque appareil sur le réseau (appelé périphérique) contient une liste de services ainsi que leurs caractéristiques sous la forme d'un fichier XML. Les chromecast par exemple (petits appareils créés par Google pour pouvoir "envoyer" des vidéos sur sa TV) utilise UPnP pour annoncer sa présence.
<root
xmlns="urn:schemas-upnp-org:device-1-0">
<specVersion>
<major>1</major>
<minor>0</minor>
</specVersion>
<URLBase>http://10.XXX.XXX.XXX:8008</URLBase>
<device>
<deviceType>urn:dial-multiscreen-org:device:dial:1</deviceType>
<friendlyName>XXXXXXXXXX</friendlyName>
<manufacturer>Google Inc.</manufacturer>
<modelName>Eureka Dongle</modelName>
<UDN>uuid:b9c125d5-XXXX-XXXX-XXXX-XXXXXXXXXXXX</UDN>
<iconList>
<icon>
<mimetype>image/webp</mimetype>
<width>98</width>
<height>55</height>
<depth>32</depth>
<url>/setup/icon.webp</url>
</icon>
</iconList>
<serviceList>
<service>
<serviceType>urn:dial-multiscreen-org:service:dial:1</serviceType>
<serviceId>urn:dial-multiscreen-org:serviceId:dial</serviceId>
<controlURL>/ssdp/notfound</controlURL>
<eventSubURL>/ssdp/notfound</eventSubURL>
<SCPDURL>/ssdp/notfound</SCPDURL>
</service>
</serviceList>
</device>
</root>
On voit ici que le périphérique indique son nom, constructeur etc, mais aussi une liste de services, qui ici ne contient qu'un seul service qui ici est le "cast" appelé "dial-multiscreen-org". Comme vous l'avez peut-être remarqué, UPnP utilise HTTP pour récupérer le fichier XML.
Afin de permettre aux périphériques d'annoncer leurs différents services etc, le protocole SSDP est utilisé, ce protocole permet à un élément qu'on appelle le point de contrôle (control point en anglais) de maintenir une liste des différents périphériques UPnP pour que chaque nouvel appareil qui se connecte sur le réseau puisse obtenir l'ensemble des périphériques du réseau sans interroger tous les appareils.
Enfin, tout appareil du réseau compatible peut interagir avec les autres appareils à l'aide du langage SOAP (qui utilise du XML) en passant par le point de contrôle à chaque fois.
Malgré sa praticité et sa relative simplicité, est décrié pour son manque de performance et de sécurité pour diverses raisons :
À cause de ces différents problèmes, UPnP est aujourd'hui peu implémenté et souffre d'une mauvaise réputation.
Il peut être très utile pour un réseau, en entreprise par exemple, d'avoir une certaine redondance. Le DNS ou SLAAC/DHCP sont des protocoles relativement simple à redonder, l'utilisateur prendra le plus rapide cependant pour la route par défaut, souvent appelé passerelle ou gateway il est rarement possible d'avoir plusieurs IPs qui répondent (pour des utilisateurs finaux du moins, pour des routeurs ou serveurs on peut utiliser de l'ECMP). Une technologie a été créée pour pallier ce problème : VRRP.
VRRP fonctionne avec plusieurs routeurs qui partagent une adresse MAC virtuelle. Chaque routeur a une priorité, celui a la priorité la plus haute est le "master".
Pour savoir le status de chaque routeur tous les membres du groupe s'échangent des paquets avec une adresse multicast, si le maitre ne répond plus le routeur avec la deuxième priorité la plus haute va prendre le relai. Leur échanges utilisent un protocole spécifique à VRRP.
Le paquet VRRP est échangé par les routeurs comme dit plus haut en multicast. L'adresse utilisée en IPv6 est FF02:0:0:0:0:0:0:12 et 224.0.0.18 en IPv4.
Le numéro de protocole utilisé pour VRRP est le 112, et le paquet est présenté sur la forme :
Les parties importantes sont :
Nous connaissons tous le protocole TLS, les certificats de TLS se basent sur le bien connu protocole X.509, avec la généralisation de l'utilisation de ce protocole sur Internet, un problème se pose : comment faire en sorte que tous les clients sachent quand un certificat est révoqué ? Afin de répondre à cette question, a été créé le protocole OCSP (Online Certificate Status Protocol).
Un client qui utilise OCSP (tous les navigateurs web récents) va interroger à chaque fois un serveur OCSP (appelé répondeur OCSP) en lui demandant le status dudit certificat (révoqué ou non).
Une requête OCSP ressemble à ça :
Le client indique ensuite des informations qui permettent d'identifier le certificat
Le serveur répond ensuite avec une réponse au format suivant :
Le protocole OCSP est très simple dans son fonctionnement et son concept, mais il est une brique essentielle de la sécurité des certificats TLS que nous utilisons quotidiennement. Il comporte néanmoins un problème majeur, le respect de la vie privée. En effet, le répondeur OSCP pourrait facilement connaître l'ensemble des sites que visite une IP. Pour pallier à cela il existe une technique appelée OCSP Stapling qui permet au serveur web d'envoyer directement la réponse OCSP au client. Ainsi, seul le client et le serveur web sont impliqués dans cet échange.
Dans un précédent article, nous avions étudié le fonctionnement du protocole POP3. Cet article sera dédié à un protocole alternatif à POP3, IMAP.
IMAP (Internet Message Access Protocol) est un protocole créé pour des usages plus avancés que POP3. Il intègre nativement le support des dossiers de mail par exemple. Ci-dessous, un exemple d'échange IMAP4 issu de la RFC que nous allons détailler.
S: * OK [CAPABILITY STARTTLS AUTH=SCRAM-SHA-256 LOGINDISABLED
IMAP4rev2] IMAP4rev2 Service Ready
C: a000 starttls
S: a000 OK Proceed with TLS negotiation
<TLS negotiation>
C: A001 AUTHENTICATE SCRAM-SHA-256 biwsbj11c2VyLHI9ck9wck5HZndFYmVSV2diTkVrcU8=
S: + cj1yT3ByTkdmd0ViZVJXZ2JORWtxTyVodllEcFdVYTJSYVRDQWZ1eEZJbGopaE5sRiRrMCxzPVcyMlphSjBTTlk3c29Fc1VFamI2Z1E9PSxpPTQwOTY=
C: Yz1iaXdzLHI9ck9wck5HZndFYmVSV2diTkVrcU8laHZZRHBXVWEyUmFUQ0FmdXhGSWxqKWhObEYkazAscD1kSHpiWmFwV0lrNGpVaE4rVXRlOXl0YWc5empmTUhnc3FtbWl6N0FuZFZRPQ==
S: + dj02cnJpVFJCaTIzV3BSUi93dHVwK21NaFVaVW4vZEI1bkxUSlJzamw5NUc0PQ==
C:
S: A001 OK SCRAM-SHA-256 authentication successful
C: babc ENABLE IMAP4rev2
S: * ENABLED IMAP4rev2
S: babc OK Some capabilities enabled
C: a002 select inbox
S: * 18 EXISTS
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: * LIST () "/" INBOX ("OLDNAME" ("inbox"))
S: a002 OK [READ-WRITE] SELECT completed
C: a003 fetch 12 full
S: * 12 FETCH (FLAGS (\Seen) INTERNALDATE
"17-Jul-1996 02:44:25 -0700" RFC822.SIZE 4286 ENVELOPE (
"Wed, 17 Jul 1996 02:23:25 -0700 (PDT)"
"IMAP4rev2 WG mtg summary and minutes"
(("Terry Gray" NIL "gray" "cac.washington.edu"))
(("Terry Gray" NIL "gray" "cac.washington.edu"))
(("Terry Gray" NIL "gray" "cac.washington.edu"))
((NIL NIL "imap" "cac.washington.edu"))
((NIL NIL "minutes" "CNRI.Reston.VA.US")
("John Klensin" NIL "KLENSIN" "MIT.EDU")) NIL NIL
"<B27397-0100000@cac.washington.ed>")
BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT"
3028 92))
S: a003 OK FETCH completed
C: a004 fetch 12 body[header]
S: * 12 FETCH (BODY[HEADER] {342}
S: Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT)
S: From: Terry Gray <gray@cac.washington.edu>
S: Subject: IMAP4rev2 WG mtg summary and minutes
S: To: imap@cac.washington.edu
S: cc: minutes@CNRI.Reston.VA.US, John Klensin <KLENSIN@MIT.EDU>
S: Message-Id: <B27397-0100000@cac.washington.edu>
S: MIME-Version: 1.0
S: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
S:
S: )
S: a004 OK FETCH completed
C: a005 store 12 +flags \deleted
S: * 12 FETCH (FLAGS (\Seen \Deleted))
S: a005 OK +FLAGS completed
C: a006 logout
S: * BYE IMAP4rev2 server terminating connection
S: a006 OK LOGOUT completed
Ça fait beaucoup de choses 😅 Détaillons tout ça étape par étape
Ici, le serveur indique les extensions qu'il supporte ainsi que sa version.
Le client lui répond ensuite en indiquant qu'il souhaite utiliser STARTTLS, un échange de clé TLS est initié. Vous avez peut-être remarqué le a000 au début des commandes. Cet identifiant est appelé tag, le client doit en générer un à chaque commande, il permet d'identifier la commande.
S: * OK [CAPABILITY STARTTLS AUTH=SCRAM-SHA-256 LOGINDISABLED
IMAP4rev2] IMAP4rev2 Service Ready
C: a000 starttls
S: a000 OK Proceed with TLS negotiation
<TLS negotiation>
C: A001 AUTHENTICATE SCRAM-SHA-256
biwsbj11c2VyLHI9ck9wck5HZndFYmVSV2diTkVrcU8=
S: + cj1yT3ByTkdmd0ViZVJXZ2JORWtxTyVodllEcFdVYTJSYVRDQWZ1eEZJbGopaE5sRiRrMCxzPVcyMlphSjBTTlk3c29Fc1VFamI2Z1E9PSxpPTQwOTY=
C: Yz1iaXdzLHI9ck9wck5HZndFYmVSV2diTkVrcU8laHZZRHBXVWEyUmFUQ0FmdXhGSWxqKWhObEYkazAscD1kSHpiWmFwV0lrNGpVaE4rVXRlOXl0YWc5empmTUhnc3FtbWl6N0FuZFZRPQ==
S: + dj02cnJpVFJCaTIzV3BSUi93dHVwK21NaFVaVW4vZEI1bkxUSlJzamw5NUc0PQ==
C:
S: A001 OK SCRAM-SHA-256 authentication successful
Tous les champs ci-dessus sont encodés en base 64, la version décodée est ci-dessous
C: A001 AUTHENTICATE SCRAM-SHA-256 n,,n=user,r=rOprNGfwEbeRWgbNEkqO
S: + r=rOprNGfwEbeRWgbNEkqO%hvYDpWUa2RaTCAfuxFIlj)hNlF$k0,s=W22ZaJ0SNY7soEsUEjb6gQ==,i=4096
C: c=biws,r=rOprNGfwEbeRWgbNEkqO%hvYDpWUa2RaTCAfuxFIlj)hNlF$k0,p=dHzbZapWIk4jUhN+Ute9ytag9zjfMHgsqmmiz7AndVQ=
S: + v=6rriTRBi23WpRR/wtup+mMhUZUn/dB5nLTJRsjl95G4=
C:
S: A001 OK SCRAM-SHA-256 authentication successful
Ici le protocole utilisé pour l'authentification est SCRAM-SHA-256, celui ci ne sera pas plus détaillé dans cet article, mais il le sera dans un prochain ;).
C: babc ENABLE IMAP4rev2
S: * ENABLED IMAP4rev2
C: a002 select inbox
S: * 18 EXISTS
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: * LIST () "/" INBOX ("OLDNAME" ("inbox"))
S: a002 OK [READ-WRITE] SELECT completed
Le serveur répond en indiquant, dans l'ordre, les différents Flags, la date, la taille du message en octets, l'enveloppe (qui contient toutes les "métadonnées" du mail, le destinataire, l'objet, la date d'envoi etc.) et le corps du message.
C: a003 fetch 12 full
S: * 12 FETCH (
FLAGS (\Seen)
INTERNALDATE 17-Jul-1996 02:44:25 -0700"
RFC822.SIZE 4286
ENVELOPE (
"Wed, 17 Jul 1996 02:23:25 -0700 (PDT)"
"IMAP4rev2 WG mtg summary and minutes"
(("Terry Gray" NIL "gray" "cac.washington.edu"))
(("Terry Gray" NIL "gray" "cac.washington.edu"))
(("Terry Gray" NIL "gray" "cac.washington.edu"))
((NIL NIL "imap" "cac.washington.edu"))
((NIL NIL "minutes" "CNRI.Reston.VA.US")
("John Klensin" NIL "KLENSIN" "MIT.EDU")) NIL NIL
"<B27397-0100000@cac.washington.ed>"
)
BODY (
"TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028 92)
)
S: a003 OK FETCH completed
Dans la requête suivante, le client demande au serveur de voir le header, le serveur lui renvoie en fait l'enveloppe mais affichée d'une manière différente
C: a004 fetch 12 body[header]
S: * 12 FETCH (BODY[HEADER] {342}
S: Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT)
S: From: Terry Gray <gray@cac.washington.edu>
S: Subject: IMAP4rev2 WG mtg summary and minutes
S: To: imap@cac.washington.edu
S: cc: minutes@CNRI.Reston.VA.US, John Klensin <KLENSIN@MIT.EDU>
S: Message-Id: <B27397-0100000@cac.washington.edu>
S: MIME-Version: 1.0
S: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
S:
S: )
S: a004 OK FETCH completed
C: a005 store 12 +flags \deleted
S: * 12 FETCH (FLAGS (\Seen \Deleted))
S: a005 OK +FLAGS completed
Voilà cet échange déchiffré, comme vous avez pu le voir, IMAP embarque des fonctionnalités supplémentaires par rapport à POP3, comme les Flags. Niveau sécurité, IMAP propose en plus de STARTTLS un port dédié aux communications chiffrées, le port 993, un sysadmin soucieux de la confidentialité des mails échangés sur son réseau pourrait donc bloquer le port 143 (port par défaut d'IMAP) pour forcer à passer par le port 993, et donc par une communication chiffrée. Une telle pratique peut néanmoins poser d'évidents problèmes de compatibilité. Il n'existe pas avec IMAP de mécanisme semblable avec DMARC pour qu'un serveur puisse forcer ses clients à utiliser une connexion chiffrée.
Nous avons vu dans une série de trois précédents articles ¹ ² ³ le protocole SMTP et tous (ou presque 😉) les processus autour de l'envoi de mails. Maintenant qu'on sait envoyer des mails, ce serait intéressant de pouvoir les lire n'est-ce pas ? 😄 Cet article s'intéressera au protocole POP3 qui a été conçu à cet effet, un autre sera dédié à IMAP.
POP3 (Post Office Protocol version 3) tout comme SMTP, POP3 est une protocole plutôt simple.
Un échange typique ressemble à cela :
S: <wait for connection on TCP port 110>
C: <open connection>
S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us>
C: APOP mrose 682949bee6805d9b611b82395e342cad
S: +OK mrose's maildrop has 2 messages (320 octets)
C: STAT
S: +OK 2 320
C: LIST
S: +OK 2 messages (320 octets)
S: 1 120
S: 2 200
S: .
C: RETR 1
S: +OK 120 octets
S: <the POP3 server sends message 1>
S: .
C: DELE 1
S: +OK message 1 deleted
C: RETR 2
S: +OK 200 octets
S: <the POP3 server sends message 2>
S: .
C: DELE 2
S: +OK message 2 deleted
C: QUIT
S: +OK dewey POP3 server signing off (maildrop empty)
C: <close connection>
S: <wait for next connection>
Détaillons les différentes commandes utilisées ici :
<1896.697170952@dbc.mtview.ca.us>mrosepass.Comme vous pouvez le voir, à l'instar de SMTP, POP3 est un protocole vraiment simple dans son fonctionnement. Afin d'ajouter une couche de sécurité supplémentaire, supporte STARTTLS, mais tout comme avec SMTP, STARTTLS pose un problème, il est dit "opportuniste". Ceci signifie que quand STARTTLS est présent, il ne rend pas obligatoire l'utilisation de TLS.
La simplicité de POP3 est à la fois une force, et une tare, une force en ce qu'elle permet aux implémentations de ce protocole d'être légères, et une tare car ce protocole ne correspond pas aux besoin des utilisateurs une utilisation plus poussées des mail, cette simplicité apporte aussi un niveau de sécurité critiquable. Au vu de ces éléments un protocole alternatif a été créé, IMAP, que nous verrons de plus près dans un prochain article.
Dans un précédent article, nous avions vu comment fonctionne SMTP, mais aussi comment sécuriser les échanges entre les appareils qui utilisent ce protocole. Aujourd'hui nous regarderons comment empêcher l'usurpation (spoofing) d'adresse email avec SMTP.
DKIM (DomainKeys Identified Mail) est sûrement le protocole le plus connu quand on parle d'empêcher l'usurpation d'adresse mail. C'est un protocole qui s'appuie sur la cryptographie asymétrique (le plus souvent RSA) afin de signer certaines parties d'un mail.
Un header DKIM ressemble à ça :
DKIM-Signature:
v=1;
a=rsa-sha256;
c=relaxed/relaxed;
d=ilearned.eu;
s=gm1;
t=1637402778;
h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
to:to:cc:mime-version:mime-version:content-type:content-type:
content-transfer-encoding:content-transfer-encoding;
bh=jkYhN5eG70Kk/sFVzVJcKR3X2zwf3jR4Ui9PYcA/0b0=;
b=ky1aAlPLJLL7xDCTgvPe+KMvtqBovXeKl6vzcT3vTd/uQAndwkzYegVvrKVdI2JxdGSVJ8
otZ2ksJ+x6yUvPGwwN9tGcLq5cMmYNM6D8uYR7vYIm7gR8YnLohASnPFs87EpLAH0ue32L
FDbnjbMh7eNZNK6WWrfRzATKYGFqMAyBiJOKPy8KybqulFtpII5V4rHbahpL+zI6EfDBXP
Hro15OxGwfgp6oGUeu+1tyEEwu845h/Ftw4LP2vywMvPNS5PwTMEaytXrRfop7MX7Min4B
y80e2ySYjAFI098fOoYTHeS6afLWbC7jRhBZ291BghmeADX8JUn853dsMekqdQ==
v correspond à la version utiliséea correspond à l'algorithme utiliséd au nom de domaine pour lequel l'authentification a été validées est le sélecteur, c'est en cherchant un enregistrement TXT pour s._domainkey.d (ici gm1._domainkey.ilearned.eu) que l'on trouve la clé publique du serveur qui a validé le mail.╰─$ dig gm1._domainkey.ilearned.eu TXT
;; ANSWER SECTION:
gm1._domainkey.ilearned.eu. 10800 IN CNAME gm1.gandimail.net.
gm1.gandimail.net. 1800 IN TXT "v=DKIM1; h=sha256; k=rsa;" "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAp8Mks4TXRqy7GjW3uIN2pfL+lnTNzEBYnYvoh9WbYseieVQIysX3tAPFz3oCoPlANa31gj/slInQVi" "B6tVb59Sw2loR1MS7HGp8g/5LaNI7KIdojiTDalLJCi4VK4Kw6eOIE/dAM/qKe3KrvU2EvSfVeU/emXU/B483vgWLWbakyiMekQN6mc+JZkegcmefambtVxrYqLswQLM9EwQ4fQPI/x8H067cOZfOe" "jPF3+a+uwbjOC8x5xVfAsNMjFmNDYoKaSjxcrX0fw54p/+5N1ciKdN7mCqsXrtb3ZRwn6TddzJR6ji0ID8fV4Y8/nUhLftsD4FRw54p7Hd3Ds1UseQIDAQAB"
h correspond aux entêtes (headers) qui ont été signésbh correspond au hash du corps du messageb correspond enfin au corps du courriel ainsi que les entêtes signésQuand le serveur SMTP de destination reçoit le courriel, il vérifie avec la clé publique présente dans l'enregistrement DNS vu ce-dessus que la signature est correcte. Si elle ne l'est pas, il peut décider de simplement supprimer le message, ou de le placer dans les spams.
SPF (Sender Policy Framework) est un protocole plus simple dans son fonctionnement que DKIM mais qui propose aussi un niveau de protection contre l'usurpation d'adresse mail satisfaisant. Avec SPF, un enregistrement DNS TXT est publié dans la zone du nom de domaine d'envoi. Ce record contient une liste d'adresses IPs (de MTA) autorisées à envoyer des courriels. Voici par exemple l'enregistrement pour la zone eff.org
eff.org. 7200 IN TXT "v=spf1 mx ip4:173.239.79.202 include:spf1.eff.org include:spf2.eff.org include:spf.protection.outlook.com include:salsalabs.org -all"
Plusieurs règles sont définies ici
mx Autorise si le nom de domaine contient un enregistrement MX pointant vers l'adresse IP de l'expéditeur. Ici l'enregistrement MX correspond à eff-org.mail.protection.outlook.com qui renvoie vers l'IP 104.47.55.138, cette IP est donc autorisée à envoyer des mails @eff.org.ip4 Autorise si l'adresse de l'expéditeur correspond à 173.239.79.202 dans notre cas.include inclue les règles contenues dans le domaine indiqué.spf1.eff.org. 7200 IN TXT "v=spf1 ip4:50.28.103.180 ip4:50.28.103.181 ip4:67.212.170.242 ?ip4:128.199.236.247 ?ip4:38.229.72.13 ?ip4:165.117.251.93 ?ip4:38.99.228.141 ?ip4:78.47.153.197 -all"
spf2.eff.org. 7200 IN TXT "v=spf1 ?include:amazonses.com -all"
salsalabs.org. 300 IN TXT "v=spf1 ip4:204.28.10.0/23 ip4:69.174.82.0/23 ip4:147.253.0.0/16 ip4:192.174.0.0/16 ip4:156.70.0.0/16 -all"
Comme on peut le voir, en allant interroger les différents noms de domaines inclus, de nombreuses autres adresses IPv4 sont autorisées, et on trouve une autre inclusion vers amazonses.com
amazonses.com. 900 IN TXT "v=spf1 ip4:199.255.192.0/22 ip4:199.127.232.0/22 ip4:54.240.0.0/18 ip4:69.169.224.0/20 ip4:23.249.208.0/20 ip4:23.251.224.0/19 ip4:76.223.176.0/20 ip4:54.240.64.0/19 ip4:54.240.96.0/19 ip4:52.82.172.0/22 -all"
Et voilà, nous avons remonté l'ensemble des adresses IPs autorisées pour le domaine eff.org 😅.
-all indique que si l'adresse IP ne correspond pas, le mail doit être rejeté. D'autres signes avant le all auraient pu indiquer d'autres actions+ : laisser passer le mail? : résultat neutre, comportement différent selon les logiciels utilisés~ : c'est le softfail les messages qui retournent un softfail sont acceptés, cet échec est cependant indiqué par le client mail- : le mail est rejeté, c'est ce qui est utilisé ici avec le -allL'utilisation de SPF et de DKIM n'a cessé de croitre ces dernières années, et afin d'homogénéiser l'utilisation de ces deux protocoles, et la réponse en cas de non-satisfaction de ceux-ci, un nouveau standard a été créé. DMARC (Domain-based Message Authentication, Reporting and Conformance) est un enregistrement DNS TXT dans _dmarc.NDD qui spécifie ces différents comportements. Reprenons notre exemple avec eff.org :
_dmarc.eff.org. 7200 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc_rua@eff.org; ruf=mailto:dmarc_ruf@eff.org;"
p : que faire en cas d'échec de SPF/DKIMnone : aucune action de la part du receveur n'est requise.quarantine : le receveur doit traiter ce message comme "suspicieux" en le plaçant dans les spams par exemple.reject : le receveur doit rejeter le message.rua correspond à l'URI où un rapport doit être envoyé en cas d'échec de SPF/DKIM.ruf correspond à l'URI où un rapport détaillé doit être envoyé.C'est sur cet article que s'achève notre série de trois articles dédiés à l'envoi de mails, j'espère qu'ils vous auront plu. Si vous avez des questions/remarques, n'hésitez pas à nous en faire part dans l'espace commentaire ci-dessous.
Dans un précédent article nous avions abordé le fonctionnement de SMTP, aujourd'hui nous verrons les différents moyens de sécuriser ce protocole.
STARTTLS est une "extension" de SMTP qui permet de communiquer de façon chiffrée avec les serveur SMTP en utilisant TLS. Elle est définie dans la RFC 320. Avec STARTTLS, l'utilisation de TLS n'est pas rendue obligatoire, elle est simplement possible pour les clients/serveurs qui le supportent. De cette non-obligation découle une problématique, étant donné que l'échange initial (le EHLO) qui indique les extensions supportées est envoyé en clair, il est trivial pour un attaquant de modifier les paquets d'initialisation de la connexion pour désactiver STARTTLS. Cette extension, standardisée en 2002, apporte donc une certaine avancée, mais n'est pas suffisant.
MTA-STS est une mécanisme standardisé en 2018 qui permet à un serveur de spécifier à l'avance s'il supporte l'utilisation de TLS en plaçant un record TXT dans la zone du MTA (Mail Transfer Agent).
_mta-sts.example.com. IN TXT "v=STSv1; id=20160831085700Z;"
Dans cet exemple v correspond à la version de MTA-STS utilisée, et id à l'ID de la policy.
La policy, c'est un fichier placé à l'URI [https://mta-sts.example.com/.well-known/mta-sts.txt](https://mta-sts.example.com/.well-known/mta-sts.txt) qui spécifie
TLSRPT.mx spécifie les mx qui peuvent être utilisésmax_age correspond au temps maximal (en secondes) que doit être conservé en cache cette policy.version: STSv1
mode: enforce
mx: mail.example.com
mx: *.example.net
mx: backupmx.example.com
max_age: 604800
STARTTLS couplé à MTA-STS permettent donc de garantir un niveau de confidentialité satisfaisant entre les serveurs SMTP.
Nous avons vu comment sécuriser la communication entre les différents acteurs d'un envoi de mail avec SMTP, mais pas comment authentifier l'utilisateur auprès du serveur, pour cela a été créé l'extension SMTP-AUTH.
S: 220 smtp.example.com ESMTP Server
C: EHLO client.example.com
S: 250-smtp.example.com Hello client.example.com
S: 250-AUTH GSSAPI DIGEST-MD5
S: 250-ENHANCEDSTATUSCODES
S: 250 STARTTLS
C: STARTTLS
S: 220 Ready to start TLS
... TLS negotiation proceeds.
Further commands protected by TLS layer ...
C: EHLO client.example.com
S: 250-smtp.example.com Hello client.example.com
S: 250 AUTH GSSAPI DIGEST-MD5 PLAIN
C: AUTH PLAIN dGVzdAB0ZXN0ADEyMzQ=
S: 235 2.7.0 Authentication successful
Dans cet exemple, de l'authentification en "Plaintext" est utilisé, ce qui signifie que le mot de passe est envoyé tel quel simplement encodé en base64. Une fois de plus on peut remarquer la simplicité du protocole SMTP.
Cette extension permet donc d'authentifier les clients, mais aucunement de garantir une protection contre l'usurpation d'adresse mail. C'est un sujet plutôt complexe et qui n'est pas directement lié à SMTP que nous aborderons dans les prochains jours !
Pour pouvoir communiquer entre des machines d’un réseau IP il est requis de posséder une adresse IP dans le réseau, une méthode simple serait que chaque machine du réseau ait une adresse fixe configurée par l’utilisateur, mais cela serait vite fastidieux et un utilisateur ne connaissant pas à l’avance le réseau serait vite bloqué. Une solution est d’avoir un protocole permettant de distribuer automatiquement aux machines une adresse via un protocole fait pour. Nous avions déjà parlé dans un article précédent de SLAAC, ici nous aborderons DHCP.
DHCP est majoritairement utilisé en IPv4, bien qu'il soit utilisable en IPv6. À la différence de SLAAC il est dit avec état, c'est-à-dire qu'un serveur central est requis pour attribuer et retenir l'IP de chaque appareil connecté au réseau.
Comme dit plus haut, ce n'est pas la machine qui choisit son IP, mais un serveur central. Le serveur peut attribuer de plusieurs manières, il peut soit, donner dynamiquement selon un pool réservé pour les hôtes (dans l'ordre logique, ou aléatoirement) ou bien en fonction de la machine qui demande. L'identification de la machine se fait généralement via l'adresse MAC. La plupart des serveurs DHCP retiennent les précédentes attribution pour redonner si possible la même adresse si une même machine demande. Les données envoyées via le serveur DHCP on une durée de bail (lease) avant que le client redemande les informations.
Le serveur DHCP peut distribuer d'autre configuration, sous forme d'"option", par exemple le résolveur DNS ou le nom de domaine utilisé pour le réseau local. Il existe vraiment beaucoup d'option officielle et non officielle exploitée.
Le client DHCP peut aussi envoyer différentes options au serveur, comme son nom d’hôte, ou bien des options personnalisées pour s'authentifier auprès du serveur DHCP.
Pour recevoir un bail DHCP le client va diffuser en "broadcast" (à tous les hôtes du réseau) sa requête, le serveur DHCP va donc recevoir aussi le paquet et lui répondre.
Pour le renouvellement le processus change un peu, le client qui connait déjà le serveur lui demandera directement et n'enverra plus à tout le réseau.
Le processus de demande en IPv6 est sensiblement différent et ressemble dans la forme à SLAAC. Au lieu de passer par un broadcast la demande est envoyée en multicast à ff02::1:2 qui identifie les serveurs ou relais (explication plus loin). Le serveur répondra su l'IP de lien local de la machine qui demande.
J'ai évoqué plus haut le concept de relai DHCP, c'est un moyen d'utiliser un serveur DHCP dans un seul réseau pour plusieurs réseaux. Comme on l'a vu plus haut le DHCP exploite des adresses qui ne fonctionnent que pour une machine dans le même réseau, mais comment employer un seul serveur DHCP pour plusieurs réseaux ? Avec un relai DHCP justement, le principe est d'en avoir un par réseau (sur un routeur par exemple, ça a l'avantage d'être plus léger et ne pas demander de stockage persistant contrairement à un serveur complet), il va récupérer les demandes DHCP envoyées en broadcast pour renvoyer à un serveur DHCP, pour permettre au serveur d'identifier il va exploiter l'IP de l'interface où est arrivé le paquet comme IP source.
Nous utilisons les mails quotidiennement, mais savons-nous seulement comment fonctionnent les protocoles qui sous-tendent ce service ? Vous trouverez dans ce calendrier de l'Avent de décembre un ensemble d'articles répondants à cette question. Aujourd'hui nous aborderons le protocole SMTP.
SMTP (Simple Mail Transfer Protocol) est un très ancien protocole qui a été standardisé pour la première fois en 1981, soit un an avant que le minitel soit présenté au grand publique en France ! De par son ancienneté, il hérite aussi d'une certaine simplicité. La communication avec SMTP s'organise autour de cinq acteurs majeurs :
Les agents de dépôt (MSA) et de transfert (MTA) sont, notamment dans les petites infrastructures, regroupés sur une seule machine, mais sur de plus grosses infrastructures ils peuvent être séparés notamment pour assurer une plus grande disponibilité du service.
Afin de trouver à quel échangeur de mail s'adresser, le MTA (agent de transfert) exploite le DNS et cherche un enregistrement MX dans la zone du nom de domaine de destination.
Plus concrètement, un exemple simple d'envoi de mail a lieu comme suit :
Comme on a pu le voir, SMTP est un protocole plutôt simple dans son fonctionnement, néanmoins, cette simplicité n'est pas sans conséquence, elle implique un manque certain de sécurité. Afin de pallier à ces problèmes, un certain nombre de solutions ont été mises en place, nous les aborderons dans un prochain article.
