Mise en place d'un réseau

M 1-IN FO Rése aux année 2011/2012 TP Infrastructure réseaux et sécurité Le but de ce TP est de mettre un place un réseau de machines et d'expérimenter des cas concrets de problèmes liés à la sécurité et la mise à disposition de ressources. Le TP sera coupé en deux parties, et vous devez vous répartir en deux groupes de taille équivalente. Dans la première partie du TP, vous effectuerez les manipulations dans chacun des deux sousgroupes. La deuxième partie du TP à pour but d'interconnecter les deux sous-réseaux implantés par chacun des sous-groupes. Vous devez tout au long de ce TP noter, sur une feuille, le plan d'adressage du réseau de votre groupe, les serveurs hébergés sur chaque machine ainsi que toutes les informations utiles pour réinstaller votre réseau à l'identique. Vous y écrirez également les réponses aux questions qui vous seront posées tout au long de ce TP. Mise en place d'un réseau Pour cette première partie, vous devez être répartis en deux groupes et avoir un «hub» ou un «switch» à disposition. Lorsqu'il sera nécessaire d'installer des paquets supplémentaires sur votre machine, il faudra penser à vous «extraire» du hub pour vous reconnecter sur le réseau de l'université. 1 Plan d'adressage et résolution de noms Dans un premier temps, vous allez décider d'un masque de réseau pour votre groupe (il faudra qu'il soit différent de celui de l'autre groupe) puis vous allez vous attribuer une adresse IP unique dans votre réseau. Vérifiez que vous arrivez à effectuer un «ping» sur chacune des machines de votre réseau. Pour automatiser cette tâche lorsqu'une nouvelle machine se connecte, vous allez mettre en place un serveur DHCP qui attribuera automatiquement une adresse IP disponible lorsqu'une nouvelle machine se connectera au réseau. De plus vous allez également intégrer un serveur DNS permettant de résoudre des noms de machines dans votre réseau. Le paquet «dnsmasq» permet d'installer facilement un serveur DHCP+DNS. Pour configurer correctement dnsmasq, il faudra positionner les attributs suivants : domain-needed dhcp-range=xxxxxx avec une durée d'une heure pour la réinitialisation dhcp-option=option:dns-server,xxxxx dhcp-host=xxxxxx Pour chacune des balises ci-dessus, vous devez vous documenter sur leur utilisation et justifier leur nécessité ici. À partir de maintenant, quand vous devrez accéder à une machine de votre groupe, vous utiliserez le nom référencé dans le serveur DNS et non plus l'ip directement. 2 Mise en place d'un serveur ssh Il est courant de retrouver un serveur ssh dans un réseau. Cela permet d'accéder et d'administrer une machine à distance sans se retrouver physiquement devant elle. Choisissez une personne de votre groupe pour héberger un serveur ssh. Le paquet openssh-server installe un serveur ssh opérationnel directement. Il ne reste plus qu'à l'administrateur du serveur qu'à créer un compte utilisateur pour chaque personne de son groupe. Chaque personne du groupe doit pouvoir se connecter sur le serveur. Pour cela, il faudra qu'il saisisse son nom d'utilisateur et son mot de passe. Question : Que se passe-t-il si une personne malhonnête se fait passer pour votre serveur ssh? Quelles informations sera-t-il capable de récupérer si vous vous faites tromper? Pour éviter ce type de problème nous allons sécuriser l'accès au serveur un se basant sur un échange de clefs. Le principe est simple, vous allez générer une clé privée ainsi que la clé publique associée. Quelqu'un en possession de votre clé publique est capable de vérifier votre identité. Pour 1/5

cela, il décide d'un message aléatoire qu'il encode avec votre clé publique. Étant le seul possesseur de votre clé publique, vous serez le seul capable de décoder le message. En comparant le message décodé avec l'original, le serveur est capable de valider votre accès. Si un serveur se fait passer pour votre serveur ssh habituel, il ne possédera pas votre clé publique et donc sera incapable de chiffrer un message à votre attention. Il faut sécuriser vos clés le plus possible! Votre clé privée doit être connue de vous seul et ne doit jamais être communiquée à un tiers. Votre clé publique doit être transmise au serveur par un moyen sécurisé, puis les droits sur celle-ci doivent être restreints à minima. Question : Comment s'assurer que sa clé publique ne peut pas être récupérée par un autre utilisateur du même serveur? Générez le couple clé privée/clé publique sur votre machine, puis transmettez votre clé publique au serveur ssh (vous pouvez utiliser une clé USB par exemple). Vérifiez que vous pouvez vous connecter sans mot de passe et que vous n'avez pas accès à la clé publique des autres utilisateurs de la machine. La génération et l'utilisation de ces clés est un point important de la sécurité dans un réseau. Pensez à faire de même pour les comptes ssh que vous possédez et à conserver vos couples de clés dans des endroits sûr comme vous le feriez pour des mots de passe. 3 Mise en place d'un serveur web Continuons la mise en place de notre réseau. Vous allez maintenant installer sur chaque machine du réseau un serveur web. Pour cela vous pouvez installer «apache» qui est un serveur web reconnu et installé en exploitation sur un grand nombre de serveurs de part le monde. Une fois qu'une personne de votre groupe a fini d'installer son serveur apache, tous les autres membres doivent vérifier que le serveur est accessible et que la page par défaut s'affiche bien dans votre client http. Personnalisez votre page par défaut en y ajoutant votre nom pour que les personnes de votre groupe aient la confirmation visuelle que c'est bien votre serveur web auquel ils sont en train d'accéder. Cas d'école : Choisissez un membre de votre réseau qui jouera le rôle du site d'une banque. Pour cela, la personne modifiera sa page par défaut de son serveur apache pour qu'il y ait le nom de la banque écrit dessus. De plus, une nouvelle entrée «ma-banque» sera ajouté dans le DNS pour accéder au serveur. Les autres membres de votre groupe doivent pouvoir accéder au serveur web ma-banque et voir la page s'afficher. Choisissez un autre membre de votre groupe qui modifiera sa page par défaut pour qu'elle soit identique à celle de ma-banque. Ajoutez maintenant une nouvelle entrée dans le DNS «mabanque» de telle sorte que cette entrée pointe sur le faux serveur. Que se passe-t-il si des utilisateurs étourdis se trompent d'url et atterrissent par inadvertance sur le faux serveur? Question : Comment s'appelle cette malveillance basée sur l'inattention de l'utilisateur? Pour sécuriser l'accès à des sites Internet, il faut vérifier avant d'accéder au site que celui-ci a été validé par une autorité de régulation. En certifiant un serveur par une autorité de régulation et en cryptant les communications on garantit la sécurité de la connexion. C'est une des raisons de l'utilisation du protocole https au lieu de http sur Internet pour les connexions nécessitant un haut niveau de sécurité. 4 Mise en place d'un serveur sécurisé Pour crypter les échanges d'informations entre un serveur et un client, un algorithme de chiffrement asymétrique est souvent la meilleur solution. Ce mode de chiffrement est basé sur le partage entre différents utilisateurs d'une clé publique (la clé privée n'est jamais communiqué et est conservé par l'utilisateur pour lequel elle a été générée). Pour le serveur ssh, c'est l'utilisateur qui utilise un moyen «sur» comme une clé USB pour déposer sa clé publique sur le serveur. Mais dans le cadre de l'accès à un site web, c'est plus problématique. Pour pouvoir communiquer avec un serveur web en cryptant les informations de sorte que seul le serveur soit capable de les lire, il nous faut récupérer sa clé publique. Celle-ci nous permettra d'encrypter des données et de les faire transiter sur Internet de telle sorte que seul le détenteur de la clé privée soit capable de les décrypter. Problème : comment être sûr que c'est bien la bonne clé publique que l'on récupère? Si par mégarde on récupère la clé publique d'un pirate, on cryptera des données sensibles en pensant, à tort, qu'elle ne seront lisibles que par le serveur web que l'on 2/5

cherche à contacter. Solution : faire signer la clé publique du serveur par un organisme référant dans le monde entier et vérifier auprès de lui que cette clé est bien celle du serveur avec lequel on souhaite échanger des informations. C'est le «certificat». Un certificat sont des petits fichiers composés de deux parties : La partie contenant les informations (version de la norme X.509, numéro de série, algorithme de chiffrement, nom, dates, clé publique du propriétaire, signature de l'émetteur ). La partie contenant la signature de l'autorité de régulation. La signature de l'autorité de régulation correspond au chiffrement des informations du certificat (ou plutôt du résultat d'une fonction de hachage lancée sur les informations) avec la clé privée de l'autorité de régulation (connue uniquement de l'autorité). La clé publique de l'autorité de régulation, quant à elle, est largement distribuée. Lorsqu'un utilisateur se connectera sur un site web sécurisé, il récupérera le certificat envoyé par celui-ci. Pour vérifier sa validité, il utilisera la clé publique de l'autorité de régulation pour déchiffrer la signature du certificat et vérifier que les informations correspondent bien à celles fournies par le certificat (ou plutôt au hachage des informations). Il existe deux catégories de certificats : Les «certificats auto-signés». Destinés à un usage interne, ils sont signés par un serveur interne et permet de garantir la sécurité des échanges d'informations dans son propre réseau local (chez soi, ou dans une petite entreprise). Cela revient à se créer sa propre autorité de régulation. Les «certificats signés par un organisme de certification». Destinés à un usage publique, comme la connexion sur des sites web accessibles au grand public, ils sont signés par un organisme certificateur connu et reconnu. Les certificats servent principalement pour : Identifier un utilisateur et lui octroyer certains droits (certificat client). Garantir l'identité d'un serveur et de sécuriser les transactions (certificat serveur). Chiffrer les connexions dans VPN (certificat client + certificat serveur). 3/5

Vous allez maintenant mettre en place votre propre autorité de régulation (une par groupe) en utilisant les outils fournis par openssl. Il faut donc créer les fichiers que l'on nommera ca.key (la clé privée) et ca.crt (le certificat incluant la clé publique) qui seront associés à notre autorité de régulation. Le certificat de l'autorité peut être distribuée à tous les demandeurs potentiels, la clé privée ne doit jamais être communiquée. Il faut maintenant créer un certificat pour le serveur web de notre banque qui sera signé par notre autorité de régulation. La première étape est de générer une clé privée pour notre serveur web. Puis il faut faire une demande de certificat (génération d'un fichier.csr) en renseignant les informations demandées (ici surtout le Common Name qu'il faut renseigner avec le nom de la machine résolu dans le DNS). Il reste enfin à faire signer cette demande par l'autorité de régulation (grâce à clé privée et le certificat préalablement créés pour l'autorité). Le résultat de cette étape est un fichier.crt qui contient les informations du certificat ainsi que la signature de l'autorité. Question : Comment voir et vérifier le contenu d'un certificat? Il faut maintenant paramétrer le serveur web de votre banque pour qu'il prenne en compte ce certificat. Il faut renseigner les fichiers de configuration pour qu'ils prennent en compte le certificat sans oublier de redémarrer le serveur web. Indication : Pour apache, il est demandé de fournir un fichier.pem et non pas un couple.key/.crt. Un fichier.pem est en fait le résultat de la concaténation des fichiers.key et.crt. Ce fichier est facilement obtenu de la manière suivante : mv apache2.key apache2.pem cat apache2.crt >> apache2.pem Distribuer sur les clients le certificat de l'autorité de régulation et retester la connexion au serveur ma-banque. Qu'observez-vous si le certificat de l'autorité de régulation n'est pas enregistré sur votre client? Il se passera la même chose si vous vous connecté sur un serveur pour lequel le certificat n'a pas été signé par une autorité de régulation que vous avez reconnue. Question : Comment le serveur peut-il envoyer des données sécurisées (donc cryptées) au client qui vient de se connecter? Inter-connecter des réseaux Dans cette partie, nous allons connecter les réseaux des différents groupes ensembles. Tout d'abord, choisissez une machine dans chaque réseau qui fera office de passerelle. Connectez les interfaces réseaux supplémentaires en USB sur les passerelles. Décidez ensemble d'un plan d'adressage pour que les plages d'adresses dans les sous-réseaux soient différentes de celles utilisées pour les adresses des interfaces publiques des passerelles. Les adresses des interfaces publiques seront paramétrées manuellement sans utilisation de DHCP. 1 Routage et accès ssh Vérifiez que chaque passerelle puisse bien accéder aux autres. Maintenant, mettre en place un routage permettant aux machines d'un sous réseau d'accéder uniquement au serveur ssh des autres sous-réseaux. Même si le serveur ssh d'un sous réseau est accessible aux autres, n'ayant pas de compte, aucun des utilisateurs des autres sous réseaux ne peut se connecter sur un serveur ssh d'un autre sous-réseau. Chaque personne d'un sous réseau (hormis la passerelle, le serveur ssh et le serveur web mabanque) doit alternativement (chacun son tour) se débrancher de son sous réseau et se brancher dans un autre sous-réseau. Il doit être capable de se connecter sur le serveur ssh de son sousréseau initial, mais pas sur le serveur ma-banque de son sous-réseau. Pour se connecter sur le serveur ma-banque de son sous-réseau d'origine, il doit mettre en place un «tunnel ssh» faisant intervenir : sa propre machine, le serveur ssh de son réseau d'origine et le serveur web ma-banque de son sous-réseau d'origine. 2 Mise en place d'un VPN Établir des tunnels ssh pour chaque service auquel on souhaite accéder dans un autre sous-réseau n'est pas la manière la plus pratique de procéder. Une autre solution consiste à mettre en place un réseau privé virtuel (VPN) qui permettra à une machine non physiquement dans un réseau d'être 4/5

reconnu comme membre à part entière. La machine ainsi connecté sera considérée comme tout autre machine du réseau! Que chacun regagne son sous-réseau d'origine! Choisissez parmi vous une machine qui hébergera le serveur VPN de votre sous-réseau. Installer les paquets d'openvpn permettant d'installer et de configurer des clients et des serveurs pour OpenVPN. OpenVPN est un VPN, il en existe d'autres, mais celui-ci à l'avantage d'être disponible sur plusieurs plateformes et reste facilement configurable. Pour utiliser un VPN, il faut générer plusieurs certificats : Un certificat pour le serveur VPN. Généré de la manière que pour le serveur web, mais il faut rajouter une extension X.509 NsCertTypeServer qui indique que c'est un certificat pour un serveur (regarder les options -extfile et -extensions de openssl). Un certificat par client qui sera autorisé à se connecter sur le serveur. La clé privée sera conservée par le client, le certificat des clients sera conservé sur le serveur pour authentifier le client. Il faut donc que vous accomplissez ces phases puis distribuiez les certificats aux différents clients (sans oublié les clés privées). Le certificat de l'autorité de régulation doit déjà être présent chez chaque client car il est le même que pour l'étape précédente avec le serveur web. Mettre maintenant une règle de routage pour que le serveur VPN soit accessible depuis les réseaux extérieurs. Il reste maintenant à configurer correctement le serveur VPN pour que les clients puissent s'y connecter puis accéder aux différentes ressources du réseau. Pour cela, plusieurs points doivent retenir votre attention : Placer les certificats du serveur des clients dans les répertoires appropriés d'openvpn. Rediriger tout le trafic du client dans le VPN (regarder la directive push "redirect-gateway def1") Paramétrer le DHCP d'openvpn pour les clients se connectant. Mettre en place les règles de routage sur le serveur VPN (le serveur VPN se comportera comme une passerelle du réseau virtuelle vers le sous-réseau physique). Tour à tour (sauf le serveur VPN et la passerelle de votre sous-réseau), débranchez-vous de votre réseau et allez vous brancher à un autre sous-réseau. Connectez-vous sur le serveur VPN de votre sous-réseau et vérifiez que vous accédez bien aux ressources disponibles dans votre sous-réseau d'origine. 5/5