Auto Hébergement et Raspberry Pi
←
→
Transcription du contenu de la page
Si votre navigateur ne rend pas la page correctement, lisez s'il vous plaît le contenu de la page ci-dessous
Table des matières État du lard..................................................................................................................... 4 Glossaire de la documentation....................................................................................... 5 Rendre les services accessibles de l'Internet..................................................................6 Les ports..................................................................................................................... 6 Le système..................................................................................................................... 8 Préparation du Raspberry........................................................................................... 8 Système d'exploitation........................................................................................... 8 Réseau.................................................................................................................. 10 Le fichier /etc/hostname...................................................................................10 Le fichier /etc/hosts.......................................................................................... 10 Le stockage.............................................................................................................. 11 Connexion SSH et sécurité....................................................................................... 15 Changer le port d'écoute depuis Internet.............................................................15 Désactiver le compte Root................................................................................... 15 Gérer la connexion SSH par clé............................................................................ 16 Bannir les intrus : Fail2Ban................................................................................... 18 Un nom de domaine ?................................................................................................... 19 Registrar................................................................................................................... 19 Gestion sur le web.................................................................................................... 19 Gestion dynamique.................................................................................................. 22 Création des champs nécessaires............................................................................ 24 Gestion en local........................................................................................................ 25 WebServices................................................................................................................. 26 Installation d'un serveur web : Lighttpd...................................................................26 Gestion du service.................................................................................................... 27 Envie d'un site ?....................................................................................................... 28 Installation de GetSimple CMS..............................................................................28 Installation de PluXML.......................................................................................... 31 Courrier électronique.................................................................................................... 32 Envoyer des messages électroniques.......................................................................32 Configuration du système pour la messagerie.....................................................32 Création des utilisateurs...................................................................................33 Création des Alias............................................................................................. 33 Installation et paramétrage de Postfix..................................................................34 Installation et paramétrage de Dovecot...............................................................40 Consulter les courriers électroniques.......................................................................42 Configuration d'un logiciel de messagerie............................................................42 Configuration de Thunderbird...........................................................................42 Configuration d'Evolution................................................................................. 42 Configuration d'Outlook....................................................................................42 Installation et paramétrage d'HastyMail2.............................................................43 Installation et paramétrage de SquirrelMail..........................................................44 Antispam - Antivirus................................................................................................. 44 Contacts & tâches........................................................................................................ 45 Installer et configurer Baikal Server.........................................................................45 Configuration de Thunderbird................................................................................... 47 Paramétrage du calendrier...................................................................................47 Paramétrage des contacts.................................................................................... 48 Configuration d'Evolution......................................................................................... 48 Paramétrage du calendrier...................................................................................48 #Autohebergement Emmanuel Le Nohaïc http://lacavernedemanu.fr
Paramétrage des contacts.................................................................................... 50 Configuration d'Android............................................................................................ 50 Paramétrage du calendrier...................................................................................51 Paramétrage des contacts.................................................................................... 51 Sauvegarde.................................................................................................................. 53 Automatisation......................................................................................................... 53 Tester une remontée................................................................................................. 53 #Autohebergement Emmanuel Le Nohaïc http://lacavernedemanu.fr
État du lard L'écriture de ce « livre » m'est venue un jour ou je me demandais « comment pourrais je contribuer à l'avancée de l'auto-hébergement ». N'étant ni codeur dans l'âme (encore que pour de petits services personnels), ni développeur web je ne me voyais pas proposé un outil bugué ou incomplet à la communauté, d’où ce petit livre. Les écrits et exemples que vous trouverez au travers de ces quelques pages ne seront pas exempts d'erreurs ou pourront aussi être complétés par des personnes plus avisées que moi sur certains sujets. L'auto-hébergement est un fait d'actualité dans les sphères geek aujourd'hui, de par la liberté que cela apporte mais aussi à cause des différentes affaires telles que Prism ou encore l'article 20 de la Loi de Programmation Militaire qui ont fait l'actualité ces derniers temps. Toutes ces lois et textes mis en place ne poussent que vers une seule chose : chiffrer et toujours chiffrer plus. J'essaierais dans ces quelques lignes d'apporter mes connaissances en la matière et ainsi permettre à chacun de disposer de son propre serveur, autonome et « sécurisé ». Ceci dit, l'auto hébergement n'est pas une chose super fun quand tout tombe en rade, et ça arrive bien plus souvent qu'on ne le pense. Ici je vais tenter de relater les aventures et configurations que j'ai été amené à produire pour mon mini serveur à la maison, un Raspberry Pi 256Mo. De plus, l'auto-hébergement n'est pas si « gratuit » que cela, en effet une connexion internet est nécessaire, une machine, une seconde pour de la redondance si jamais on le souhaite ainsi que de la sauvegarde. Même si toutes ces variables semblent « gratuites » car vous disposez de machines en spare, une connexion internet partagée légalement avec le voisin ou encore un lecteur de bandes pour archiver vos données ; Le coût en temps est monstrueux et pousse même à parfois s'arracher les cheveux jusqu'à ce qu'une nuit vous vous réveilliez en percutant ce qui bloque depuis 3 jours. Et oui c'était ce foutu smtpd_recipient_restrictions dans Postfix auquel vous aviez mis une condition avant l'autre (Ca n'arrivera pas ici, je me suis assez cassé les dents dessus !;) ). Qui dit Raspberry Pi dit carte SD, écritures régulières, crash, lenteur etc. L'installation sur ce type de machine est chronophage, il faut du temps et il faut vouloir y passer du temps. Ceci dit (une fois de plus !) il existe des distributions déjà toutes prêtes à l'emploi qui ont été pensée et développées par des personnes souhaitant partager leurs connaissances et techniques pour apporter au plus grand nombre l'hébergement facile, je pense particulièrement au projet Yunohost (http://yunohost.org) mais aussi à bien d'autres, Google pourra le trouver facilement pour vous. Pour finir, cette documentation a été faite sur base de connaissances personnelles acquises tant bien que mal sur la plupart du temps (libre ! :)). En aucuns cas je ne peux me proclamer comme étant omniscient et il se pourrait donc qu'un à un moment donné cette doc soit obsolète ou non à jour ou encore truffée d'erreur. Cette documentation se veut être la plus claire possible et la plus vulgarisante, je l'ai clairement orientée avec des points de vue et échange de ma part de façon à guider le débutant et ne pas le perdre en cours de route. Je comprends tout à fait que les confirmés passent leur chemin et ne prennent pas le temps de s'attarder ici. La doc est plus longue que ce que j'avais initialement prévu de par les avis que je laisse avant ou après chaque manipulation. Cela ne sera que ma modique contribution à un sujet qui me tient à cœur, ne m'en tenez pas rigueur et apportez les modifications que vous souhaitez à cette documentation, que chacun puisse en profiter. En vous souhaitant une bonne lecture. #Autohebergement Emmanuel Le Nohaïc http://lacavernedemanu.fr
Glossaire de la documentation Tout au long de la doc, j'essayerais d'être « uniforme ». J'entends par là que j'essayerais tant bien que mal de conserver le même langage et les mêmes expressions avec par exemple • http://ndd.tld → Représente l'adresse de votre serveur sous la forme FQDN (ex : http://google.fr) • http://10.10.10.251 → Représente l'adresse de votre serveur via son IP • rpi → Représente RaspberryPi en abrégé, mais vous l'aurez remarqué Dans certains fichiers de configuration j'utiliserai des nom et / ou logins génériques. Ceux ci seront tout à fait utilisable mais ne seront pas obligatoires et pourront bien évidemment être changés selon les goûts. Afin d'éviter des erreurs de copier / coller ou autres, les principaux fichiers de configurations nécessaire au bon fonctionnement seront fournis dans l'archive qui contient ce document mis à part les fichiers demandant des modifications mineures. Ceci dit ces fichiers seront tout de même détaillés (tant bien que mal parfois) autant que possible afin de comprendre leurs contenus et leurs fonctions. Le contenu indiqué de couleur orange et encadré indiquera au cours de la documentation que nous nous trouvons dans un terminal en mode administration du serveur. Dans ce contenu je surligne en gras des informations qui ne sont pas forcément à conserver, qui peuvent être adaptées comme des identifiants ou encore des noms de groupe. Je vous inviterais d'ailleurs à ne pas forcément copier / coller les lignes de commande afin d'éviter d'éventuelles erreurs dues au retour à la ligne forcé par LibreOffice et qui n'est pas forcément le cas dans le terminal ou vous travaillerez. Le contenu indiqué de couleur rouge et encadré représentera une sorte de synthèse ou rappel concernant la partie active de la documentation. Toutes les manipulations et paramétrages sont faits avec l'utilisateur root. J'aborderai au cours de la doc une partie sécurité quant à la connexion via SSH et nous verrons aussi comment gérer la connexion par clé afin de supprimer le couple login / mot de passe et aussi pour renforcer la sécurité. En avant ! #Autohebergement Emmanuel Le Nohaïc http://lacavernedemanu.fr
Rendre les services accessibles de l'Internet Une partie « masquée » de l'auto-hébergement est de rendre les services accessibles depuis Internet. Ici une sérieuse barrière se pose devant nous, la box de l'opérateur. Pas de soucis ils ont (dans la plupart des cas) pensé aux gentils bonhommes qui utilisent leur propre serveur à la maison et permettent donc de rediriger le trafic entrant vers une ou plusieurs machines sur notre réseau. Il faut bien entendu savoir que les opérateurs (même en 2013 et 2014) qui fournissent une adresse IP publique fixe avec un reverse configurable sont rares : • OVH • Free • […] Rattrapez moi si j'en oublie. Je suis personnellement chez SFR et tout se passe bien malgré le fait que je ne dispose pas d'adresse IP publique fixe. Le tout moyennant quelques bidouillages plus ou moins honteux mais on fait avec les moyens du bord (moyens qui seront abordés dans cette documentation plus tard). Les ports Les ports sont ce que l'on peut ramener aux portes d'une maison pour une image que tout le monde pourra s'imaginer. En effet comme pour une maison, chaque ouverture sert à quelque chose. La porte d'entrée s'ouvre pour le facteur qui vient vous livrer votre Raspberry, la porte du garage s'ouvre pour la voiture etc. Nous aurons bien compris que la porte d'entrée, la porte du garage et la fenêtre des wc reçoivent des flux. Ces flux peuvent être du web, du mail, du ftp, du ssh etc. Voici un petit récapitulatif non exhaustif des ports : • 80/443 → http / https • 25 / 465 → smtp / smtps • 22 → ssh • 143 / 993 → imap / imaps • 20 / 21 → FTP Il est donc important de saisir le but des ports. En effet, derrière chaque port accessible se trouve un service qui écoute et attend des requêtes. Le serveur dispose de ports mais la box aussi, et c'est à la box que le trafic entrant à destination du serveur s'adressera en premier. La box étant par défaut « sécurisée » ne laissera pas entrer le trafic dont elle ne connaît pas l'origine ni la destination et ne saura de toute façon pas vers quelle machine rediriger ce trafic. Pour rendre l'installation accessible il sera donc nécessaire d'ouvrir presque tous les ports cités précédemment à savoir ssh, smtp, smtps, imaps, http et https etc. à destination du serveur. Je ne détaillerais pas ici comment ouvrir ou rediriger un port sur une box opérateur, de multitudes de documentations sont disponibles sur Internet pour cela. Il faudra cependant penser lorsque vous ferez la redirection des ports à déterminer quelle sera l'adresse IP locale (192.168.1.x ou toute autre adresse) de votre serveur afin que le trafic soit correctement acheminé et vous y tenir tout au long de la documentation. #Autohebergement Emmanuel Le Nohaïc http://lacavernedemanu.fr
Le système Sur le Raspberry Pi, une installation du système est faisable sur un disque dur USB mais je n'aborderais pas cette technique dans ces pages, ne l'ayant pas mise en place chez moi je ne sais pas de quoi il en retourne et cela ne m'intéresse pas. Si la carte SD du Pi flambe, je balance l'image système que j'ai faite au préalable dans une autre SD et tout repart (10€ de spare on a connu pire). Une carte SD n'est pas faite à proprement parler pour encaisser des écritures en continu. Or tout OS Linux garde trace de manière régulière de ce qu'il se passe dans le système et écrit donc les logs. J'ai choisir de brancher un disque dur usb du rpi. J'ai ainsi monté /var de manière automatique sur le disque mécanique, afin de réduire les écritures sur la SD et apporter un peu de souffle à la machine en terme d'espace de stockage. Si votre installation ne se fait pas sur un raspberry pi vous pouvez tout de même suivre cette documentation, les installations et configurations sont identiques. Cependant vous pouvez déjà passer à la partie webservices. Préparation du Raspberry Une fois de plus, si vous faites votre installation sur autre chose qu'un raspberry ou une autre machine n'utilisant pas de cartes SD, passez au prochain chapitre :). Je ne détaillerai pas ici la méthode pour préparer la carte SD sous Windows, ne disposant pas de ce type de système actuellement, je ne peux l'expliquer. Cependant ce lien : http://computers.tutsplus.com/articles/how-to-flash-an-sd-card-for-raspberry-pi--mac- 53600 Ou encore une recherche avec « write raspberry pi image sd card windows » sur notre ami Google devrait aider à trouver la solution. Système d'exploitation Il faut donc télécharger l'image du système ici : http://downloads.raspberrypi.org/raspbian_latest Une fois l'image téléchargée on la dézippe, on écrit le contenu du .img obtenu sur la carte SD. unzip 2013-05-25-wheezy-raspbian.zip dd bs=4M if=2013-05-25-wheezy-raspbian.zip of=/dev/mmcblk0 sync Notre carte SD est donc prête à être insérée dans le rpi, on peut donc lancer la bête. Si comme moi vous ne disposez pas d'écran à brancher sur la bête, vous pouvez lancer un scan du réseau pour récupérer l'adresse ip attribuée par le serveur dhcp. nmap 192.168.1.* Si 192.168.1.0 est l'adresse de votre réseau Nmap scan report for raspberrypi (192.168.1.179) Host is up (0.0026s latency). Not shown : 999 closed ports PORT STATE SERVICE 22/tcp open ssh #Autohebergement Emmanuel Le Nohaïc http://lacavernedemanu.fr
On peut donc se connecter en SSH (login : pi – mdp : raspberry) sur la machine et commencer l'administration. Celle-ci est assez intuitive et se fait relativement simplement, on accède au menu de paramétrage en tapant : sudo raspi-config De multiples paramètres sont accessibles via le menu qui s'affiche. On peut commencer par 1 Expand Filesystem qui va nous permettre d'exploiter la taille totale de la carte SD. On pourra ensuite paramétrer la langue du pi 4 Internationalisation Options Change Locale Puis on choisit fr_FR.UTF8 UTF-8 et on valide tout en confirmant fr comme langue par défaut. On configure ensuite le « split » mémoire, à savoir la quantité de ram que l'on va allouer au gpu. 8 Advanced Options A3 Memory Split Sur mon pi 256M j'ai choisi de n'allouer que 16M de ram au GPU, soit le maximum pour le système. On peut ensuite sortir du menu et redémarrer le pi : Finish reboot Réseau Nous aborderons ici la configuration de fichiers réseau tels que /etc/hostname et /etc/hosts. Ces deux fichiers sont importants et sont nécessaires au bon fonctionnement du serveur. Le fichier /etc/hostname Ce fichier intègre le FQDN (Fully Qualified Domain Name) de notre machine. On y retrouve donc par exemple mail.ndd.tld Le fichier /etc/hosts Ce fichier sert de « résolveur » DNS. A savoir que le système d'exploitation viendra se renseigner dans ce fichier afin d'obtenir l'adresse ip d'un hôte sur le réseau à partir de son nom avant d'aller demander l'information à un serveur DNS tiers. #Autohebergement Emmanuel Le Nohaïc http://lacavernedemanu.fr
Plusieurs services peuvent s'appuyer sur ce fichier et le système même vient interroger la configuration pour récupérer des adresses ip. Ci dessous le contenu d'un fichier /etc/hosts d'une machine située derrière une box 127.0.0.1 localhost 10.10.10.251 mail.ndd.tld sv 127.0.1.1 mail.ndd.tld Le fichier interfaces Il est pertinent de fixer une adresse ip fixe à la machine qui va héberger nos services. Sous Debian ça se fait dans /etc/network/interfaces auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 10.10.10.251 netmask 255.255.255.0 gateway 10.10.10.1 dns-nameservers 10.10.10.1 194.2.0.20 network 10.10.10.0 broadcast 10.10.10.255 Bien entendu la configuration mise en gras est à appliquer selon votre configuration. L'adresse IP choisie ici correspond à mon plan d'adressage sur mon réseau @ home. Il est fort probable que votre plan d'adressage soit du type 192.168.1.x ou 192.168.0.x. La configuration de l'interface serait donc plutôt du type auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 192.168.1.251 netmask 255.255.255.0 gateway 192.168.1.1 dns-nameservers 192.168.1.1 194.2.0.20 network 192.168.1.0 broadcast 192.168.1.255 Il est aussi important de déterminer un nom d'hôte à votre goût et qui vous parle. Ce nom n'est aucunement indicatif quant à la configuration de vos services mais peut être quelque chose comme mail.ndd.tld Comme le service le plus « important » est l'hébergement des mails, j'ai personnellement choisi de le nommer mail.ndd.tld Pour modifier le hostname du pi, il faut éditer le fichier /etc/hostname dans lequel on indiquera le nom sous la forme FQDN (Fully Qualified Domain Name) mail.ndd.tld #Autohebergement Emmanuel Le Nohaïc http://lacavernedemanu.fr
Le stockage Comme mentionné dans la page servant d'introduction au départ, l'espace de stockage qui accueillera les données sera monté sur un autre disque. Nous bénéficierons ainsi d'un stockage mécanique plus performant et plus « sécurisé » dans le temps que la carte SD. Toutefois si vous souhaitez conserver le service sur la carte SD, vous pouvez passer à la partie Nom de domaine. Après avoir branché le disque dur, préparez vous à créer une nouvelle partition puis un nouveau système de fichier et enfin à automatiser le montage du disque et /var sur celui-ci pour qu'à chaque démarrage l'espace de stockage soit monté. On commence par identifier le disque dur sur lequel on veut travailler fdisk -l Va nous permettre d'afficher les disques connectés au système. Chez moi le résultat ressemble à ceci Disk /dev/mmcblk0: 16.6 GB, 16642998272 bytes 4 heads, 16 sectors/track, 507904 cylinders, total 32505856 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x000c7b31 Device Boot Start End Blocks Id System /dev/mmcblk0p1 8192 122879 57344 c W95 FAT32 (LBA) /dev/mmcblk0p2 122880 32505855 16191488 83 Linux Disk /dev/sda: 160.0 GB, 160041885696 bytes 81 heads, 63 sectors/track, 61254 cylinders, total 312581808 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x000bcb59 Device Boot Start End Blocks Id System /dev/sda1 2048 312581807 156289880 83 Linux Le disque dur est /dev/sda, c'est sur ce disque que nous allons créer la partition fdisk /dev/sda fdisk est l'utilitaire qui va créer la partition Un prompt va s'afficher et demander une saisie : • m → Affiche l'aide • n → Crée une nouvelle partition • […] Ici un second prompt attend une réponse : #Autohebergement Emmanuel Le Nohaïc http://lacavernedemanu.fr
• p → Crée une partition primaire • 1 → Saisir un numéro de partition (Le plus souvent par défaut) • Start Cylinder → Entrée • Last Cylinder → Entrée • w → Ecrit les changements sur le disque La partition est maintenant créée. Il faut encore créer le système de fichier. Pour créer le système de fichier, il nous faut la lettre du disque et le numéro de la partition précédemment créée. Ici sûrement /dev/sda1 Création du système de fichier mkfs.ext4 /dev/sda1 On peut maintenant créer un répertoire dans /mnt pour monter le système de fichier mkdir /mnt/storage De nos jours il n'est plus forcément nécessaire de saisir le type de système de fichiers que l'on monte, le système d'exploitation peut détecter le type dont il s'agit et ainsi s'adapter. mount /dev/sda1 /mnt/storage Ou mount -t ext4 /dev/sda1 /mnt/storage Il suffit ensuite d'afficher l'espace disque pour se rendre compte que le disque est bien là df -h Sys. fich. Taille Util. Dispo Uti% Monté sur rootfs 16G 2,0G 13G 14% / /dev/root 16G 2,0G 13G 14% / devtmpfs 108M 0 108M 0% /dev tmpfs 24M 252K 23M 2% /run tmpfs 5,0M 0 5,0M 0% /run/lock tmpfs 47M 0 47M 0% /run/shm /dev/mmcblk0p1 56M 19M 38M 33% /boot /dev/sda1 147G 13G 127G 9% /mnt/storage A ce stade, la partition ne sera pas automatiquement montée au prochain redémarrage. Pour ce faire il faut renseigner le fichier /etc/fstab avec l'UUID de la partition et aussi le point de montage. UUID.. J'ai encore entendu il y a peu de temps que ça ne servait pas et qu'on pouvait continuer à utiliser l'identifiant de la partition de type sdx, ce qui n'est pas fondamentalement faux, mais il vaut clairement mieux utiliser l'UUID. En effet, l'UUID est un identifiant unique permettant d'identifier une partition. (Des informations ici https://help.ubuntu.com/community/UsingUUID). Il est donc préférable et recommandé d'utiliser ces UUID plutôt que /dev/sdX car en cas de changement de #Autohebergement Emmanuel Le Nohaïc http://lacavernedemanu.fr
disque dur ou par hasard inversion de ports sur la carte mère, le système serait susceptible de ne plus retrouver ses petits au redémarrage. Il est donc nécessaire d'identifier la partition ls -l /dev/disk/by-uuid Ici cette commande me renvoie lrwxrwxrwx 1 root root 10 nov. 27 23:17 f4b67733-3194-45fa-bd21-e304c9559978 -> ../../sda1 Le code en gras est l'uuid de ma partition Il faut ensuite aller éditer le fichier /etc/fstab pour y ajouter nos informations à la dernière ligne UUID="f4b67733-3194-45fa-bd21-e304c9559978" /mnt/storage ext4 defaults,noatime 0 1 Maintenant la partition sera montée automatiquement à chaque démarrage. Il est possible de s'en assurer en tapant la commande mount qui si tout se passe bien ne doit rien renvoyer à l'écran. Et pour s'en assurer définitivement, un petit reboot puis df -h une fois relogué. Il nous reste (c'est fini ensuite pour cette partie) à créer des liens depuis /var/ • www • log • sqlite • apt_cache Pour y arriver, il faudra déplacer les répertoires souhaités en temps voulu. Toutefois si au cours de la documentation j'oublie de le spécifier, je vais tenter d'expliquer la manipulation ici. Historiquement les données du serveur web sont stockées dans /var/www/ mais nous souhaitons les déplacer sur le disque dur prévu à cet effet. On commence donc par déplacer le répertoire mv /var/www/ /mnt/storage/ Puis on va créer le lien depuis le nouvel emplacement vers l'ancien afin de « feinter » au système que les données n'ont pas bougées d'endroit. Pour cela on utilise la commande ln -s avec en premier la source du lien et ensuite la destination vers laquelle on souhaite faire pointer le lien, ici ln -s /mnt/storage/www/ /var/ On peut donc faire des tests en créant un fichier dans /var/www/ puis en listant le répertoire sur le disque dur /mnt/storage/www/ touch /var/www/toto ls -l /mnt/storage/www/ #Autohebergement Emmanuel Le Nohaïc http://lacavernedemanu.fr
-rw-r--r-- 1 root root 0 déc. 2 23:44 toto Le fichier est bien sur le disque dur, le lien symbolique fonctionne. Il suffit maintenant de répéter l'opération pour log et sqlite si l'on souhaite y stocker nos base de données sQlite (Baikal + CMS.) La configuration du système est terminée. Le serveur peut maintenant commencer à accueillir nos services. Pour cette partie de la documentation, d'autres sources concernant le paramétrage du Raspberry sont disponibles sur Internet si j'avais oublié quelques configurations. Connexion SSH et sécurité Il est possible de se connecter en SSH en local comme depuis l'Internet sur notre serveur. SSH présente des avantages qui ne sont plus à présenter pour l'administration d'un serveur. Dans la documentation qui suit concernant SSH, nous allons voir plusieurs méthodes qui seront compatibles ou non entre elles. En effet, le port d'écoute public par exemple n'impactera aucunement l'authentification, qu'elle soit par clé ou couple login / mot de passe. Toutefois le fait de forcer l'authentification par clé désactivera tout autre moyen de connexion et rendra inutile la configuration d'un groupe spécial ainsi que d'un utilisateur spécial. A chacun d'adapter cette configuration selon ses propres besoins, ici rien n'est forcé ni obligatoire ;). A noter tout de même que si seule l'authentification par clé est configurée, vous devrez vous munir de votre clé privée sur tous les postes depuis lesquels vous souhaiterez vous connecter. Changer le port d'écoute depuis Internet Historiquement le démon SSH tourne sur le port 22, on « camoufle » généralement ce port en en utilisant un tout autre pour éviter les tentatives de connexion sur ce service. Il existe deux sons de cloche concernant cette habitude, ceux qui partent du principe que la sécurité est assurée même sur le port 22 et les autres. Je fais personnellement partie du second groupe, je préfère ajouter cette « barrière », ça ne coûte rien et ça peut freiner les petits malins. Cette fonction de redirection de port est assurée par la box ou routeur qui est en front de votre connexion Internet. Le démon en local écoutera toujours sur le même port mais c'est la box qui lorsqu'elle recevra une requête sur le port par exemple 54321 qui redirigera sur le port 22 de la machine. A savoir donc si vous souhaitez employer cette technique, ici rien d'obligatoire. La configuration abordée ici est un premier pas (à mon sens) pour éviter de se faire scanner en permanence et aussi pour palier aux connexions intempestives. Le choix de changer le port public de connexion dépend de chacun, ici pas d'obligations une fois de plus. Désactiver le compte Root Par défaut tous les utilisateurs du système sont autorisés à se connecter en SSH. Cela ne pose pas de problème en soit excepté si le compte que vous utilisez se voit compromis, qui plus est si ce compte est root. Pour palier à ce problème plusieurs options sont envisageables. La première est de désactiver le compte root dans la configuration du serveur SSH. On pourra ensuite créer un groupe spécial et y ajouter un nouvel utilisateur avec lequel on ne fera que se connecter à distance sur le système pour ensuite passer Root. #Autohebergement Emmanuel Le Nohaïc http://lacavernedemanu.fr
Pour désactiver la connexion de root nano /etc/ssh/sshd_config PermitRootLogin no Ne pas appliquer la configuration tout de suite sous risque de se couper la main. Nous allons maintenant créer un groupe « spécial SSH » pour y ajouter le compte « spécial SSH » qui sera un compte qui ne servira qu'à se connecter au système et avec lequel nous élèverons les droits à root. Le groupe et l'utilisateur indiqués dans les lignes suivantes sont à adapter selon votre choix groupadd sshpowerusers useradd -m -s /bin/bash mysshuser gpasswd -a mysshuser sshpowerusers Puis à la fin du fichier /etc/ssh/sshd_config on vient indiquer la ligne suivante pour autoriser la connexion du groupe sshpowerusers AllowGroups sshpowerusers Avant de se déconnecter et de se reconnecter en SSH avec le nouvel utilisateur, il convient de modifier son mot de passe passwd mysshuser Puis on redémarre le serveur ssh et on se déconnecte /etc/init.d/ssh restart exit Si vous vous déconnectez vous ne pourrez pas vous reconnecter en root. Dorénavant la connexion se fera avec l'utilisateur mysshuser. Cet environnement nous servira à nous authentifier avec l'utilisateur root une fois la connexion établie. La configuration abordée ici pourra servir à se connecter à distance depuis un poste qui ne disposera pas de la clé privée que nous allons créer dans la suite de la configuration SSH. Toutefois la connexion par clé est à privilégier par rapport à la méthode de groupe. A chacun d'y trouver son usage. Gérer la connexion SSH par clé La connexion par clé présente plusieurs avantages, en effet nous pourrons nous connecter au serveur sans avoir à rentrer à chaque fois le couple login / mot de passe mais il est aussi possible de forcer chaque utilisateur à se connecter via cette méthode et ainsi désactiver la connexion par login afin de renforcer la sécurité du système. Dans cette partie je n'aborderais que la configuration d'un client Linux, plus tard viendra sûrement cet aspect de la configuration dans un environnement Microsoft. Comme nous avons configuré un utilisateur dans la partie précédente, j'ai pris le parti de continuer la documentation avec cet utilisateur pour nous connecter par clé et ensuite nous authentifier avec le compte root. On commence par créer une clé sur le système client depuis lequel nous nous connecterons au serveur. Laisser les champs par défaut lors de la création. #Autohebergement Emmanuel Le Nohaïc http://lacavernedemanu.fr
ssh-keygen -t dsa Enter file in which to save the key (/root/.ssh/id_dsa): Created directory '/root/.ssh'. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /root/.ssh/id_dsa. Your public key has been saved in /root/.ssh/id_dsa.pub. The key fingerprint is: 00:3f:e9:21:26:5e:df:55:91:06:1f:cf:7e:93:62:c9 root@manulaptop The key's randomart image is: +--[ DSA 1024]----+ | . ..+o | | o . oo+ | | . + * ... o | | . + + = . ... .| | . o S E.o.| | . ...| | | | | | | +-----------------+ Aperçu du processus de création de clé Nous allons maintenant copier la clé publique sur le serveur afin de pouvoir nous y connecter. L'adresse IP du serveur est à modifier ici aussi en fonction de la configuration. ssh-copy-id -i .ssh/id_dsa.pub mysshuser@mail.ndd.tld Ici le mot de passe root sera demandé à la première connexion puis vous serez invité à vous connecter au serveur pour essayer la connexion sans mot de passe. Jusqu'ici, la connexion par login / mot de passe fonctionne toujours. Il est possible de désactiver cette fonction afin de n'autoriser que l'authentification par clé (Non obligatoire). nano /etc/ssh/sshd_config Puis on décommente et on passe la ligne suivante à No qui indique que l'on refuse les connexions par mot de passe #PasswordAuthentication yes à PasswordAuthentication no Puis on redémarre le serveur SSH /etc/init.d/ssh restart #Autohebergement Emmanuel Le Nohaïc http://lacavernedemanu.fr
On peut maintenant essayer de se connecter avec n'importe quel compte, la connexion sera refusée. Permission denied (publickey). La configuration abordée dans les lignes précédentes est la plus restrictive pour les connexions extérieures. En effet il nous faudra disposer de la clé privée afin de nous connecter. Toute altération de la clé nous sera ainsi signalée par le système afin de par exemple prévenir d'une attaque de type Man In the Middle. Bannir les intrus : Fail2Ban Fail2ban est un puissant analyseur de logs. L'outil passe son temps à analyser les logs qu'on lui soumet dans la configuration et peut ainsi détecter si un nombre important de connexions a lieu sur un service et peut ainsi bannir l'adresse IP distante pour un certain temps. J'avais configuré il y a longtemps Fail2ban sur mon Pi en m'appuyant sur la documentation de Maylug http://www.maylug.org/wiki/doku.php?id=documentation:fail2ban Je vous invite à suivre cette doc qui est facile d'accès plutôt que la reproduire ici :). #Autohebergement Emmanuel Le Nohaïc http://lacavernedemanu.fr
Un nom de domaine ? Un nom de domaine sera clairement utile pour joindre les différents services, qui plus est si vous ne disposez pas comme moi d'adresse ip publique fixe. Le nom de domaine peut être personnalisé à souhait surtout que maintenant il est possible d'utiliser des caractères spéciaux et bientôt des .bzh (dédicace:)), des .paris etc. Registrar Plusieurs fournisseurs peuvent vous fournir un nom de domaine avec plus ou moins de services : protection contre le vol, masquage de vos informations etc. Mon nom de domaine est enregistré chez OVH historiquement le fournisseur chez lequel j'avais tous mes services hébergés. (3 noms de domaines + 2 serveurs dédiés fut une époque = avant le rapatriement de mes services @ home:)). OVH fournit un service de DNS dynamique, ce qui veut dire que si vous ne disposez pas d'adresse IP fixe vous pourrez mettre vos enregistrements à jour dynamiquement et de manière automatisée sans avoir donc à vous poser la question si votre box à changée d'adresse ou autres soucis liés à cette problématique. Vous pouvez néanmoins obtenir votre nom de domaine chez Online.net ou encore 1and1. D'autres registrars sont disponibles sur Internet mais ce n'est pas l'objet de la documentation ici. Dans les parties dédiées au DNS qui suivent je parlerais exclusivement de la configuration via le manager OVH. Si votre nom de domaine n'est pas enregistré chez ce fournisseur, vous pourrez passer à la suite de la documentation après avoir bien sur fait des recherches sur les DNS dynamiques chez les autres registrars. Gestion sur le web OVH met à disposition de ses services un manager qui sert à configurer la totalité des services. Ainsi en mode graphique il est facilement possible de configurer sa propre zone DNS depuis l'interface web. Pour se connecter sur l'interface de configuration, c'est ici : https://www.ovh.com/managerv3/ L'interface ressemble normalement (elle peut changer) à la capture d'écran suivante Pour configurer la zone, il faut sélectionner le service soit dans l’ascenseur situé en haut de la page ou alors dans la colonne de gauche du manager puis suivre les captures d'écran suivantes #Autohebergement Emmanuel Le Nohaïc http://lacavernedemanu.fr
On trouvera sur la capture d'écran suivante l'interface nécessaire à la configuration de notre zone et à l'édition des nombreux champs nécessaires Il peut être nécessaire de « faire le ménage » dans la configuration DNS fournie par OVH. Dans la capture d'écran précédente on peut voir qu'il existe une fonction pour Réinitialiser le Domaine. La « procédure » pour faire cette réinitialisation est détaillée dans la capture suivante #Autohebergement Emmanuel Le Nohaïc http://lacavernedemanu.fr
Après quelques secondes, la zone est réinitialisée, on va pouvoir commencer la configuration. Les champs crées sont fictifs et sont la à titre indicatif excepté pour les champs NS qui sont absolument à conserver dans notre cas. On peut donc supprimer les champs CNAME et MX pour partir d'une configuration vierge. Le champs A ne peut être supprimé et pour cause, nous allons le modifier pour le « transformer » en champs DynHost afin de pouvoir le mettre à jour régulièrement. Dans le manager, cliquer sur le bouton de modification du champs de type A (Le bouton se trouve en face de l'enregistrement). Dans le menu qui s'affiche, activer les fonctions et remplir les champs comme indiqué dans la capture d'écran qui suite. L'adresse 1.2.3.4 est volontairement indiquée, nous verrons ainsi plus facilement l'impact sur la configuration lors de la mise à jour dynamique via le script détaillé plus loin dans cette documentation. (Ne pas oublier de valider:)). Sur l'écran suivant, nous allons configurer l'identifiant et le mot de passe nécessaire à la mise à jour de notre enregistrement. Bien entendu l'identifiant choisi dans cette procédure n'est là qu'à titre indicatif, vous pourrez en choisir un tout autre sans soucis. Évitez tout de même les caractères spéciaux. L'identifiant sera donc du type ndd.tld-identifiantchoisi. #Autohebergement Emmanuel Le Nohaïc http://lacavernedemanu.fr
L'écran suivant confirme la création de l'identifiant. En nous rendant à nouveau dans le détail de la zone DNS, on peut voir que le champs de type A est maintenant modifié en champs de type DynHost et l'enregistrement est 1.2.3.4. La configuration de la zone DNS est maintenant « presque » terminée. Il nous reste à gérer la mise à jour dynamique du champs. Gestion dynamique La gestion dynamique est autonome. Moyennant quelques configurations, la solution une fois en place ne consomme presque pas de ressources et les mises à jour se font de manière totalement transparentes. Pour commencer quelques explications. OVH met à disposition des clients de nom de domaine une connexion à leur infrastructure afin de permettre les mises à jour « automatiques ». C'est cette fonction que nous allons aborder ici. La documentation technique est disponible ici : http://guides.ovh.com/DynDns ou encore là : http://www.funtaff.com/software/addns.pl/ pour la configuration du script que nous allons utiliser. La configuration se fait en plusieurs étapes : création des fichiers de configuration pus automatisation du tout. On commence par créer le fichier de configuration principal dans /etc/ et on y copie / colle le contenu suivant (Bien faire attention aux guillemets quand nécessaire). nano /etc/addns.conf [webcheck] { server_host = www.ovh.com update_host = ndd.tld detect_method = "webcheck" ip_detect_host = "checkip.dyndns.org" ip_detect_port = 80 username = "ndd.tld-identifiant" password = "mot_de_passe_ovh" } Les champs marqués en gras sont à adapter à votre configuration Puis copier / coller le script addns.pl contenu dans le dossier de cette documentation. Si celui-ci est altéré ou absent, il est possible d'obtenir la dernière version du script à cette adresse http://www.funtaff.com/software/addns.pl/addns-1.2a.tar.gz Il faut ensuite rendre le script exécutable chmod +x /etc/addns.pl Le script a besoin d'un fichier log ou stocker les différents échanges, on va donc le créer touch /var/log/addns.log #Autohebergement Emmanuel Le Nohaïc http://lacavernedemanu.fr
Il faudra ensuite se rendre dans le répertoire /etc/ puis exécuter le script cd /etc/ ./addns.pl La mise à jour doit normalement se faire. Vous devrez voir la capture d'écran suivante dans votre terminal ainsi que le champs mis à jour après avoir rafraîchit la page du manager OVH. La partie mise à jour automatique est terminée, le restant de notre configuration se basera sur l’enregistrement DynHost pour la totalité de nos services (mail : champs MX, et des alias de type CNAME). Création des champs nécessaires Différents champs seront nécessaires pour la suite de la documentation. Les champs MX serviront à la configuration mail et les alias CNAME serviront à rediriger les requêtes d'une manière plus « parlante ». Il sera par exemple envisageable de diriger les requêtes à destination du webmail vers l'url https://webmail.ndd.tld ou encore les requêtes à destination d'un blog vers http://blog.ndd.tld. Cette configuration se fera au niveau du DNS de la même manière que pour la création du champs DynHost. Dans le manager OVH, il faudra commencer par créer un enregistrement de type CNAME avec comme valeur mail.ndd.tld comme indiqué dans la capture d'écran suivante Une fois l'enregistrement crée, on va pouvoir créer le champs MX nécessaire au routage des courriers électroniques. De la même manière dans le manager, sélectionner le Type MX puis remplir les champs comme indiqué ci- dessous #Autohebergement Emmanuel Le Nohaïc http://lacavernedemanu.fr
Une fois l'opération validée, on se retrouve donc avec les champs dans l'ordre .ndd.tld NS ns100.ovh.net .ndd.tld NS dns100.ovh.net mail.ndd.tld MX 5 ndd.tld .ndd.tld DynHOST @PUBLIQUEBOX mail.ndd.tld CNAME ndd.tld Le reste de la configuration sera semblable à la création du champs mail.ndd.tld. En effet comme la totalité de l'installation que nous allons faire repose sur une seul adresse IP, les futurs champs crées seront de type CNAME. Par exemple dans ma configuration, mon site est accessible « sur le champs » type A mais l'ensemble des services annexes comme cloud, webmail ou autre sont de « simples » CNAME. Gestion en local Le DNS en local fonctionne de la même manière que sur l'Internet. Un poste client émet une requête vers un serveur de nom afin d'obtenir l'adresse IP en fonction du nom. La plus basique des box peut faire office de serveur DNS. Les champs à renseigner seront identiques à ceux indiqués dans le manager de votre registrar à l'exception des champs MX. On pourra donc retrouver par exemple dans la configuration DNS de la box → mail.ndd.tld 192.168.0.x → blog.ndd.tld 192.168.0.x →… Ceci dit, si vous ne disposez que d'un seul ordinateur à la maison, il est possible d'outrepasser cette fonction de la box et d'inscrire directement « en dur » ces renseignements dans le fichier hosts. (Technique fonctionnelle mais relativement déconseillée de par le manque de souplesse de la solution). Sous Windows de mémoire le fichier en question se trouve dans C:\Windows\System32\drivers\etc et sous Linux le fichier à renseigner est /etc/hosts. #Autohebergement Emmanuel Le Nohaïc http://lacavernedemanu.fr
La configuration du Nom de Domaine est désormais terminée, l'installation se doit d'être autonome, la configuration du DynHost est là pour ça. La suite de cette partie sur le DNS peut varier en fonction de votre fournisseur d'accès et donc de la box ou routeur fourni par ce dernier. De multiples documentations sont disponibles sur Internet. Vu la multitude de box disponibles sur le marché, il serait trop long de détailler les configurations de chacune d'elles. Cette dernière partie est très générale et reprend les principes du DNS local afin que pour l'usage d'un pc nomade par exemple, vous n'ayez pas à reconfigurer votre client mail selon que vous soyez ou non au domicile. WebServices Installation d'un serveur web : Lighttpd Basé sur une Debian, nous allons utiliser aptitude pour mettre à jour le système et installer le « coeur » de l'installation notre serveur web. aptitude update aptitude upgrade aptitude install lighttpd Lighttpd est désormais opérationnel, il faut maintenant installer php5 afin que le serveur web apprenne à interpréter ce langage aptitude install php5-cgi Il faut maintenant activer php5 dans la configuration de Lighttpd (avec votre éditeur de texte favori éditez le fichier /etc/php5/cgi/php.ini puis on y décommente à la ligne 765 cgi.fix_pathinfo=1. Toujours avec votre éditeur de texte favori, éditez le fichier /etc/lighttpd/lighttpd.conf pour y ajouter le mod_fastcgi dans server.modules server.modules = ( « mod_access », « mod_alias », « mod_compress », « mod_redirect », « mod_rewrite », « mod_fastcgi », « mod_accesslog », ) Il est possible d'activer ces modules via la commande lighty-enable-mod mais je trouve (avis perso) préférable de les gérer dans le fichier de configuration, d'un seul coup d'oeil on peut ainsi voir quels sont les modules activés avec par exemple cette commande cat /etc/lighttpd/lighttpd.conf | grep mod Qui nous renvoie toutes les lignes de ce fichier contenant mod #Autohebergement Emmanuel Le Nohaïc http://lacavernedemanu.fr
Afin d'activer PHP dans la configuration du serveur web, il est nécessaire de préciser à celui-ci ou se trouve le répertoire d'exécution de PHP. Ajouter les lignes suivantes dans /etc/lighttpd/lighttpd.conf fastcgi.server = ( ".php" => (( "bin-path" => "/usr/bin/php5-cgi", "socket" => "/tmp/php.socket" ))) Répertoire d'exécution de PHP On redémarre ensuite Lighttpd /etc/init.d/lighttpd restart Redémarrage de Lighttpd Tant que nous y sommes on pourra activer SSL (Secure Socket Layer) pour des transactions sécurisées, intéressant notamment lorsqu'on se connectera au webmail pour ne pas que les identifiants passent en clair sur le réseau. mkdir /etc/lighttpd/certs cd /etc/lighttpd/certs openssl req -new -x509 -keyout lighttpd.pem -out lighttpd.pem -days 3650 -nodes Une suite de question est ensuite demandée avec dans l'ordre des réponses FR Bretagne ? =) maville [] [] /!\ common name : hostname.monndd.tld masuperadresse@monndd.tld Le CommonName est très important car il va déterminer la « crédibilité » du certificat aux yeux du navigateur web. Ainsi si le certificat porte le nom monsuperhost.ndd.fr et que le service que l'on souhaite couplé a SSL porte le nom monsupertruc.ndd.fr, les noms ne matcheront pas et des applications pourront vous envoyer voir plus loin si vous y êtes. Ceci étant dit, un wildcard (certificat *.ndd.tld) permet de résoudre le problème. Gestion du service GetSimple repose sur XML et PHP. Un large panel de serveurs web permet de le faire tourner. Dans le cadre de cette documentation je vais détailler l'installation des tous les webservices sur Lighttpd qui est un serveur web minimaliste par on emprunte sur le système mais hyper puissant par son usage. Lighttpd stocke toute sa configuration dans un seul et même fichier que l'on « amménagera » au cours de cette documentation selon les besoins et les services que nous mettrons en place. Cela dit, il est possible de « spliter » la configuration par sous domaine / service en jouant avec des include dans le fichier de configuration principal de Lighttpd. Pour démarrer, redémarrer ou arrêter le service Lighttpd #Autohebergement Emmanuel Le Nohaïc http://lacavernedemanu.fr
Vous pouvez aussi lire