Héberger son serveur avec OpenBSD

L'auto-hébergement facile et sécurisé

Copyright © 2017-2019 Xavier Cartron – 14/08/2019

Cet ouvrage est publié sous licence CC-BY-SA à l'aide de txt2tags. Merci de me dire si vous le partagez ailleurs, juste pour information. 😁

Si vous souhaitez encourager les contributeurs ou participer à ce document, Vous pouvez consulter les sources. Pour contacter l'auteur, le soutenir, lui jeter des cailloux ou lui dire merci, c'est sur son site.

Vous pouvez acheter ce livre :

Vous pouvez aussi enregistrer la page sur votre appareil ou l'imprimer pour lecture ultérieure 😁.

Sommaire
Faire un don ♥

couverture du livre par péha

1. Introduction

1.1. Avant-propos

Vous êtes sur le point de plonger dans l'univers de l'auto-hébergement. Ce document est écrit pour vous aider à héberger chez vous ou sur un serveur dédié certains services malheureusement trop souvent confiés à des tiers. L'objectif est de vous guider dans la découverte de ces notions de façon cohérente, sans fioritures et aussi simplement que possible. Vous comprendrez donc que vulgariser l'auto-hébergement entraîne des compromis. Les plus pointilleux chercheront certainement à approfondir les notions évoquées ici. C'est pourquoi vous pouvez lire les parties dans l'ordre que vous souhaitez, selon vos besoins, quitte à faire quelques rappels parfois. Le sommaire est là pour vous repérer. 😉

Afin que ce voyage soit le plus confortable possible, nous utiliserons le système OpenBSD. Ce dernier est réputé pour être sûr. Il est aussi, à mon avis, nettement plus simple à configurer que d'autres systèmes. En effet, les serveurs mail, http, antispam (entre autres) sont déjà intégrés et se configurent avec une syntaxe semblable. Souhaitant rendre plus accessible la démarche d'auto-hébergement, c'est un avantage non négligeable.

Bien que les développeurs d'OpenBSD fournissent de nombreux efforts pour vérifier le code source et assurer un système fiable et sécurisé, il faut rester vigilant. Pas de panique, nous verrons quelques éléments de rigueur pour configurer en toute sécurité votre serveur, cela demande juste du bon sens.

Vous verrez que s'auto-héberger n'est finalement pas si difficile et consiste en grande partie à modifier du texte dans des fichiers. Cette démarche devrait donc être accessible à tous.

Alors, prêt à plonger? Bonne lecture!

1.2. L'auto-hébergement : C'est quoi? Avantages et inconvénients.

La plupart des sites web que vous avez l'habitude de consulter (vos courriels, les réseaux sociaux…) sont hébergés sur des ordinateurs quelque part dans le monde. Ces derniers ne servent qu'à proposer des services et du contenu à d'autres ordinateurs. On les appelle des serveurs. La seule différence notable est qu'ils ne sont en général pas reliés à un écran.

Lorsque vous voulez consulter vos e-mails, votre navigateur va chercher sur un serveur tous vos messages, qui sont alors téléchargés vers votre ordinateur. C’est comme si pour lire votre courrier postal, vous deviez aller dans une agence pour demander au facteur :

Y a-t-il du courrier pour moi?

Ce dernier va vérifier, puis prendre votre courrier pour vous le donner. C’est le bureau de poste qui l'avait avant que vous ne le releviez. Le principe n'est pas si différent lorsque vous allez consultez vos mails.

Ce procédé apporte quelques inconvénients. Imaginez que le facteur ouvre votre courrier avant de vous le donner…

La centralisation des services permet aux sociétés qui façonnent le web de contrôler les données à leur guise, pas toujours dans l'intérêt des utilisateurs. Qui n'a pas râlé parce qu'il n'obtenait pas ce qu'il espérait d'un service postal? C'est la même chose pour Google (au hasard) qui met en avant certains contenus, par exemple leurs services commerciaux ; scanne vos mails pour vous proposer des publicités susceptibles de vous plaire… À ce jour, ce type d'activités n'est plus un secret.

De plus, si l'un de ces fournisseurs tombe en panne, c'est tout une partie de l'Internet qui est inaccessible aux dépens des utilisateurs. Cela va à l'encontre de l'idée originale du web où chacun devrait pouvoir constituer un nouveau nœud à sa toile.

Héberger chez soi les services que l'on utilise présente plusieurs avantages :

  • Les données restent chez vous. Cela veut dire que vous en gardez le contrôle. C'est particulièrement intéressant si vous aviez l'habitude de partager des documents à l'aide de services tiers (les photos chez Picasa, les vidéos sur Youtube, des papiers administratifs sur WeTransfer ou Dropbox…). Vous êtes ainsi certains que vos données n'ont pas été oubliées sur un disque dur dans une quelconque déchetterie après un renouvellement du matériel, voire revendues au plus offrant.
  • Votre vie privée est davantage respectée. Par exemple, vous êtes sûrs que vos courriels ne seront pas scannés. Cela est primordial, même lorsque l'on pense ne rien avoir à cacher.
Prétendre que votre droit à une sphère privée n'est pas important parce que vous n'avez rien à cacher n'est rien d'autre que dire que la liberté d'expression n'est pas essentielle car vous n'avez rien à dire. -- E. Snowden
  • Vous pouvez avoir à portée de main des services qui répondent exactement à vos besoins.
  • Vous pouvez utiliser du matériel à faible consommation électrique et faire ainsi attention à la planète.
  • S’auto-héberger, c’est amusant, instructif et passionnant. Cela permet de mieux comprendre le fonctionnement d’Internet et de participer à sa qualité.

Cependant, cette démarche n'est pas sans inconvénients :

  • Cela prend du temps.
  • La bande passante des particuliers n'est pas toujours aussi grande que ce que l'on voudrait. Vous ne pourrez donc pas envoyer des données aussi vite que vous le souhaitez. Ça peut être gênant pour transférer des fichiers très volumineux. (vidéos…). Pour une utilisation familiale, nul besoin de la fibre toutefois.
  • C'est à vous de vous charger de la sécurité. Cela demande du soin, mais vous avez au moins la certitude que ce n'est pas effectué avec négligence ou par un inconnu.

1.3. Pré-requis

Afin de bien se comprendre et réussir à vous auto-héberger sans tracas, on supposera dans la suite du document que :

  • Le système sur votre serveur sera OpenBSD en version 6.5. Quelques conseils sont proposés pour l'installation dans la suite du document.
  • Utiliser la ligne de commande ne vous fait plus peur, tant qu'on vous explique ce qu'il faut écrire.
  • Vous êtes capable d'éditer un fichier.
  • Vous serez attentif à différencier les commandes à saisir dans un terminal des lignes de configuration à écrire dans un fichier. Vous remarquerez que les commandes à écrire en tant qu'administrateur sont précédées d'un "#", sinon elles sont précédées de "$".
  • Gardez en tête que les lignes de code trop longues sont automatiquement découpées, précédées d'un alinéa. On les distingue facilement car lors d'une césure, le symbole \ est ajouté dans la version papier du présent document.
  • Vous disposez d'un vieil ordinateur récupéré qui servira de serveur, ou bien d'un appareil acheté pour l'occasion (basse consommation, configuration adaptée à vos besoins particuliers…). Puisqu'OpenBSD supporte de nombreuses architectures, choisissez i386, sinon amd64 pour du matériel plus récent. Dans le doute, ça fonctionnera avec i386.
  • Vous devez connaître l'adresse IP de votre serveur. L'idéal est de disposer d'une IP fixe (cela évite une configuration DynDNS). Un petit message à votre fournisseur d'accès à internet vous permettra d'en réclamer une. Sinon, le plus simple sera de souscrire à un abonnement chez un fournisseur qui propose ce service.
  • Vous disposez d'un nom de domaine. Si vous ignorez ce que c'est, référez-vous à la partie consacrée à ce sujet.

1.3.1. Quelle est mon adresse IP ?

Note : Les concepts abordés rapidement dans cette partie sont approfondis dans la section sur les adresses réseau si vous souhaitez en savoir plus.

Avant de définir une adresse IP (Internet Protocol), soyons sérieux deux minutes et parlons du Père Noël. Chaque enfant sait très bien qu'il doit envoyer sa liste de cadeaux à "Route du Ciel, Pôle Nord". S'il veut une réponse, il notera sa propre adresse derrière l'enveloppe.

C'est le même principe pour l'ordinateur de votre collègue qui vous montre une vidéo de chat sur Youtube : l'ordinateur sait où trouver Youtube, et Youtube sait à quelle adresse envoyer les données.

Chaque appareil connecté à Internet dispose de son adresse : l'adresse IP. Cependant, les ordinateurs n'ont pas le même sens de la poésie que les enfants. Les adresses utilisées dans un réseau sont des séries de chiffres, par exemple 192.0.2.2. Nettement moins classe que l'adresse du Père Noël.

D'accord, mais comment font les serveurs pour connaître l'adresse d'un site? Il y a un annuaire ?

Quelle idée intéressante. C'est effectivement prévu, lisez la partie sur les noms de domaine pour en savoir davantage.

Il faut distinguer l'IP publique de l'IP locale. La plupart du temps, pour vous connecter à Internet, votre fournisseur d'accès vous a donné une *box. Celle-ci fait le relai entre internet et votre ordinateur. Cela donne :

Source de l'image : https://okeanos.grnet.gr

S'il faut retenir quelque chose, c'est :

  • L'IP locale du serveur servira pour les communications qui restent à l'intérieur de votre réseau privé : entre les machines connectées à votre *box (en bas du schéma).
  • L'IP publique servira dès que des données seront à échanger sur l'Internet mondial. Pour les besoins de l'auto-hébergement, il est très important que cette adresse soit fixe. Certains fournisseurs d'accès refusent de vous en donner. Il existe des moyens de contourner ce problème (DynDNS…) mais vous vous faciliterez vraiment la vie en prenant votre abonnement internet chez un fournisseur qui accepte de vous fournir une IP fixe. Ce problème n'existe pas si vous disposez d'une IPv6 : cette adresse est unique pour votre serveur sans que la *box ne soit un intermédiaire.

    Lors de l'installation d'OpenBSD, vous avez configuré le réseau grâce à l'assistant. Votre serveur est donc normalement prêt à servir. Si vous voulez modifier la configuration réseau, référez-vous à la partie dédiée.

Pour connaître votre IP publique, il existe de nombreux services en ligne, par exemple sur mon-ip.com, lehollandaivolant.net, who.is , ipecho , ifconfig.me ou encore whatsmyip. Ça devrait suffire 😁.

Pour trouver l'IP locale de votre serveur, saisissez la commande suivante :

# /sbin/ifconfig |grep inet

Vous verrez apparaître des lignes comme celles-ci :

inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
inet 127.0.0.1 netmask 0xff000000
inet 192.168.1.2 netmask 0xffffff00 broadcast 192.168.1.255
inet6 fe80::feaa:14ff:fe65:5f86%re0 prefixlen 64 scopeid 0x1

Les adresses inet6 sont des IPv6 et inet des IPv4.

  • ::1 et 127.0.0.1 : Il s'agit des adresses "internes" de votre serveur, ce n'est pas ce que nous cherchons.
  • Les adresses commençant par fe80: et 192.168 sont les IP locales de votre serveur.

Si quelqu'un veut visiter votre site web, il ne connaît que votre IP publique. Or, l'IP (IPv4) publique renvoie vers la *box, les données ne sont pas dessus mais sur votre serveur. Elle doit donc savoir qu'elle doit diriger ce visiteur vers l'IP locale de votre serveur. La *box est un routeur qu'il faut configurer. Ça tombe bien, c'est expliqué juste après.

1.3.2. Rediriger les ports sur son routeur

Votre serveur, comme votre ordinateur probablement, sera connecté à Internet par l’intermédiaire d’un modem-routeur (une *box). Il faut s’assurer que lorsqu’un visiteur voudra accéder à votre serveur, ce routeur (la *box) le redirige bien vers votre serveur, et non vers une autre machine du réseau local. On dit que l’on configure le routeur.

Autrement dit, imaginez votre routeur comme un grand mur avec dedans plusieurs portes. Chacune est numérotée. Quand quelqu’un veut accéder à votre serveur, il va venir frapper à l’une des portes, par exemple la numéro 80 pour un serveur web (http). Afin que tout fonctionne bien, il est nécessaire de savoir où mène la porte numéro 80. Si le routeur ne le sait pas, alors la porte reste fermée et votre serveur est inaccessible. Bien sûr, pour encore plus de sécurité, une fois la porte 80 passée, votre serveur sera équipé d’un parefeu pour vérifier que vous avez bien le droit d’entrer. Ce sera un peu le concierge 😁.

Dans le schéma ci-dessus, seuls les ports 443, 80 et 22 sont associés au serveur. Si le petit malin demande un port qui n’est pas redirigé vers le serveur (la porte est fermée), alors la requête ne peut pas aller jusqu'au bout. C’est comme s’il demandait d'aller à une destination qui n’existe pas. En revanche, lorsque le visiteur demande de passer par la porte 80, il est bien renvoyé vers le serveur.

La configuration du routeur se déroule toujours de la même façon :

  1. Vous accédez à l’interface de configuration du modem ;
  2. Vous précisez le port d’écoute par lequel vont arriver les requêtes. Par exemple, le port 80 pour un site web ;
  3. Vous indiquez que le flux qui est adressé à ce port doit être mis en relation avec le port 80 de votre serveur (et pas un autre ordinateur connecté à la *box).

Cependant, l’interface de configuration n’est pas la même selon si vous avez une livebox, freebox, modem OVH… Pas d’inquiétude, voici quelques indices.

Déjà, pour accéder à la configuration, c'est à partir d'un navigateur web (Firefox par exemple). On peut trouver l’adresse à taper dans un navigateur web pour accéder à cette interface. Essayez dans l’ordre suivant (Bien sûr, cette “adresse” est à utiliser sur un ordinateur lui-même connecté à la *box.) :

  • 192.168.0.1
  • 192.168.1.1
  • 192.168.1.254
  • Pour une freebox, cela se passe en ligne sur la page de gestion de votre compte, ou via http://mafreebox.freebox.fr/ ou 192.168.0.254.

Sachez que cette adresse (on parle d'adresse du routeur, ou adresse passerelle) s'avère un élément important de la configuration de votre réseau. Retenez-la bien.

Il est possible qu’un nom d’utilisateur et un mot de passe soient demandés. Essayez dans ce cas admin/admin, sinon, demandez directement à votre fournisseur d’accès à Internet. Une fois connecté, allez dans la section "Configurer mon routeur".

Pour plus d’informations, vous pouvez consulter cette page.

1.3.3. Un nom de domaine

Ce n'est pas une obligation, mais vous voudrez certainement obtenir un nom de domaine, qui permettra à tous d'accéder plus facilement à votre serveur. Cela vous donne aussi la possibilité de mieux vous organiser avec des sous-domaines, par exemple mail.chezmoi.tld, blog.chezmoi.tld…

Mais c'est quoi un nom de domaine?

Imaginons que M. Ali Gator vit au 5 rue du moulin à Picsouville. Pour aller lui rendre visite, c’est à cette adresse que vous irez. Sur le web, l’adresse de votre serveur, c’est une série de nombres : l'IP. Par exemple 192.0.2.2. C’est pratique pour les machines, pas pour les humains.

Un nom de domaine nous permet d’utiliser l’adresse wikipedia.org, qui est traduit par les ordinateurs en 91.198.174.192. Avouez que c’est plus facile à retenir.

L’association d’une IP avec un nom de domaine est possible grâce aux enregistrements DNS (Domain Name System). Ce système est à la base de toutes les interactions qui se servent des noms de domaines : Email, Web, … C'est une sorte d'annuaire numérique.

Vous pouvez acheter un nom de domaine auprès de ce que l’on appelle un registre ou registrar comme OVH ou Gandi que je conseille. Ce n'est pas très onéreux, mais sachez qu'il en existe aussi des gratuits, comme ceux de FDN ou freenom.com.

Une fois votre domaine acquis, configurez les champs DNS pour le faire pointer vers votre adresse IP. Pour ça, référez-vous à la partie suivante sur les enregistrements DNS et registres qui offrira le service DNS. Si vous le souhaitez, vous pourrez gérer les enregistrements DNS vous-mêmes en installant un serveur de noms.

1.3.4. Les enregistrements DNS

Lorsque un ordinateur doit aller sur un site dont le nom est "chezmoi.tld", il va demander à un serveur DNS (qu'on appelle résolveur dans ce cas) à quelle adresse IP ce nom de domaine correspond. Le DNS, c'est un peu comme des panneaux sur le bord de la route qui indiquent le chemin à suivre pour arriver à destination.

Pour créer ce panneau une fois que vous avez un nom de domaine, il faut le relier à l’adresse IP de votre serveur. Mais si, souvenez-vous, cette série de nombres ressemblant à 192.0.2.2. Pour cela, enregistrez un champ de type A dans l’interface d’administration du registre. Par exemple :

chezmoi.tld	A	192.0.2.2

Notez qu'il existe plusieurs types d’enregistrements :

  • Les champs A pour les adresses IPv4. ex : 192.0.2.2.
  • Les champs AAAA pour les adresses IPv6. ex: 2001:db8:1:1::2.
  • Les champs CNAME. Ils sont très utiles pour définir des sous-domaines et organiser votre serveur. Vous aurez alors plusieurs CNAME qui pointeront vers le champ A précédent. Par exemple :

    blog.chezmoi.tld CNAME chezmoi.tld
    wiki.chezmoi.tld CNAME chezmoi.tld
    webmail.chezmoi.tld CNAME chezmoi.tld
    
  • Les champs MX, NS ,TXT…

Pour en savoir plus, vous pouvez lire les pages suivantes :

Sachez qu'il vous est tout à fait possible d'auto-héberger un serveur de noms et être totalement indépendants.

1.3.5. Quel matériel acheter ?

Vous n'avez pas besoin d'une puissance phénoménale pour vous auto-héberger. Souvent, une machine récupérée car trop peu puissante pour une utilisation bureautique sera amplement suffisante.

Si vous souhaitez investir, je vous conseille de vérifier la compatibilité avec OpenBSD. Ça évite une mauvaise surprise et un coup de pas-de-chance 😁.

La liste du matériel supporté, classé par architecture, est disponible sur la FAQ officielle (en) et la FAQ inofficielle (fr).

Mon petit coup de cœur ? Les architectures arm car très peu gourmandes en énergie. Bien que ça ne soit pas une architecture ARM, la carte APU2 (apu2d0) est économe, peu chère, fiable et fonctionne vraiment très bien bien qu'un peu plus difficile à installer (pas d'écran) ! Vous trouverez la liste des vendeurs ici.

1.3.5.1. Un vieil ordinateur, ça suffit ?

Je dispose d'un vieil ordinateur. Je pense que l’alimentation n’est pas adaptée pour le laisser allumé 24 h/24, 7 j/7, non ?

Pour la consommation, regardez ce qui est écrit sur l'alimentation. La puissance en watt donnera une idée de la consommation engendrée. En général, une puissance de 1W, c'est environ 1 euro/an d'électricité.

1.3.5.2. Quid d'OpenBSD sur Raspberry Pi ?

Est-ce qu'OpenBSD peut fonctionner sur le raspberry pi ?

Oui, à partir de la version 3 du raspberry pi en choisissant l'architecture arm64. Cela reste très jeune et difficile à utiliser pour l'instant malgré le travail en cours. Vous pourrez préférer une autre carte ARM dans ce cas.

1.3.6. Adresses réseau

1.3.6.1. Rappel des concepts

Pour construire un serveur, il vous faut impérativement configurer correctement sa configuration réseau. Vous avez en particulier besoin d'adresses (publiques et privées) stables, ainsi que de connaître l'adresse de votre passerelle ou routeur.

Cette documentation a pour but de vous aider à monter un serveur auto-hébergé, aussi on va se concentrer sur les solutions fournies par des fournisseurs d'accès Internet grand public.

Vous pouvez passer ce chapitre si vous êtes à l'aise et commencer vos premiers essais avec une configuration en dhcp puis revenir ici une fois que vous vous êtes habitués.

Voici quelques précisions ou rappels qui vous permettront de mieux appréhender la suite.

1.3.6.1.1. Adresse publique, adresse privée

Tout d'abord sachez que votre fournisseur d'accès ne vous connecte sûrement pas directement sur le réseau internet, mais plutôt par ce qu'on appelle du NAT. Si vous utilisez une box, alors cet appareil (on va beaucoup parler de lui plus bas) va, lui, recevoir une adresse Internet publique.

Adresse publique, ça signifie que les gens qui naviguent sur le net peuvent contacter cette adresse. Elle est routable et unique. Tous les sites web notamment utilisent des adresses publiques.

Votre box va alors distribuer des adresses privées sur votre réseau local. (Ce qui signifie, si vous suivez bien, que vous avez, chez vous, plusieurs adresses privées - une pour chaque appareil connecté sur votre réseau : TV connectée, smartphone, imprimante… - qui se partagent une seule adresse publique.)

OK ? Bien, on continue 😁.

Les adresses privées peuvent être dans trois rangées:

  1. 10.0.0.0/8 : de 10.0.0.0 à 10.255.255.255.
  2. 172.16.0.0/12 : de 172.16.0.0 à 172.31.255.255
  3. 192.168.0.0/16 : de 192.168.0.0 à 192.168.255.255

Votre adresse privée, ou locale, c'est celle que votre ordinateur utilise, celle qu'il connait. Par exemple sur un ordinateur utilisant Linux :

[toto@jabberwocky src]$ ip add show dev eno1
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    inet 10.0.153.194/16 brd 10.0.255.255 scope global dynamic eno1
       valid_lft 28073sec preferred_lft 28073sec

Ici 10.0.153.194 est bien une adresse (ou IP ou adresse IP) privée.

Votre adresse publique, c'est celle que vous utilisez pour la navigation internet. C'est cette adresse que connaissent les différents sites web que vous fréquentez. Et justement, si vous ne la connaissez pas, il vous suffit d'aller voir par exemple ifconfig.me (ou mon-ip.com, who.is, ipecho, ifconfig.me, whatsmyip…).

1.3.6.1.2. Le routeur

Le routeur, c'est la box internet. On parle aussi de passerelle (gateway en anglais).

D'un côté du routeur, on a donc une adresse internet publique (que dans l'ensemble de cette documentation, on a supposé fixe, comme dit juste au-dessus), de l'autre on a une adresse privée. Cette dernière adresse est très importante: c'est celle que votre serveur (ainsi que votre ordinateur personnel, votre smartphone, votre grille-pain connecté…) doit connaitre pour atteindre internet.

Dans les faits, quand quelqu'un dans votre réseau doit contacter un site internet, il passera par cette adresse, qui s'avère donc critique, et qui plus est un goulet d'étranglement.

C'est également le routeur qui fait les redirections de ports.

Pour trouver l'adresse de votre "gateway", vous pouvez vous connecter en dhcp dans un premier temps puis entrer la commande suivante :

# route -n show
Routing tables

Internet:
Destination        Gateway            Flags   Refs      Use   Mtu  Prio Iface
default            192.168.0.1      UGS       35     4827     -     8 re0  
224/4              127.0.0.1          URS        0       13 32768     8 lo0  
127/8              127.0.0.1          UGRS       0        0 32768     8 lo0  
127.0.0.1          127.0.0.1          UHhl       9      969 32768     1 lo0  
…

La première ligne vous donne la réponse : 192.168.1.1 dans l'exemple.

1.3.6.1.3. Nom de machine

Chaque élément sur le réseau a un nom (qu'on appelle nom d'hôte, ou nom de machine. Certaines documentations parlent de nom de réseau de la machine).

Sur les éléments les plus sophistiqués (les vrais ordinateurs), on peut changer ce nom. De nombreux appareils actuels sont toutefois verrouillés (essayez de changer le nom de machine d'un smartphone Android…). Ça n'a l'air de rien mais avoir un nom de machine permet de reconnaître les appareils effectivement présents et fonctionnels dans le réseau.

Le nom de machine d'un ordinateur tournant sous OpenBSD se définit dans /etc/myname, où sera juste inscrit son nom complet. Par exemple:

toto@maitre:/home/toto $ cat /etc/myname
maitre.chezmoi.tld
1.3.6.1.4. DHCP

Pour configurer l'adresse locale, vous pouvez utiliser le client dhcp qui vient par défaut avec chaque installation OpenBSD.

Pour ce faire, il suffit d'indiquer dhcp dans le fichier de configuration de l'interface réseau de votre serveur. Ce fichier est /etc/hostname.if avec if le nom de ladite interface. Si vous avez sélectionné dhcp lors de l'installation d'OpenBSD, alors c'est bon.

toto@maitre:/home/toto cat /etc/hostname.re0                                                               
dhcp

Suivant la configuration du routeur que vous utilisez (configuration que vous ne pouvez pas forcement changer facilement), il peut être nécessaire d'utiliser DHCP pour obtenir de la connectivité sur votre serveur (le routeur pourrait refuser de relayer les connexions à une machine qui n'est pas dans sa table DHCP).

Si vous obtenez votre configuration réseau par DHCP, alors il n'est pas nécessaire de connaître ou de renseigner l'adresse de votre routeur.

1.3.6.1.5. Configuration statique

La configuration statique d'une machine s'avère plus complexe, mais on a davantage de maîtrise dessus (on peut par exemple assigner plusieurs adresses si on l'estime nécessaire).

On configure d'abord l'interface voulue :

toto@maitre:/home/toto $ cat /etc/hostname.re0 
inet            192.168.1.2     255.255.255.0     192.168.0.255
inet   alias    192.168.0.9    255.255.255.0     192.168.0.255
## et autant d'autres que vous le voulez…

up

Puis on indique l'adresse du routeur (son adresse privée, celle dont j'ai dit plus haut à quel point elle est importante). Cette adresse se configure dans le fichier /etc/mygate:

toto@maitre:/home/toto cat /etc/mygate
192.168.0.1

Vous devez connaître l'adresse de votre passerelle. Cette adresse n'est pas standard, en revanche les constructeurs ou les FAI ont souvent des réglages par défaut qui sont connus et qu'on peut retrouver sur le web. Il est également possible d'utiliser DHCP au début du processus de construction du serveur, puis mettre la configuration en statique quand on a pris la main et qu'on commence à vouloir faire des trucs sophistiqués.

Une fois ces deux fichiers configurés, l'interface sera configurée et mise en service automatiquement à chaque démarrage de la machine. Notez également que vous pouvez combiner des éléments de configuration dynamique (dhcp) avec de la configuration statique.

Vous pouvez tester votre bonne connexion au net grâce à la (célèbre) commande ping.

Tout d'abord "pinger" votre passerelle :

ping 192.168.0.1

Puis "pinger" le serveur de l'APNIC par exemple :

ping 1.1.1.1

Si tout va bien, alors votre serveur est connecté au net.

1.3.6.2. IPv6

IPv6 c'est le nouveau protocole IP. Aujourd'hui, ça devient essentiel de le maîtriser un petit peu. Sachez que si vous n'avez pas encore d'ipv6 chez vous, il est probable que vous en ayez d'ici un ou deux ans. Mieux vaut être préparé pour en tirer le meilleur profit non ?

La configuration reprend les grands principes d'ipv4, mais avec des différences sur les méthodes et la syntaxe:

toto@maitre:/home/toto $ cat /etc/hostname.re0 
inet…

inet6   2001:db8:1:1::2    64 # adresse
inet6   autoconf              # utilisation des adresses 
                              # SLAAC automatiques

up

Les adresses SLAAC ont l'avantage d'être stables (si on utilise pas l'attribut autoconfprivacy), ce qui est exactement ce dont vous avez besoin sur un serveur. En revanche, elles sont encombrantes et peu mémorisables par un être humain.

Vous pouvez aussi utiliser les adresses ULA, qui sont des adresses locales pour votre réseau. Elles permettent de configurer un réseau de manière permanente sans avoir besoin de tout renuméroter en cas de changement de FAI. Elles sont également non-routables, ce qui veut dire que personne ne peut les attaquer. Enfin, elles constituent un excellent moyen de commencer à mettre en place votre réseau en attendant d'avoir vos adresses publiques définitives (si vous n'en avez pas encore). Vous pouvez lire davantage à propos de ces adresses ici.

L'écoute des annonces des routeurs permet de connaître leur adresse, ce qui est, on vous le rappelle, une donnée essentielle. Vous pouvez aussi renseigner cette donnée dans le fichier /etc/mygate.

toto@maitre:/home/toto cat /etc/mygate
192.168.0.1
2001:db8:1:1::

Ces divers paramètres se combinent de manière adéquate les uns avec les autres. Ainsi, vous pouvez tout à fait utiliser des adresses SLAAC et des adresses statiques.

En ipv6, il n'est plus question de redirection de ports (et ça c'est cool 😁) : votre serveur est directement connecté à internet. Soyez donc prudent et vérifiez bien le pare-feu de votre serveur (PF).

1.3.7. Exemple d'installation détaillée d'OpenBSD

Cette section n'est là que pour rassurer les plus réticents. Pour des informations plus complètes, n'hésitez pas à consulter la documentation d'OpenBSD.

On télécharge tout d'abord l'image d'installation de la dernière version d'OpenBSD, qui est, à l'heure où j'écris ces lignes, la 6.5.

N'oubliez pas de vérifier la somme de contrôle. À partir d'un système OpenBSD, cela se passe avec cette commande :

signify -Cp /etc/signify/openbsd-65-base.pub -x SHA256.sig install*.fs

Sinon, sur un autre système, calculez la somme de contrôle "sha256" puis comparez avec le contenu du fichier SHA256 présent à cette adresse : https://cdn.openbsd.org/pub/OpenBSD/6.5/amd64/ (remplacez "amd64" par votre architecture 😉 ).

  • Pour installer à partir d'un cdrom, choisissez install65.iso puis gravez-la sur le CD.
  • Pour installer à partir d'une clé USB, choisissez install65.fs. Pour préparer une clé USB, utilisez l'outil dd (remplacez /dev/sdb par le chemin vers votre clé USB). Par exemple sur un système GNU/Linux :

    # dd if=/location/install*.fs of=/dev/sdb bs=1M 
    

    À partir d'OpenBSD :

    # dd if=/location/install*.fs of=/dev/rsd1c bs=1m 
    

    La commande dd va reproduire le contenu de l'image sur la clé USB. Pour éviter d'avoir à écrire le nom exact de l'image d'installation, on utilise le symbole * qui veut dire "n'importe quelle suite de caractères". Les autres options servent au bon fonctionnement du transfert.

Vous pouvez récupérer un outil graphique nommé etcher pour préparer la clé USB plus sereinement si la commande dd ne vous plaît pas.

Les utilisateurs de Windows pourront faire la même chose avec le logiciel rufus.

Et hop, on insère tout ça dans le lecteur ou prise USB du PC, puis on redémarre en choisissant de démarrer sur le bon disque (boot en anglais). Repérez les messages qui s'affichent du type F12 : Boot Menu ou F7 : Setup indiquant les touches qui permettent de faire apparaître les fenêtres (bleues) des tableaux de réglage du BIOS. On y indique souvent le lecteur de CDROM ou la clef USB comme média de démarrage numéro 1.

Si au cours de la configuration de l'installation vous vous trompez, pas de panique. Appuyez sur ctrl-C puis entrez la commande install afin de recommencer la configuration au début en retrouvant vos choix précédents.

Le premier écran nous propose d'ajouter des options pour démarrer OpenBSD. Normalement, on n'en a pas besoin, on appuie donc juste sur "Entrée" :

>> OpenBSD/amd64 CDBOOT 341.
boot> 

Si votre machine a un port série, vous avez besoin d'un retour console. Vous devrez alors préciser ces options :

>> OpenBSD/i386 PXEBOOT 1.00
boot> stty com0 19200
boot> set tty com0
boot> <Appuyez sur entree>

Plein de texte sur fond bleu apparaît, indiquant la détection du matériel et autres choses qui ne doivent pas vous inquiéter.

On lance l'installation en entrant "I" :

erase ^?, werase ^W, kill ^U, intr ^C, status ^T

Welcome to the OpenBSD/amd64 6.5 installation program.
(I)nstall, (U)pgrade, (A)utoinstall or (S)hell?

Les valeurs proposées pour l'installation sont largement suffisantes dans la plupart des cas. Les choix par défaut sont indiqués entre crochets : [choix]. À chaque fois, des exemples sont disponibles avec '?'.

On choisit une disposition de clavier : fr

At any prompt except password prompts you can escape to a shell by typing '!'.
Default answers are shown in []'s and are selected by pressing RETURN.  
You can exit this program by pressing Control-C, 
but this can leave your system in an inconsistent state.

Choose your keyboard layout ('?' or 'L' for list) [default] fr

On choisit ensuite un nom de machine, par exemple "maitre.chezmoi.tld" ou "maitre".

System hostname? (short form, e.g. 'foo')

Ensuite, on configure la connexion à Internet. Notez qu'il n'est pas obligatoire d'avoir un accès en ligne si vous avez choisi une image install*.* qui contient tous les éléments pour faire l'installation.

Vous avez la possibilité de définir une IP statique pour votre serveur ou bien utiliser la configuration DHCP par facilité.

Available network interfaces are: re0 vlan0.
Which network interface do you wish to configure? (or 'done') [re0]
IPv4 address for re0? (or 'dhcp' or 'none') [dhcp]
DHCPDISCOVER on re0 - interval 1
DHCPOFFER from 10.0.2.2 (52:55:01:00:02:02)
DHCPREQUEST on re0 to 255.255.255.255
DHCPACK from 10.0.2.2 (52:55:01:00:02:02)
bound to 10.0.2.15 -- renewal in 43200 seconds.

Pour avoir une IPv6, choisissez autoconf le moment venu pour en avoir une automatiquement. Vous souhaiterez certainement configurer cette partie manuellement par la suite.

IPv6 address for re0? (or 'autoconf' or 'none') [none] autoconf
Available network interfaces are: re0 vlan0.
Which network interface do you wish to configure? (or 'done') [done]

La configuration réseau se termine par la route IPv4 et le DNS. Laissez les choix par défaut à moins d'avoir un besoin très particulier :

Default IPv4 route? (IPv4 address or none) [10.0.2.2]
add net default: gateway 10.0.2.2
DNS domain name? (e.g. 'bar.com') [my.domain]
Using DNS nameservers at 10.0.2.3

Ensuite, l'installateur vous demande le mot de passe de l'administrateur système dont le petit nom est root. Choisissez un mot de passe robuste.

Password for root account? (will not echo)
Password for root account? (again)

Vous pouvez ensuite faire en sorte que SSH soit lancé par défaut au démarrage. C'est conseillé pour un serveur afin de pouvoir l'administrer sans écran à partir d'un autre ordinateur.

On nous demande si un serveur X sera utilisé (session graphique) : ce n'est absolument pas nécessaire pour un serveur. Autant attribuer toutes les ressources aux calculs autres que l'affichage.

Vous ne voudrez sans doute pas changer la console par défaut, laissez "no".

Password for root account? (will not echo)
Password for root account? (again)
Start sshd(8) by default? [yes]
Do you expect to run the X Window System? [yes] no
Change the default console to com0? [no]

Vous pouvez ajouter un utilisateur si vous le souhaitez en entrant son login. Vous n'êtes pas obligés, mais je vous le conseille pour vous connecter à votre serveur via SSH. Ainsi, vous éviterez d'utiliser le compte root.

Setup a user? (enter a lower-case loginname, or 'no') [no] luffy
Full name for user luffy? [luffy] Mugiwara No Luffy
Password for user luffy? (will not echo)
Password for user luffy? (again)

On vous demande ensuite si vous voulez autoriser l'utilisateur "root" à se connecter via SSH. C'est une très mauvaise idée, puisque cet utilisateur a tous les droits et est la cible privilégiée des pirates. Choisissez "no".

WARNING: root is targeted by password guessing attacks, pubkeys are safer.
Allow root ssh login? (yes, no, prohibit-password) [no]

Le fuseau horaire peut être modifié :

What timezone are you in? ('?' for list) [Canada/Mountain] Europe/Paris

C'est parti pour le choix du disque sur lequel installer OpenBSD :

Which disk is the root disk? ('?' for details) [wd0]
Use (W)hole disk MBR, whole disk (G)PT, (O)penBSD area or (E)dit? [whole]

Après avoir appuyé sur Entrée, vous voyez :

Disk: wd0      geometry: 2610/255/63 [41943040 Sectors]
Offset: 0      Signature: 0xAA55
           Starting         Ending     LBA Info:
 #: id     C   H   S -      C   H  S [    start:     size ]
-----------------------------------------------------------------
 0: 00     0   0   0 -      0   0  0 [        0:        0 ] unused
 1: 00     0   0   0 -      0   0  0 [        0:        0 ] unused
 2: 00     0   0   0 -      0   0  0 [        0:        0 ] unused
*3: A6     0   1   2 -   2609 254 63 [       64: 41929586 ] OpenBSD
Use (W)hole disk MBR, whole disk (G)PT, (O)penBSD area or (E)dit? [W]

Nous voilà à la partie sans doute la plus complexe : le partitionnement. Notez que celui par défaut proposé par l'installateur conviendra dans la majorité des cas.

Je tape donc "W" (ou "G") dans la suite pour utiliser le disque entier, puis "A" pour le partitionnement automatique.

Vous pouvez modifier le partitionnement par défaut en tapant "E".

Setting [OpenBSD https://www.openbsd.org/] MBR partition to whole wd0…done.
The auto-allocated layout for wd0 is :
#            size     offset  fstype [fsize bsize   cpg]
  a:   738.1M         64  4.2BSD   2048 16384     1 # /
  b:   223.8M    1511648  swap
  c: 20480.0M          0  unused
  d: 172.9.1M    1969888  4.2BSD   2048 16384     1 # /tmp
  e:  1791.0M    4372032  4.2BSD   2048 16384     1 # /var
  f:  1558.1M    8040032  4.2BSD   2048 16384     1 # /usr
  g:   906.8M   11230976  4.2BSD   2048 16384     1 # /usr/X11R6
  h:  3364.2M   13088192  4.2BSD   2048 16384     1 # /usr/local
  i:  1287.2M   19977984  4.2BSD   2048 16384     1 # /usr/src
  j:  1826.5M   22614208  4.2BSD   2048 16384     1 # /usr/obj
  k:  7604.8M   26354784  4.2BSD   2048 16384     1 # /home
Use (A)uto layout, (E)dit auto layout, or create (C)ustom layout? [a] e

Ensuite, vous pouvez lire le manuel de disklabel si vous êtes perdus. Il faut en général indiquer une action (avec une lettre) à réaliser sur la partition où il faudra l'effectuer.

Par exemple : la suite d f (entrée) permet de supprimer la partition f (delete f), qui était /usr, et d k pour supprimer le /home.

Ensuite, taper a f permet de re-créer cette partition, et d'en définir la taille. Notez que vous pouvez définir une taille en pourcentage du disque (par exemple 50%) ou en pourcentage de l'espace libre restant (50&). Ici, je vais réduire le /home au profit de /usr qui prendra 75% de l'espace restant. De la même façon avec a k, on re-crée /home à la taille souhaitée.

Use (A)uto layout, (E)dit auto layout, or create (C)ustom layout? [a] e
Label editor (enter '?' for help at any prompt)
> d f
> d k
> a f
offset: [26354784]
size: [15574866] 75&
FS type: [4.2BSD]
mount point: [none] /usr
> a k
offset: [38035904]
size: [3893746]
FS type: [4.2BSD]
mount point: [none] /home

À tous moments, vous pouvez taper p pour afficher les partitions actuelles, histoire de voir où vous en êtes.

> p 
OpenBSD area: 64-41929650; size: 41929586; free: 3190962
The auto-allocated layout for wd0 is :
#           size       offset  fstype [fsize bsize   cpg]
  a:     1511584           64  4.2BSD   2048 16384     1 # /
  b:      458240      1511648  swap
  c:    41943040            0  unused
  d:     2402144      1969888  4.2BSD   2048 16384     1 # /tmp
  e:     3668000      4372032  4.2BSD   2048 16384     1 # /var
  f:    11681120     26354784  4.2BSD   2048 16384     1 # /usr
  g:     1857216     11230976  4.2BSD   2048 16384     1 # /usr/X11R6
  h:     6889792     13088192  4.2BSD   2048 16384     1 # /usr/local
  i:     2636224     19977984  4.2BSD   2048 16384     1 # /usr/src
  j:     3740576     22614208  4.2BSD   2048 16384     1 # /usr/obj
  k:     3893728     38035904  4.2BSD   2048 16384     1 # /home

Quelques points à garder en tête :

  • La partition "b" est réservée au swap.
  • La lettre "c" est réservée, elle représente tout le disque.
  • Vos sites web seront enregistrés dans /var. Songez à lui attribuer une place suffisante.
  • Vous pouvez définir des tailles en ajoutant une unité (50G), un pourcentage du disque (5%) ou un pourcentage de l'espace libre restant (100&).

Taper q permet de valider les changements.

> q
Write new label?: [y]
newfs: reduced number of fragments per cylinder group from 94472 to 94096 to
enlarge last cylinder group
/dev/rwd0a: 738.1MB in 1511584 sectors of 512 bytes
5 cylinder groups of 114.559MB, 7334 blocks, 14720 inodes each
…
…
/dev/wd0a (8c0364801ae0817e.a) on /mnt type ffs  \
    (rw, asynchronous,local, nodev, nosuid)
/dev/wd0k (8c0364801ae0817e.k) on /mnt/home type ffs  \
    (rw, asynchronous,local, nodev, nosuid)
…
…
STOP ! Je n'ai aucune idée de l'espace à consacrer à mes partitions. Un coup de main svp ?

Si vous doutez, je vous propose la répartition suivante très simple :

  • 10G pour /usr/local seront amplement suffisants pour contenir les programmes installés.
  • Entre 10G et 50G pour /var qui contiendra vos sites et les journaux. Vous pouvez attribuer encore plus d'espace si vous pensez en avoir besoin.
  • L'espace restant ira pour la partition racine et donc tout le reste : /.

Enfin l'installation des composants du système peut commencer. L'installateur doit savoir où aller les chercher : sur le cdrom d'installation (cd0), la clé USB d'installation (disk) ou directement sur un miroir de téléchargement (http). Choisissez cd0 ou disk si vous installez avec une image install*.* ou bien http en cas de doute.

Petite astuce pour choisir un miroir si ça vous intéresse. Entrez "?" pour avoir la liste numérotée des serveurs disponibles. Quittez cette liste avec "q", puis entrez seulement le numéro du miroir que vous souhaitez utiliser.

Pour ajouter un set, saisissez simplement son nom, par exemple game65.tgz. Pour retirer un set, saisissez son nom précédé du signe moins : -game65.tgz. Ils ne prennent vraiment pas beaucoup de place, je vous conseille de tout laisser coché.

Let's install the sets!
Location of sets (cd0 disk http or 'done') [http]
HTTP proxy URL? (e.g. ’http://proxy:8080’, or ’none’) [none]
HTTP Server? (hostname, list#, ’done’ or ’?’) [ftp.fr.openbsd.org]
Server directory? [pub/OpenBSD/6.2/amd64]

Select sets by entering a set name, a file name pattern or ’all’. De-select
sets by prepending a ’-’ to the set name, file name pattern or ’all’. Selected
sets are labelled ’[X]’.

  [X] bsd     [X] base65.tgz  [X] game65.tgz    [X] xfont65.tgz
  [X] bsd.rd  [X] comp65.tgz  [X] xbase65.tgz   [X] xserv65.tgz
  [ ] bsd.mp  [X] man65.tgz   [X] xshare65.tgz

Set name(s)? (or ’abort’ or ’done’) [done]

bsd.mp est le noyau optimisé pour les systèmes multi-processeurs, et bsd le noyau classique. C'est l'un ou l'autre qui sont utilisé, et non pas l'un en plus de l'autre. OpenBSD est suffisamment intelligent pour choisir le noyau optimisé si le matériel le permet, vous n'avez rien à faire.

Si vous installez les sets à partir du CD, un avertissement sur la signature apparaît. Rien d'inquiétant, vous pouvez dans ce cas continuer.

Directory dœs not contain SHA256.sig. Continue without verification? [no] yes

L'installation avance

Get/Verify SHA256.sig    100% |**************************| 2152        00:00
Signature Verified
Get/Verify bsd           100% |**************************| 10423 KB    00:14
Get/Verify bsd.rd        100% |**************************| 9215  KB    00:11
…
…
Installing base65.tgz    100% |**************************| 52181 KB
…
…
Installing xserv65.tgz    100% |**************************| 22686 KB
Location of sets? (cd0 disk http or 'done' [done]

Pour terminer, l'installateur s'occupe de la configuration et de générer un noyau unique :

Saving configuration files…done.
Making all device nodes…done.
Relinking to create a unique kernel…

CONGRATULATIONS! Your Openbsd install has been successfully completed!

When you login to your new system the first time, please read your mail using the 'mail' command.

Exit to (S)hell, (H)alt or (R)eboot? [reboot]

Et voilà, l'installation est terminée, on valide le reboot pour redémarrer.

Lors du premier démarrage, éditez (créez) le fichier /etc/installurl puis assurez-vous d'avoir une ligne contenant le miroir de téléchargement choisi. Pour faire simple, autant utiliser le CDN d'OpenBSD qui vous redirigera automatiquement vers un serveur rapide :

https://cdn.openbsd.org/pub/OpenBSD

Pour les personnes souhaitant chiffrer entièrement leur serveur (pour protéger les données en cas de cambriolage par exemple), rendez-vous un peu plus loin dans le manuel.

2. Gérer son serveur

2.1. Surveiller son serveur

Une fois votre serveur en route, il faudra veiller à ce que tout fonctionne correctement. Ça paraît bête, mais c'est très important. Inutile d'aller plus loin si vous comptiez laisser votre serveur dépérir 😉. Heureusement, tout est déjà prévu dans OpenBSD pour nous faciliter la vie.

En effet, chaque jour un rapport est généré et envoyé à l'administrateur du serveur, cet utilisateur répondant au charmant nom de "root". Vous pourrez y lire un tas d'informations utiles comme :

  • Une vérification des systèmes de fichier est réalisée. C'est pratique pour voir si on est bientôt à court d'espace de stockage.
  • Quels fichiers ont été modifiés, lesquels et comment? Normalement, c'est vous qui vous en êtes chargé. Sinon, c'est qu'il y a un problème, voire une intrusion. On vous indique aussi si de nouveaux programmes ont été ajoutés ou retirés. Cela pourrait ressembler à ceci :

    Running security(8):
    
    Checking mailbox ownership.
    user spamd.black mailbox is owned by root
    user spamd.black mailbox is -rw-r--r--, group wheel
    
    
    ======
    /etc/rc.local diffs (-OLD  +NEW)
    ======
    --- /var/backups/etc_rc.local.current   Sat Jun  4 03:46:48 2016
    +++ /etc/rc.local       Thu Oct 20 09:46:54 2016
    @@ -1 +1 @@
    -su pi -c "tmux new -s rtorrent -d rtorrent"
    +/usr/bin/su pi -c "/usr/bin/tmux new -s rtorrent -d /usr/local/bin/rtorrent"
    
    
    ======
    /etc/spwd.db SHA-256 checksums
    ======
    OLD: 075455a721ef[…]b942f590fb8e3edfd88c5dd4
    NEW: 37eba7537dd7[…]42468cc4cbe768fcf496b230
    
    

    On y voit des alertes sur les propriétaires de certains fichiers.

    Ensuite, les modifications sur un fichier. Les lignes commençant par un + correspondent à ce qui a été rajouté et celles qui commencent par un - à ce qu'il y avait avant.

    Enfin, on voit qu'une somme de contrôle a changé : un nouvel utilisateur a-t-il été créé par vos soins ? Espérons que oui puisque le fichier /etc/spwd.db a changé. Normalement, ce rapport est très peu rempli, c'était un exemple 😉.
Tout ceci, c'est bien beau, mais comment recevoir ces messages?

Comme vous allez le voir, c'est d'une simplicité enfantine :

  1. Éditez le fichier /etc/mail/aliases ;
  2. Ajoutez tout en bas une ligne comme celle-ci :
    root : toto@ouaf.xyz
    

    Bien sûr, vous remplacerez l'adresse mail par celle que vous consultez régulièrement.

  3. Lancez maintenant la commande # newaliases.
  4. Relancez le serveur mail intégré à OpenBSD :

    # rcctl restart smtpd
    

Et voilà!

Si vous voulez tester que tout fonctionne comme prévu, saisissez la commande suivante pour vous envoyer un mail test :

echo "Coucou toi!" | mail -s "test" root

Vous devriez le recevoir à l'adresse définie dans /etc/mail/aliases.

Ne vous reste plus qu'à lire soigneusement ces messages que le serveur va vous envoyer.

Si besoin, vous pouvez configurer le nom de domaine des adresses d'expéditeur de mail, dans le fichier /etc/mail/mailname. Editez ce fichier, et mettez, en première ligne, votre nom de domaine. Par exemple : chezmoi.tld

Ainsi, les mails qui seront envoyés par l'utilisateur root partiront avec l'expéditeur "root@chezmoi.tld", et ceux qui seront envoyés par votre utilisateur partiront avec l'expéditeur "mon-user@NDD".

Si vous souhaitez surveiller avec davantage de finesse votre serveur, vous voudrez sans doute lire la partie parlant de monitoring ou celle parlant de sécurité.

2.2. Le Pare–feu

Quoi? Déjà le firewall?

Eh oui, on va commencer par cet élément essentiel à la sécurité du serveur. Avouez que ce serait dommage de travailler sur une machine vulnérable dès le départ. Donc avant d'aller plus loin : le pare-feu! Rassurez-vous, on va parler de choses simples.

Sur OpenBSD, le pare-feu s'appelle pf, comme "packet filter". Sa configuration se déroule dans le fichier /etc/pf.conf, et comme vous le verrez, est nettement plus facile à appréhender que celle d'iptables (l'outil servant à configurer le pare-feu sous Linux…).

Avant toutes choses, il faut se demander ce dont on va avoir besoin sur notre serveur. Un serveur web (http) ? Les mails ? Un serveur ftp ? Selon les réponses à ces questions, nous n'ouvrirons pas les mêmes ports. En effet, pour assurer un maximum de sécurité, on ne va rien laisser passer sauf ce que qui est réellement utile. Redoutable.

Pour trouver les ports sur lesquels écoutent les services dont vous pourriez avoir besoin, regardez le contenu du fichier /etc/services. Ainsi, écrire www ou 80 revient au même pour pf, mais est plus lisible pour les humains.

Les règles que vous allez définir seront appliquées dans l'ordre de lecture du fichier de configuration.

Prêts ? C'est parti pour un exemple détaillé. Nous allons configurer le parefeu pour un simple site web avec accès sur les ports 80 (www) et 443 (https).

On commence par tout bloquer, et enregistrer dans le journal les connexions interdites avec le mot log.

block log

Afin de nous simplifier la vie, nous allons mettre les ports à ouvrir dans une variable. Ça sera particulièrement pratique lorsqu'on aura davantage de ports à ouvrir.

tcp_pass = "{ 80 443 }"

Remarquez que c'est identique à tcp_pass = "{ www https }"

Ensuite, on autorise les visiteurs éventuels à accéder à votre serveur. Ce seront des connexions dites "entrantes", on utilisera donc le mot clé "in". Au lieu de chercher le nom de votre interface réseau (qui dépend de votre matériel), nous allons préciser le nom du groupe que portent ces interfaces afin que ça fonctionne sans inquiétudes : egress.

pass in quick on egress proto tcp to port $tcp_pass 
T'es mignon hein, mais c'est du charabia tout ça!

D'accord, nous allons expliquer ce que veut dire cette syntaxe. On peut la traduire la ligne de configuration précédente ainsi : "laisse passer vers l'intérieur (pass in) sans t'occuper ensuite des règles suivantes (quick) à travers l'interface egress (on egress) pour le protocole tcp (proto tcp) vers les ports dans $tcp_pass (to port $tcp_pass).

Pfouh!

Enfin, on autorise tout le trafic en sortie (mot clé "out") :

pass out on egress 

Cela nous donne au final :

tcp_pass = "{ 80 443 }"
block log

pass in quick on egress proto tcp port $tcp_pass 
pass out on egress all

Facile, non ?

Je vous propose de remplacer la dernière ligne par quelque chose d'un peu plus restrictif :

pass out on egress proto { tcp udp icmp ipv6-icmp } modulate state

On précise simplement les protocoles autorisés en sortie avec une précaution pour chaque connexion sortante (modulate state).

Vous l'aurez compris, pf nous permet un contrôle de premier ordre sur notre serveur. Dans un premier temps, vous souhaiterez simplement choisir quels ports doivent être ouverts.

Cela fait de nombreuses nouvelles notions, prenez le temps de relire ce qui a été écrit jusqu'ici si besoin.

Lorsque vous serez plus à l'aise, sachez qu'on pourra filtrer le trafic entrant et sortant, et même rediriger une partie de celui-ci vers des services internes (par exemple un anti-spam). Je vous invite à lire la partie "aller plus loin avec pf". Vous y verrez comment ignorer certaines listes d'IP connues comme nuisibles que l'on enregistrera dans des tables, des règles contre les attaques bruteforce ou encore une proposition d'outil qui ajoute sur liste noire d'éventuels pirates en temps réel. Jetez aussi un œil à la page du wiki obsd4* consacrée à pf.

Je vous laisse construire votre fichier /etc/pf.conf selon vos besoins. Partez de l'exemple vu au-dessus puis ajoutez les ports à ouvrir pour commencer. N'hésitez pas à consulter l'exemple fourni à la fin du document.

Pour être sûr, on peut avoir un exemple pour ouvrir le port SSH ?

Si le port SSH configuré est le 222, alors vous aurez dans la configuration de pf :

pass in quick on egress proto tcp to port 222

Bien sûr, vous pouvez aussi vous contenter de modifier uniquement la variable tcp_pass :

tcp_pass = "{80 443 222}"
pass in…

2.3. Commandes pratiques pour pf

Un dernier mot avant de terminer cette partie. Enfin plutôt quelques commandes bien pratiques :

  • Désactiver le pare-feu :
    # pfctl -d
    
  • Activer le pare-feu avec le fichier /etc/pf.conf :
    # pfctl -ef /etc/pf.conf
    
  • Relancer le pare-feu :
    # pfctl -d && pfctl -ef /etc/pf.conf
    
  • Recharger la configuration du pare-feu :
    # pfctl -f /etc/pf.conf
    
  • Vider les règles du pare-feu (Attention!), ça peut être pratique lorsqu'on s'est auto-banni du serveur (si si, ça arrive même aux meilleurs…) :
    # pfctl -F all
    
  • Voir en temps réel ce que le pare-feu bloque (à condition que vous ayez mis le mot clé log dans la configuration) :

    # tcpdump -n -e -ttt -i pflog0
    

  • Voir à tout instant les logs enregistrés :
    # tcpdump -n -e -ttt -r /var/log/pflog
    
  • Afficher la liste des IP bloquées dans une table :
    # pfctl -t nom_de_la_table -T show
    
  • Ajouter une IP dans une table
    # pfctl -t nom_de_la_table -T add 123.456.678.909
    
  • Retirer une IP d'une table
    # pfctl -t nom_de_la_table -T delete 123.456.678.909
    
  • Lister toutes les règles actives :
    pfctl -sr
    

2.4. Aller plus loin avec pf

2.4.1. Blacklist d'IP nuisibles

Certaines adresses IP sont connues pour être les sources d'attaques. Vous pouvez configurer pf pour qu'il rejette automatiquement toutes les requêtes venant de ces IP.

Pour nous faciliter la vie, Stéphane HUC s'est donné la peine d'écrire des outils qui rassemblent des listes d'IP nuisibles de plusieurs sources. Merci qui ? Merci Stéphane !

Son projet se trouve à cette adresse.

Il contient des listes que vous pourrez utiliser avec d'autres logiciels que pf si vous avez l'envie d'y jeter un œil.

En attendant, nous allons utiliser directement les listes générées par ses bons soins.

On commence par télécharger les listes, tout en vérifiant leur intégrité. Nous les placerons dans un dossier /var/blockzones.

# mkdir -p /var/blockzones
# cd /var/blockzones
# ftp https://stephane-huc.net/share/BlockZones/lists/badips_ipv4
# ftp https://stephane-huc.net/share/BlockZones/lists/badips_ipv6
# ftp https://stephane-huc.net/share/BlockZones/lists/BlockZones_GenLists.pub
# ftp https://stephane-huc.net/share/BlockZones/lists/BlockZones.sha512.sig

Pour vérifier l'intégrité des données, on lance ensuite :

signify -Cp BlockZones_GenLists.pub -x BlockZones.sha512.sig

Le message suivant doit vous être retourné :

Signature Verified
./badips_ipv4: OK
./badips_ipv6: OK
./bind.zone: FAIL
./hosts: FAIL
./baddomains: FAIL
./bogons_ipv4: FAIL
./local-zone: FAIL
./bogons_ipv6: FAIL
./README: FAIL

Les "FAIL" correspondent aux fichiers que je n'ai pas récupéré pour l'exemple. Pas d'inquiétudes à avoir donc pour ces derniers. 😁

Pour utiliser ces listes, on ajoute les lignes suivantes dans le fichier /etc/pf.conf :

set limit table-entries 400000
table <t_badips>  persist file "/var/blockzones/badips_ipv4"
table <t_badips6> persist file "/var/blockzones/badips_ipv6"


block quick from { <t_badips>, <t_badips6> }

Vous pouvez maintenant relancer le parefeu avec pfctl -f /etc/pf.conf. Et voilà, votre serveur sera nettement allégé à l'avenir.

Je vous invite à mettre à jour régulièrement les listes d'IP en mettant les lignes précédentes dans le fichier /etc/weekly.local par exemple.

Pour compléter les listes proposées par Stéphane, vous pouvez consulter celles que je rassemble avec le même projet ainsi que l'outil vilain en suivant ce lien.

2.4.2. Anti-bruteforce

Une méthode qu'utilisent les pirates pour s'en prendre à un serveur s'appelle "bruteforce". Ces attaques consistent à essayer toutes les combinaisons d'identifiants/mot-de-passe possibles jusqu'à tomber sur la bonne.

Si vous avez choisi des phrases de passe robustes, vous êtes normalement à l'abri. Toutefois, ces attaques utilisent inutilement des ressources sur votre serveur et peuvent potentiellement réussir un jour (avouez que ça serait pas de bol).

Afin de déjouer ces attaques, il faudrait prendre le temps de décortiquer les journaux des services que vous hébergez (dans /var/log et /var/www/logs) à la recherche d'échecs d'identification et repérer d'où viennent ces attaques pour en bannir les auteurs. Mais soyons honnête, c'est à la fois pénible et chronophage.

L'idéal serait un outil qui surveille les journaux à votre place et s'occupe de mettre sur la liste noire de votre parefeu les IP des "attaquants". Ça tombe bien, vous pouvez utiliser vilain ou sshguard qui sont faits pour ça.

En attendant, pf intègre déjà une protection qui limite le nombre de connexions sur un port pendant un temps donné. C'est très efficace et reste léger.

2.4.2.1. Anti-Bruteforce intégré à pf

Pf dispose d'une fonctionnalité très intéressante : les "tables" (tableaux). Ça va nous permettre de garder en mémoire certaines adresses IP de pirates qui tenteraient de compromettre le serveur. Par exemple, pour protéger le service SSH, on va procéder ainsi :

  1. Création d'une table pour enregistrer les IP abusives avec notre serveur SSH.
  2. Bloquer toutes les IP qui seraient dans la table précédente, et ne pas aller plus loin pour elles.
  3. Ouvrir le port ssh, mais enregistrer dans la table précédente toutes les IP qui tenteraient de se connecter plus de 3 fois par minute (attaque par bruteforce).

    Ça nous donne donc ceci :
ssh_port = "22"
table <ssh_abuse> persist
block in log quick proto tcp from <ssh_abuse> to any port $ssh_port
pass in on egress proto tcp to any port $ssh_port flags S/SA keep state (max-src-conn-rate 3/60, overload <ssh_abuse> flush global)

Notez que nous avons enregistré le numéro du port utilisé pour le serveur SSH. C'est inutile, car on peut mettre à la place de $ssh_port simplement ssh, c'est-à-dire le nom du service. Cependant, on peut vouloir changer le port par défaut du serveur SSH, comme décrit dans le chapitre sur ce service.

Voici un autre exemple pour un site web (ports http et https) :

http_ports = "{ www https }"         # ports http(s)
# Si + de 40 connexions toutes les 5 secondes sur les ports http(s)
# ou si elle essaie de se connecter + de 100 fois
# on ajoute l'ip pour la bloquer.
pass in on egress proto tcp to any port $http_ports flags S/SA keep state (max-src-conn 100, max-src-conn-rate 40/5, overload <http_abuse> flush global)

2.4.2.2. En temps réel avec vilain

Je me permets de vous proposer un outil que j'ai écrit avec l'aide de Vincent Delft dans le but de mettre sur liste noire d'éventuels pirates lorsque l'attaque a lieu. Notez bien qu'il est encore jeune et que vous devriez savoir ce que vous faites en l'utilisant. Par ailleurs, vos retours d'utilisation permettront de l'améliorer.

Le script en question s'appelle vilain. Vous pouvez suivre le lien suivant pour consulter le code.

Voici comment l'installer. Tout d'abord, on télécharge l'archive dans le dossier /tmp :

# cd /tmp
# ftp -o vilain.tgz https://framagit.org/prx/vilain/repository/master/archive.tar.gz

On décompresse l'archive :

# tar xvzf vilain.tgz

Ensuite, on procède à l'installation :

# cd vilain-master*
# make install

Afin que vilain puisse fonctionner, ajoutez une table à la configuration de pf afin de retenir les IP des attaquants. Éditez le fichier /etc/pf.conf pour y mettre :

table <vilain_bruteforce> persist
block quick from <vilain_bruteforce>

Rechargez pf avec # pfctl -f /etc/pf.conf puis éditez le fichier de configuration de vilain /etc/vilain.conf. Vous y trouverez quelques exemples de la forme suivante :

[nom du gardien]
logfile = /chemin/du/journal/a/inspecter
regex = expression reguliere qui retourne l'IP de l'attaquant en cas d'echec

D'autres options sont disponibles, comme le nombre d'échecs avant le bannissement, les IP à ignorer s'il y a une erreur…

Afin de lancer vilain, vous avez besoin de python3. Installez le paquet python-3.6.* par exemple.

Vous pouvez maintenant activer et lancer vilain comme n'importe quel service :

# rcctl enable vilain
# rcctl start vilain

Si vous consultez les journaux dans le fichier /var/log/daemon, vous y verrez des messages comme :

Start vilain for ssh
Start vilain for ssh2
Start vilain for http401
Start vilain for smtp
Start vilain for dovecot

vilain est en train de protéger votre serveur.

Vous pouvez si vous le souhaitez lancer régulièrement cette commande pour retirer les IP bannies depuis trop longtemps :

pfctl -t vilain_bruteforce -T expire 86400

Pour voir les IP bannies, saisissez :

pfctl -t vilain_bruteforce -T show

2.4.2.3. En temps réel avec sshguard

Contrairement à ce que son nom indique, sshguard est en mesure de vérifier les tentatives de connexions sur plusieurs services, pas seulement SSH.

Son installation sous OpenBSD n'est pas très compliquée à mettre en place. Comme vilain, vous devrez créer une table dans pf qui contiendra toutes les IP mises sur liste noire. Ainsi, on ajoute dans le fichier /etc/pf.conf une nouvelle table contenant les IP des pirates :

table <sshguard> persist
block in from <sshguard>

Rechargez le parefeu avec pfctl -f /etc/pf.conf.

Maintenant, on installe sshguard comme on a l'habitude de le faire :

# pkg_add sshguard

Nous pouvons maintenant activer et lancer sshguard :

# rcctl enable sshguard
# rcctl start sshguard

Et voilà, votre serveur est désormais sous bonne garde.

Vous voudrez peut-être mettre sur liste blanche quelques adresses IP avec l'option "-w". Procédez ainsi (cette option peut être employée plusieurs fois).

rcctl set sshguard flags -w 192.168.1.0/24 -w 123.123.123.123

2.5. SSH : administrer à distance

2.5.1. Configuration de SSH

SSH, c'est magique. Cet outil vous permettra de vous connecter au serveur à partir d'un autre ordinateur. Vous pourrez alors l'administrer à distance sans devoir y brancher un clavier et un écran. À vrai dire, sauf exception, tous les serveurs sont administrés ainsi, mais vous êtes chez vous après tout, donc vous pouvez faire comme vous voulez.

De plus, SSH ne sert pas qu'à ça. Il est capable de créer des tunnels chiffrés vers votre serveur. Vous serez en mesure d'avoir un espace de stockage de fichiers en SFTP, voire d'en faire une sorte de NAS.

Quoi qu'il en soit, si vous n'avez pas activé SSH lors de l'installation d'OpenBSD, vous pouvez l'activer avec la commande suivante :

# rcctl enable sshd

Bien que ce protocole soit fiable, ça ne coûte rien de prendre quelques précautions de sécurité. On va éditer la configuration de SSH dans le fichier /etc/ssh/sshd_config.

  • Vous pouvez changer le port utilisé par défaut, par exemple: Port 222. Dans tous les cas, pensez à ouvrir ce port dans le parefeu et le rediriger dans le routeur.
  • Très important, retirez à root la possibilité de se connecter en SSH avec cette ligne, ceci afin d'éviter des attaques par bruteforce directement sur l'identifiant "root" :
    PermitRootLogin no
    

Pour vous connecter à la machine, il faudra créer un utilisateur simple, par exemple toto, avec la commande adduser.

Une fois les modifications réalisées, relancez le démon SSH :

# rcctl reload sshd

Par la suite, pour vous connecter au serveur, vous utiliserez la commande suivante à partir de votre ordinateur (dans un terminal, ou avec un client comme putty sous windows) :

$ ssh toto@votredomaine.com

Et si vous avez changé le port par défaut :

$ ssh -p 222 toto@votredomaine.com

Ça demandera le mot de passe de l'utilisateur toto, puis vous pourrez administrer le serveur à distance.

2.5.2. Connexion sans mot de passe

Il est tout à fait possible de se connecter en SSH sans utiliser de mot de passe. À la place, on se sert de paire de clés. C'est une bonne idée au moins pour les raisons suivantes :

  • C'est nettement plus sécurisé.
  • Ça évite d'écrire un mot de passe à chaque fois.
  • C'est pratique et permet de lancer des commandes ssh dans des scripts.

Toutefois, cela vous impose d'avoir la clé privée sur l'ordinateur servant à se connecter, ce qui n'est pas forcément le cas.

Voici la marche à suivre :

Sur le serveur, modifiez le fichier /etc/ssh/sshd_config pour qu'il contienne cette ligne :

PubkeyAuthentication yes

Maintenant, sur l'ordinateur qui veut accéder au serveur, nous allons générer la paire de clés avec la commande suivante :

ssh-keygen -t ed25519 -f ~/.ssh/clessh -a 64

Vous trouverez deux nouveaux fichiers :

  • ~/.ssh/clessh : c'est votre clé privée, ne la divulguez jamais à personne.
  • ~/.ssh/clessh.pub : la clé publique. Contrairement à son nom, c'est comme une serrure dans laquelle seule la clé privée peut entrer.

L'algorithme ed25519 est utilisé. Très sécurisé, il n'est pas supporté par d'anciens serveurs (normalement pas votre cas). Pour la forme, notez qu'il est possible d'utiliser une clé RSA ainsi :

$ ssh-keygen -t rsa -b 4096 -p -f ~/.ssh/clessh -o -a 64

Ne mettez pas de mot de passe puis patientez le temps que les clés soient générées.

Vous prendrez soin d'éditer le fichier ~/.ssh/config de votre utilisateur pour le remplir ainsi :

Host votreserveur
HostName nomtreslong.vraimenttroplong.long
User jeanbaptiste.professeurdanseur
Port 222
PasswordAuthentication no
IdentityFile ~/.ssh/clessh

Bien sûr, vous modifierez le nom de domaine de votre serveur ainsi que le nom de l'utilisateur qui doit se connecter. Ensuite, lancez la commande suivante pour copier la clé publique sur le serveur.

ssh-copy-id -p xxx -i ~/.ssh/clessh.pub "jeanbaptiste.professeurdanseur@nomtreslong.vraimenttroplong.long"

Ici, remplacez "xxx" par le port utilisé par SSH.

Dans le cas où l'outil ssh-copy-id ne serait pas disponible, il faut copier la clé publique manuellement. Pour l'afficher, tapez

$ cat ~/.ssh/clessh.pub

Connectez-vous sur le serveur en SSH, puis ajoutez dans le fichier ~/.ssh/authorized_keys le contenu du fichier affiché précédemment.

Une fois ceci fait, vous pouvez vous connecter sans devoir entrer de mot de passe avec simplement la commande :

$ ssh votreserveur

Pratique non?

Si ça fonctionne comme prévu, vous pouvez si vous le souhaitez désactiver l'identification par mot de passe pour de bon afin de ne garder que le jeu de clés comme possibilités. Modifiez le fichier /etc/ssh/sshd_config pour qu'il contienne cette ligne :

PasswordAuthentication no

Attention à ne pas perdre votre jeu de clés !

2.5.3. Transférer un fichier

Vous aurez certainement besoin d'envoyer des fichiers sur votre serveur de temps en temps. Une fois que SSH est configuré, vous pourrez utiliser la commande scp depuis n'importe quel ordinateur afin de copier un fichier vers votre serveur. Par exemple :

$ scp -P <port ssh> utilisateur@chezmoi.tld:/emplacement/de/destination fichier-a-copier

C'est très pratique.

Si vous souhaitez toutefois transférer de nombreux fichiers, sauvegarder ou stocker des documents, tournez-vous plutôt vers le protocole SFTP, plus sécurisé et disposant de davantage de fonctionnalités comme la reprise d'un transfert partiel.

Si les fichiers sont trop gros, vous pouvez les découper pour réaliser les transferts en plusieurs fois.

Quoi que vous décidiez, c'est toujours une bonne idée de vous assurer que le transfert s'est bien déroulé en vérifiant la somme de contrôle des fichiers envoyés.

2.5.4. Aller plus loin avec SSH

Pour en apprendre plus sur la sécurisation et l'utilisation de SSH, vous pouvez lire les pages suivantes :

Je vous invite à mettre en place un outil contre les attaques par bruteforce, notamment avec sshguard ou vilain, deux outils présentés dans ce document.

2.6. Maintenir le système à jour

Pour conserver un système robuste et sécurisé, il est essentiel de le maintenir à jour. Afin d'appliquer les correctifs de sécurité, il faudra mettre à jour :

  • Le système de base
  • Les ports de programmes tiers éventuellement installés par vos soins si une version plus récente est disponible.

Plusieurs méthodes pour faire ça sont possibles avec ses avantages et inconvénients éventuels.

Pour les pressés :

# syspatch
# pkg_add -u

2.6.1. Mettre les paquets à jour

Mettre les paquets à jour est l'histoire d'une seule commande :

# pkg_add -u

Oui, c'est tout. Merci à solene qui a rendu cela possible.

Puisque ce paragraphe est un peu court, j'en profite pour vous donner deux astuces 😁. Je vous conseille d'ajouter au fichier /etc/daily.local la commande

pkg_add -nu

De cette façon, dans le mail journalier envoyé par Charlie Root, vous verrez ce qu'il pourrait se passer si des paquets pouvant être mis à jours sont disponibles. En réalité, rien n'est fait, car si un programme mis à jour doit être redémarré, il risque de ne pas fonctionner le temps que vous le relanciez. Ainsi, vous êtes avertis d'éventuelles mises à jour à appliquer, et avec l'option -n, les paquets sont gardés dans le cache afin de gagner du temps sans risquer de mettre un service en panne s'il doit être redémarré suite à la mise à jour. Vous lancerez à la main pkg_add -u lorsque vous en aurez l'occasion.

Si vous souhaitez tout de même appliquer les mises à jour automatiquement, je vous conseille d'installer avant tout le paquet checkrestart qui vous indiquera si un service doit être relancé suite à la mise à jour. Cela donnera donc dans /etc/daily.local :

pkg_add -u
echo "Service à relancer avec rcctl restart:"
checkrestart

Il faudra tout de même recharger les services à la main avec rcctl.

2.6.2. Mettre le système à jour

Tout d'abord, un petit rappel : OpenBSD est disponible en 3 "saveurs" (flavour) :

  • release : il s'agit de la version publiée et que vous avez sans doute téléchargée pour installer OpenBSD.
  • stable : c'est la version release avec plusieurs correctifs de sécurité. C'est celle-ci que nous souhaiterons suivre.
  • current : c'est la prochaine mouture en préparation d'OpenBSD, dans le dépôt CVS (qui sert au développement du code source).

Il peut en effet arriver que des bugs soient découverts. À chaque fois, des correctifs sont rapidement proposés. Il est alors recommandé d'appliquer les patchs de sécurité.

Depuis la version 6.1, cette opération se réalise très simplement avec la commande suivante :

# syspatch

Les patchs binaires sont alors téléchargés et installés. Wouhou ! Ça ressemblait à ça sous OpenBSD 6.1 :

Get/Verify syspatch61-002_vmmfpu.tgz 100% |*******************************|  9377 KB    00:49    
Installing patch 002_vmmfpu
Get/Verify syspatch61-003_libress… 100% |*******************************| 11391 KB    00:22    
Installing patch 003_libressl
…

Cet outil n'est disponible que pour les architectures i386, amd64, et plus récemment arm64. Vous souhaiterez peut-être utiliser l'ancienne méthode de récupération des sources et installation manuelle décrite succintement par la suite.

2.6.2.1. Mise à jour du système par compilation

On va expliquer ci-dessous comment mettre OpenBSD à jour en compilant les sources. Ce n'est pas très compliqué contrairement à ce que l'on peut penser et parfois nécessaire si vous ne pouvez pas utiliser les solutions proposées précédemment. Il faut se contenter de suivre les étapes unes par unes. En cas de doute, n'hésitez pas à consulter la FAQ dédiée.

Pour commencer, on récupère les sources "patchées" et corrigées :

# cd /usr
# cvs -qd anoncvs@anoncvs.fr.openbsd.org:/cvs get -rOPENBSD_6_5 -P src
# cvs -qd anoncvs@anoncvs.fr.openbsd.org:/cvs get -rOPENBSD_6_5 -P ports

La première fois, c'est long. Pas d'inquiétudes donc, préparez un petit café pendant ce temps. Si vous aviez déjà les sources, il suffit alors de lancer :

# cd /usr/src
# cvs -q up -rOPENBSD_6_5 -Pd
# cd /usr/ports
# cvs -q up -rOPENBSD_6_5 -Pd

Vous serez peut-être intéressés par les changements effectués dans les sources depuis la dernière fois. Cette commande permet de consulter ces modifications :

cvs log -rOPENBSD_6_5:

Ou alors, qui donne un résultat moins long :

cvs diff -u -rOPENBSD_6_5

Ensuite, les commandes suivantes permettront de compiler le noyau :

# cd /sys/arch/$(machine)/conf
# config GENERIC.MP
# cd /sys/arch/$(machine)/compile/GENERIC.MP
# make clean 
# make obj
# make config
# make
# make install

Si vous ne disposez pas d'un processeur multi-cœurs, vous remplacerez `GENERIC.MP` par `GENERIC`. Laissez `GENERIC` en cas de doute.

Vous voudrez peut-être prendre un autre café ou une soupe selon la puissance de votre machine.

Il faut maintenant redémarrer sur le nouveau noyau (commande reboot) avant de passer à la suite, où l'on met à jour les fichiers du système après un petit nettoyage.

# rm -rf /usr/obj/*
# cd /usr/src
# make obj 
# make build

Une fois que c'est terminé, mettez à jour les fichiers de configurations qui auraient pu changer et recréez les "devices" :

# sysmerge 
# cd /dev && ./MAKEDEV all

Voilà, rien de plus qu'une série de petites commandes. Mais je crois qu'on préfère tous syspatch 😁.

2.6.3. Être averti des mises à jour

Pour savoir si des mises à jour doivent être appliquées, vous pouvez consulter la page errata qui contient la liste des patchs de sécurité disponibles.

Vous pouvez aussi être averti par mail (et ça c'est top 😁). Pour recevoir les messages importants de mises à jour disponibles sur le système, inscrivez-vous aux listes announce et security-announce. Pour ça, on envoie un premier mail à majordomo@OpenBSD.org contenant simplement :

subscribe announce

Puis envoyez un second message avec :

subscribe security-announce

Je vous conseille aussi de vous inscrire à la liste indiquant qu'il existe une nouvelle version des ports en vous inscrivant à la liste ports-security en envoyant toujours à la même adresse un message contenant :

subscribe ports-security

2.6.4. Changer de version

Lorsqu'une nouvelle version majeure d'OpenBSD est disponible, la procédure de mise à jour est toujours détaillée sur le site officiel. Vous pouvez par curiosité consulter les notes de version lors du passage de la 6.3 à la 6.4.

2.7. Sauvegardes

On peut utiliser un serveur à la maison pour sauvegarder ses documents. C'est une précaution qui ne fait jamais de mal.

Il faut penser aussi à sauvegarder le serveur en cas de défaillance du disque dur qui vieillit un peu, d'un orage virulent ou encore d'un dérapage incontrôlé du chat qui joue derrière les meubles…

Pour l'exemple, nous allons réaliser le tout sur un disque dur supplémentaire (disque dur externe) que l'on va préparer afin d'avoir deux partitions :

  • Une partition pour sauvegarder le serveur ;
  • Une partition pour les sauvegardes personnelles.

2.7.1. openrsync

Avant toutes choses, sachez qu'OpenBSD est livré avec l'outil openrsync qui vous sera très utile pour synchroniser deux répertoires sur votre serveur, voire de votre serveur vers une autre machine à travers un tunnel ssh. Il est d'autant plus pratique qu'il ne copie que les fichiers qui ont changés.

Quelques exemples :

  • openrsync -r repertoire1/ /home/repertoire2/ : copie le contenu de repertoire1 vers repertoire2 ainsi que tous son contenu.
  • openrsync -r --delete repertoire1/ /home/repertoire2/ : Pareil qu'au-dessus, mais supprime les fichiers absents dans repertoire1 et présents dans repertoire2.
  • openrsync -a repertoire1/ /home/repertoire2/ : Pareil que le premier, mais conserve les permissions, les liens symboliques…
  • openrsync -e "ssh" -a repertoire1/ toto@chezmoi.tld:/backup : sauvegarde le contenu de repertoire1 sur un serveur accessible en ssh dans le dossier /backup via le compte toto.

2.7.2. Partitionnement du disque dur

Branchez le disque dur au serveur. Si vous lancez la commande dmesg, vous verrez apparaître quelque chose comme ça :

umass0 at uhub0 port 1 configuration 1 interface 0 "Western Digital Ext HDD 1021" rev 2.00/20.21 addr 2
umass0: using SCSI over Bulk-Only
scsibus2 at umass0: 2 targets, initiator 0
sd1 at scsibus2 targ 1 lun 0: <WD, Ext HDD 1021, 2021> SCSI2 0/direct fixed serial.10581021383235373034
sd1: 1907727MB, 512 bytes/sector, 3907024896 sectors

Ces messages nous apprennent que le disque branché sera identifié par sd1.

On initialise le disque avec fdisk en créant une grande partition:

# fdisk -i sd1

On va diviser cette partition en 2 avec disklabel. On entre donc en mode édition :

# disklabel -E sd1

Maintenant, on peut créer les partitions l'une après l'autre. En cas de doute, appuyez sur p pour afficher l'état actuel du disque.

  • Pour créer la première partition, on saisit a a. Cela signifie "ajouter une partition a".
    • Laissez l'offset par défaut.
    • Réglez la taille de la partition selon vos besoins. Notez que vous pouvez définir une taille avec :
      • Une unité : 4G;
      • Avec une proportion du disque : 50%;
      • Avec un pourcentage de l'espace libre restant : 25&.
    • Choisissez le système de fichier 4.2BSD.
  • Créez la deuxième partition de la même façon avec cette fois-ci la combinaison a d. Notez qu'on ne peut pas créer une partition "c", cette lettre étant réservée pour désigner le disque entier. De même, je préfère ne pas utiliser "b" ici, car c'est souvent (mais pas obligatoirement) utilisé pour une partition d'échange "swap". Toutes les autres lettres de l'alphabet restent valables.

    Une fois terminé, utilisez la lettre q pour quitter et appliquer les changements.

    Regardons maintenant l'état du disque en entrant disklabel sd1 :

    # /dev/rsd1c:
    type: SCSI
    disk: SCSI disk
    label: Ext HDD 1021
    duid: 782f1ddb783cdd13
    flags:
    bytes/sector: 512
    sectors/track: 63
    tracks/cylinder: 255
    sectors/cylinder: 16065
    cylinders: 243201
    total sectors: 3907024896
    boundstart: 64
    boundend: 3907024065
    drivedata: 0
    
    16 partitions:
    #            size       offset  fstype [fsize bsize  cpg]
      a:    629153472           64  4.2BSD   4096 32768    1
      d:   3277870464    629153536  4.2BSD   8192 65536    1 
      c:   3907024896            0  unused
    

Au secours, c'est quoi tout ça???

Pas de panique, tout n'est pas important. Commençons pour une fois par les dernières lignes. Chaque partie décrit une caractéristique de la partition.

Partition Taille Début Système de fichier Divers
a: 629153472 64 4.2BSD 4096 3…
d: 3277870464 629153536 4.2BSD 8192 6…

L'autre point important (parce qu'il faut l'avouer, il y a beaucoup d'informations qui ne nous serviront pas), c'est le "duid".

duid: 782f1ddb783cdd13

Cet élément nous permettra d'identifier le disque lorsqu'on voudra le monter. Si vous voulez le retrouver, vous pouvez aussi entrer :

# sysctl hw.disknames
hw.disknames=wd0:bfb4775bb8397569,cd0:,wd1:56845c8da732ee7b,wd2:f18e359c8fa2522b

Nous avons presque terminé, il faut maintenant formater les deux partitions créées (a et d) :

# newfs /dev/rsd1a
# newfs /dev/rsd1d

2.7.3. Sauvegarde de la racine du serveur

OpenBSD a déjà pensé à tout. En effet, il sauvegardera chaque jour le système si une partition /altroot est présente.

Nous allons donc ajouter la ligne suivante dans le fichier /etc/fstab :

782f1ddb783cdd13.a /altroot ffs xx 0 0

Vous remarquerez qu'on identifie la partition avec <numéro duid du disque>.a.

Afin que le serveur soit sauvegardé chaque nuit, ajoutez maintenant la ligne suivante dans le fichier /etc/daily.local :

ROOTBACKUP=1

Et c'est tout!

Si un jour le disque du serveur a une défaillance, vous pourrez quand même démarrer pour le dépanner. Il faudra alors booter sur la partition de sauvegarde. Tout cela se passera au tout début du démarrage de la machine, lorsque vous verrez le prompt boot >. Vous écrirez à ce moment là :

boot > set device hd1a
boot > boot -s

Ou tout en une seule fois :

boot > boot -s hd1a:/bsd

Si le moment venu vous ne savez plus sur quelle partition se trouve votre sauvegarde, entrez ceci :

boot > machine diskinfo

ATTENTION : seul le contenu de la partition racine / est sauvegardé. Si /usr/local, /var ou autres sont montées sur des partitions respectives, elles ne seront pas sauvegardées. Ce n'est pas grave pour dépanner un système puisqu'avec le partitionnement par défaut, vous disposerez quand même du système de base, mais en aucun cas des paquets tiers installés ou vos données de sites web, logs… Le paragraphe suivant est donc essentiel, ne passez pas à côté 😉

2.7.4. Autres sauvegardes

Nous allons utiliser la seconde partition du disque externe pour y sauvegarder les autres données qui nous semblent importantes. Tout d'abord, on crée un point de montage :

# mkdir -p /mnt/sauvegardes

Ensuite, on ajoute une ligne au fichier /etc/fstab pour monter ce disque :

782f1ddb783cdd13.d /mnt/sauvegardes ffs rw,nodev,nosuid,softdep,noatime 1 2

Afin de le monter, entrez mount -a.

Vous pouvez changer les droits en écriture sur ce disque avec chmod ou l'attribuer à un utilisateur.

Je vous conseille d'installer l'excellent outil rsync pour vos sauvegardes, qui ne copiera que les fichiers qui ont été modifiés. Voici un exemple d'utilisation sur votre serveur.

Ajoutez au fichier /etc/weekly.local les lignes suivantes afin de sauvegarder quotidiennement les dossiers /var et /usr/local :

/usr/local/bin/rsync -a --delete /var/ /mnt/sauvegardes/var.bak/
/usr/local/bin/rsync -a --delete /usr/local/ /mnt/sauvegardes/usrlocal.bak/

Si vous ne voulez pas installer rsync, il vous est toujours possible de vous servir des outils présents de base dans OpenBSD :

Pour dupliquer un dossier /SRC dans un dossier /DST, vous pouvez entrer :

cd /SRC && dump 0f - . | (cd /DST && restore -rf - )

N'hésitez pas à consulter la FAQ officielle sur le sujet.

Notez que vous pouvez aussi envoyer des données à sauvegarder de votre ordinateur personnel si vous voulez utiliser votre serveur comme espace de stockage. À partir de cet ordinateur, lancez la commande :

$ rsync -e "ssh -p <port ssh>" -avz --progress --delete /dossier/a/sauvegarder \
	toto@chezmoi.tld:/mnt/sauvegarde/toto

On utilise une connexion SSH avec le compte toto pour envoyer tout un dossier sur le serveur.

Cette solution peut ne pas convenir, en particulier si vous souhaitez permettre à plusieurs utilisateurs de réaliser des sauvegardes. Préférez dans ce cas la mise en place d'un chroot SFTP.

Une autre solution consiste à utiliser syncthing détaillé plus loin.

3. OpenNTPD : un serveur à l'heure

Il est essentiel que votre serveur dispose d'une date et heure justes. Normalement un système d'exploitation, et OpenBSD fait de même, récupère cette information du matériel (carte mère). Néanmoins, dans certains cas cette donnée n'est pas fiable : matériel embarqué, machine virtuelle … Votre machine doit disposer d'une date et d'une heure précises avec peu de variation, sinon certaines données n'auront plus de valeur et vous devrez faire face à de nombreux problèmes : fichiers de logs inutiles, agenda fou, bases de données corrompues …

Afin de maintenir à l'heure votre beau serveur, nous allons utiliser OpenNTPD qui permet de synchroniser notre horloge à intervalles réguliers sur des serveurs de temps de confiance. Pas d'inquiétude, là encore c'est très simple.

3.1. Installation

OpenNTPD développé par l'équipe OpenBSD est déjà présent sur votre machine. Nous devons juste préciser à notre serveur de lancer OpenNTPD au démarrage et se synchroniser aussitôt. Pour cela, on entre :

rcctl set ntpd flags -s

3.2. Configuration

Nous allons maintenant passer à l'étape de configuration. Tout se passe dans un seul fichier situé ici : /etc/ntpd.conf

# See ntpd.conf(5) and /etc/examples/ntpd.conf

## To browse Public NTP servers
## http://support.ntp.org/bin/view/Servers/WebHome#Finding_A_Time_Server

# Serveurs preferes

server 0.fr.pool.ntp.org
server 1.fr.pool.ntp.org
server 2.fr.pool.ntp.org
server 3.fr.pool.ntp.org

# Serveurs de backup
servers pool.ntp.org

# use all detected timedelta sensors
sensor *

# get the time constraint from a well-known HTTPS site
constraints from "https://www.openbsd.org/"

On liste plusieurs serveurs de temps utilisés et on termine par se référer à un site disponible via TLS de confiance pour éviter les attaques "Man in the middle".

Terminez par relancer ntpd pour prendre les changements en compte :

# rcctl restart ntpd

Et voilà 😁

4. Héberger un site web

Héberger votre propre site web, en voilà une bonne idée ! OpenBSD intègre par défaut un serveur HTTP qui s'appelle tout simplement httpd. Il ne propose pas de fonctionnalités exotiques, mais sa légèreté le rend d'autant plus simple à configurer et moins sensible à d'éventuelles failles de sécurité. Il s'avère amplement suffisant dans la plupart des cas. Si vous avez réellement besoin d'un serveur HTTP plus complet, sachez que nginx et apache sont disponibles.

Nous évoquerons dans cette partie la mise en place d'un site web, l'utilisation de PHP puis présenterons plusieurs applications.

Avant d'aller plus loin, il est important de noter que pour des raisons de sécurité, le serveur web (http)d sera lancé en chroot dans le dossier /var/www.

Et c'est censé vouloir dire quoi?

En réalité, pour le serveur web (http), tous les documents qui sont "au-dessus" du dossier /var/www sont totalement inaccessibles. Pour lui, il s'agit de la racine /. Ce comportement peut être modifié, mais je vous le déconseille : autant garder un maximum de précautions.

4.1. Un site simple avec httpd

Ce que l'on appelle un "site simple" est constitué de plusieurs pages html. Voici comment mettre en place votre premier site.

On commence par créer un dossier qui contiendra les pages du site :

# mkdir /var/www/htdocs/mon_super_site

Copiez maintenant les pages de votre site dans ce dossier (index.html…). Une fois terminé, on va modifier les droits sur ce dossier pour qu'il appartienne à un utilisateur spécial : www. Il sera ainsi accessible au serveur web (http)d mais pas aux autres utilisateurs. Cette étape est facultative mais recommandée :

# chown -R www:daemon /var/www/htdocs/mon_super_site

Il ne nous reste plus qu'à modifier la configuration du serveur web (http)d. Pour cela, on va éditer (ou créer selon l'exemple situé dans /etc/examples) le fichier /etc/httpd.conf. Vous pourrez constater que sa configuration est très simple.

types { include "/usr/share/misc/mime.types" }

server "chezmoi.tld" {
        listen on * port 80
        root "/htdocs/mon_super_site"
}

Quelques explications :

  • types … : La première ligne permet de préciser les types des fichiers que le serveur pourra avoir à fournir. Ce n'est pas obligatoire, mais ça permet par exemple à un visiteur de voir directement une image dans son navigateur plutôt que de la télécharger lorsqu'il clique dessus.
  • server "chezmoi.tld" { : On définit ici le nom de domaine du site web, puis on indique que nous allons configurer ce site en ouvrant une accolade.
  • listen … : Le serveur écoute en ipv4 et ipv6 sur le port 80 (le port www par défaut).
  • root … : On indique où se trouve la "racine" du site. C'est le dossier contenant les pages html. Il est relatif au chroot évoqué plus haut, on ne note donc pas /var/www/ devant.

On termine en activant httpd et en le (re)démarrant :

# rcctl enable httpd
# rcctl restart httpd

Vous pouvez désormais aller admirer votre site. Toutes les pages html que vous placerez dans /var/www/htdocs/mon_super_site seront servies.

Petite astuce : vous pouvez envoyer les pages de votre site à l'aide d'un client comme le logiciel Filezilla ou via SFTP, seul un accès SSH au serveur est nécessaire.

Et voilà, c'est suffisant pour un simple site. Afin d'y accéder, n'oubliez pas d'ouvrir le port 80 (www) dans le parefeu et de le rediriger.

Si vous voulez en savoir plus, lisez la partie "Astuces pour httpd".

4.2. HTTPS

Prévoir un accès avec chiffrement pour votre site n'est pas obligatoire. C'est malgré tout intéressant si :

  • Certaines parties de votre site nécessitent un mot de passe (interface d'administration d'un blog, d'un forum…).
  • Vous vous souciez de la vie privée de vos visiteurs.

4.2.1. Obtenir un certificat avec letsencrypt

Nous allons proposer en exemple d'obtenir un certificat via letsencrypt.org, une autorité de certification gratuite dont un client est disponible sous OpenBSD nativement : acme-client. Sinon, vous pouvez lire le paragraphe dédié pour consulter les autres solutions et en apprendre davantage. C'est un service absolument génial tout à fait adapté à l'auto-hébergement.

Attention : vérifiez que le port 80 est bien ouvert sur votre parefeu (et si vous utilisez un adressage privé, vérifiez vos renvois de ports, beaucoup d'erreurs viennent de là) ! En effet, acme-client doit rendre disponible sur votre serveur des "fichiers secrets" pour obtenir le certificat.

Cet outil va vérifier que vous avez bien accès au domaine pour lequel vous souhaitez un certificat. Il procède ainsi :

  1. Il demande à letsencrypt un fichier unique, une sorte d'empreinte, qui est enregistré dans /var/www/acme.
  2. Ensuite, letsencrypt tente de récupérer ce fichier en allant sur votre site dans le dossier .well-known/acme-challenge pour certifier que c'est bien votre serveur. (Ce fichier est supprimé aussitôt après.) En gros, il demande http://chezmoi.tld/.well-known-acme-challenge/unfichiersecret.

    Cependant, votre site web est sans doute enregistré dans /var/www/htdocs/votresite, un autre dossier. Il faut donc rendre disponible le dossier /var/www/acme lorsque letsencrypt cherche à récupérer le fichier en question.

    Ajoutez ces quelques lignes dans votre fichier httpd.conf.

    server "chezmoi.tld" {
        root "/htdocs/super-site"
        listen on * port 80
        location "/.well-known/acme-challenge/*" {
            root "/acme"
            request strip 2
        }
    }
    

    Quelques explications :

Attention, il faut mettre cette portion pour chaque sous-domaine indiqué dans la partie alternative names du fichier de configuration d'acme-client détaillé ci-dessous. Il sera donc plus pratique d'utiliser des instructions include dans la configuration d'httpd comme indiqué dans la partie des astuces pour httpd.

Avant d'utiliser acme-client, nous allons le configurer en ajoutant cette ligne à la fin du fichier /etc/acme-client.conf :

include "/etc/acme-client-custom.conf"

Ainsi, nous pourrons configurer acme-client dans un autre fichier /etc/acme-client-custom.conf sans risquer de voir nos modifications écrasées par des mises à jour.

Dans ce dernier fichier, nous allons donc mettre ces lignes :

domain chezmoi.tld {
    alternative names { webmail.chezmoi.tld www.chezmoi.tld }
    domain /etc/ssl/private/chezmoi.tld.key
    domain certificate "/etc/ssl/chezmoi.tld.crt"
    domain chain certificate "/etc/ssl/chezmoi.tld-chain.crt"
    domain full chain certificate "/etc/ssl/chezmoi.tld-fullchain.pem"
    sign with letsencrypt
}

Remplacez les éléments suivants :

  • chezmoi.tld par votre nom de domaine.
  • alternative names { … par les noms de domaines et sous-domaines à certifier.
  • Adaptez l'emplacement de la clé et du certificat obtenus dans domain key, domain certificate, domain chain certificate et domain full chain certificate. Ce sont ces fichiers que vous préciserez lorsque vous voudrez utiliser ces certificats.
  • Changez éventuellement le répertoire où se trouve votre site dans challengedir.

Facultatif : Vous pouvez ajouter à votre zone DNS des enregistrements de type CAA. Ce n'est pas obligatoire, mais ça permet de démontrer que vous, le propriétaire de ce domaine, avez autorisé letsencrypt à vous donner un certificat. Ça démontre que le certificat n'est pas là de façon fortuite. Cette étape est une précaution supplémentaire. Dans votre zone, il y aura donc :

@ 300 IN   CAA   0 issue "letsencrypt.org"

Vous pourrez ensuite générer vos certificats avec cette commande :

# acme-client -vAD chezmoi.tld

Pour mettre à jour les certificats, il suffira d'entrer :

# acme-client chezmoi.tld

Je vous invite à ajouter cette ligne dans le fichier /etc/weekly.local pour un renouvellement régulier :

/usr/sbin/acme-client -v chezmoi.tld && /usr/sbin/rcctl reload httpd

Maintenant, nous allons utiliser notre certificat en activant l'accès https dans la configuration de httpd :

# extrait de /etc/httpd.conf
server "chezmoi.tld" {
    listen on * tls port 443
    root "/htdocs/monsupersite"

    tls {
        certificate "/etc/ssl/chezmoi.tld-fullchain.pem"
        key "/etc/ssl/private/chezmoi.tld.key"
    }
    hsts

    # n'oubliez pas d'ajouter la configuration
    # specifique liee à votre site
    location "/.well-known/acme-challenge/*" {
        root "/acme"
        request strip 2
	}

Vous remarquerez que la connexion se fait désormais sur le port 443 (https), qu'il faut ouvrir dans le parefeu et rediriger dans le routeur.

L'option hsts rend l'échange des clés et donc la qualité du chiffrement plus sûrs. Pour un mot en plus, ça ne fait pas de mal.

Afin de diriger les visiteurs qui arriveraient avec l'adresse http://chezmoi.tld vers la version "https" de votre site, on ajoute le bloc suivant :

# extrait de /etc/httpd.conf
server "chezmoi.tld" {
    listen on * port 80
    block return 301 "https://$SERVER_NAME$REQUEST_URI"
}

4.3. PHP

4.3.1. Configuration minimale

Il est fort possible que vous souhaitiez ajouter le support de PHP à votre site, surtout si vous voulez héberger un moteur de blog ou un CMS. Il s'agit d'un langage de programmation offrant davantage de possibilités que de simples pages HTML.

La commande suivante permet d'installer PHP (à remplacer par la version souhaitée):

# pkg_add php-7.2.10

Pour lister toutes les versions de PHP disponibles, tapez :

# pkg_info -Q php

Après installation du paquet, on active PHP et on le démarre :

# rcctl enable php72_fpm
# rcctl start php72_fpm

Nous pouvons maintenant modifier la configuration de httpd pour lui dire de servir les pages au travers de PHP. Quelques lignes sont à ajouter au fichier /etc/httpd.conf :

server "chezmoi.tld" {
        listen on * port 80
        root "/htdocs/monsupersite"
        directory index index.php

        location "*.php*" {
                fastcgi socket "/run/php-fpm.sock"
        }
}

Remarquez l'instruction directory index index.php. Elle permet de rendre l'adresse http://chezmoi.tld/ équivalente à l'adresse http://chezmoi.tld/index.php.

Et voilà, les fichiers ".php" seront correctement interprétés. Cette configuration est suffisante dans la plupart des cas.

4.3.2. Installation plus complète de PHP

Je vous propose dans cette partie d'aller un peu plus loin pour préparer l'installation d'applications plus complètes (blog, CMS…) en activant des extensions et des options qui ne le sont pas par défaut, toujours dans un souci de sécurité.

4.3.2.1. Ajouter des bibliothèques PHP

Vous avez peut-être remarqué lors de l'installation de PHP une note concernant le dossier /usr/local/share/doc/pkg-readmes. Ce dernier contient des informations très intéressantes que nous allons appliquer ici.

Les extensions installées sont dans le dossier /etc/php-7.2.sample. Afin de les activer, il faut les relier dans le dossier /etc/php-7.2. On peut le faire en deux commandes :

# cd /etc/php-7.2.sample
# for i in *; do ln -sf ../php-7.2.sample/$i ../php-7.2/; done
# rcctl restart php72_fpm

Ainsi, toutes les extensions disponibles pour PHP sont activées. Pensez-y si vous en installez de nouvelles plus tard.

La plupart des extensions sont déjà présentes, mais vous voudrez peut-être y ajouter les paquets suivants (en adaptant le numéro de version):

  • php-curl-7.2.10,
  • php-gd-7.2.10,
  • php-intl-7.2.10,
  • php-zip-7.2.10.
  • libmcrypt qui donne accès à des fonctionnalités de cryptographie (remplace mcrypt).
  • pear, (ainsi que des paquets "pecl-…" qui sont des extensions pratiques)

4.3.2.2. Modifier la configuration de PHP

On peut souhaiter modifier la configuration de PHP. Il faut pour cela éditer le fichier /etc/php-7.2.ini. Je vous conseille notamment de modifier ces quelques lignes :

; Augmente la taille des fichiers que vous pouvez envoyer sur le site
post_max_size = 10M
upload_max_filesize = 10M
; une application php peut chercher du contenu distant (images..)
allow_url_fopen = On
; Le fuseau horaire
date.timezone = Europe/Paris
; configuration du cache
opcache.enable=1
opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=4000
opcache.enable_file_override=1

4.3.2.3. Configuration relative au chroot

Il est possible que votre site doive récupérer des informations ou données venant d'autres sites. Il a donc besoin de résoudre des noms de domaines, vérifier des certificats, connaître l'heure du système. Ces éléments sont situés dans le dossier /etc. Malheureusement, si vous vous souvenez bien, le serveur http est dans un chroot. Où se trouve ce chroot déjà?

Dans /var/www !!!

Très bien Jean-Eudes! Il y en a au moins un qui suit.

On va donc être obligé de mettre quelques fichiers qui normalement se trouvent dans /etc à l'intérieur du chroot. Ce n'est pas obligatoire, mais parfois nécessaire surtout si vous utilisez des applications PHP.

Voici la procédure :

# cd /var/www     # On va dans le chroot
# mkdir etc/      # On fabrique un dossier etc
# cp /etc/resolv.conf etc/resolv.conf            
# cp /etc/hosts etc/hosts              
# cp /etc/localtime etc/localtime                
# mkdir etc/ssl   # On cree un autre dossier
# install -m 444 -o root -g bin /etc/ssl/cert.pem /etc/ssl/openssl.cnf /var/www/etc/ssl

Ces fichiers ne doivent qu'être lisibles et accessibles :

chmod -R 444 /var/www/etc/*
chmod -R a+X /var/www/etc/

Les fichiers copiés servent notamment à :

  • /etc/resolv.conf et /etc/hosts : Permettent à PHP de traduire un nom de domaine en adresse
  • /etc/localtime : Permet d'être à la bonne heure
  • /etc/ssl/* : Fichiers permettant de vérifier les certificats SSL. Ce dernier doit être régulièrement mis à jour. Ajoutez donc cette ligne dans le fichier /etc/monthly.local :

    install -m 444 -o root -g bin /etc/ssl/cert.pem /etc/ssl/openssl.cnf /var/www/etc/ssl
    

Certaines applications ont besoin d'être capable d'envoyer des mails (forums, wikis…). Puisque PHP est dans un chroot, il ne pourra pas communiquer avec le programme responsable de l'envoi des mails : sendmail. Heureusement, lorsque vous avez installé PHP, l'outil femail-chroot a été lui aussi installé grâce au jeu des dépendances. Pour que PHP puisse l'utiliser, il faut copier "sh" dans le chroot (voir le fichier /usr/local/share/doc/pkg-readmes/femail-chroot*).

# cp /bin/sh /var/www/bin/

Une fois toutes vos modifications réalisées, n'oubliez pas de relancer PHP avec rcctl restart php72_fpm.

4.4. Astuces pour httpd

Je ne peux m'empêcher de vous inciter à lire le man httpd.conf. On y trouve tout ce qui est écrit ici, et plus encore.

  • Vous pouvez choisir un fichier spécifique où seront enregistrés les logs dans la section de chaque site. Cela peut être pratique avec webalizer par exemple. Ils sont par défaut enregistrés dans le dossier /var/www/logs.

    log access "nom_du_site.log"
    
  • Pour désactiver les logs, écrivez no log.
  • Pour protéger l'accès à un site ou une partie du site par un mot de passe, utilisez la commande htpasswd pour créer un fichier d'accès :

    # htpasswd /var/www/secret.htpw login
    
    Remplacez login par le nom d'utilisateur que vous souhaiterez utiliser, puis définissez un mot de passe solide. Recommencez autant de fois que vous voulez ajouter un nouvel utilisateur.

    Modifiez les permissions sur ce fichier :

    # chown www /var/www/secret.htpw
    # chmod 400 /var/www/secret.htpw
    
    Enfin, dans la configuration de httpd, pour protéger l'accès au sous-dossier /dossier_protege/* :

    location "/dossier_protege/*" {
        authenticate "Acces restreint" with "/secret.htpw"
    }
    
    Remarquez que l'emplacement du fichier secret.htpw est relatif au chroot de httpd, on fait comme si /var/www était /.

    Pour protéger un site complet, indiquez :

    location "/*"
    

    Ou alors, mettez l'instruction "authenticate" au tout début de la configuration sans jamais préciser de "location".

  • Afin de lister automatiquement dans le navigateur les fichiers présents dans un dossier, ajoutez dans le fichier /etc/httpd.conf :
    location "/dossier/*" {
    	directory auto index
    }
    

  • Si vous avez plusieurs sites, ça peut vite être le bazar de tout configurer dans le fichier /etc/httpd.conf. Il vous est possible de découper la configuration dans plusieurs fichiers avec l'instruction include :
        include "/etc/httpd/site1.conf"
        include "/etc/httpd/site2.conf"
    

    Pour accélérer les futures négociations TLS si vous servez votre site en https, vous pouvez ajouter ces quelques options :

    hsts preload
    tls {
    	certificate "/etc/ssl/chezmoi.tld-fullchain.pem"
    	key "/etc/ssl/private/chezmoi.tld.key"
    	ticket lifetime default
    }
    

4.5. Quelles permissions donner à mon site?

Attribuer les permissions adéquates aux fichiers constituant vos sites web est très important d'un point de vue sécurité. Il n'y a cependant pas de règles générales, car cela dépend des besoins de l'application hébergée et des vôtres. Voici cependant quelques exemples :

  • Les fichiers du site devraient appartenir au serveur http :
    # chown -R www:daemon /var/www/htdocs/mon_site
    
  • Dans le cas d'un site statique (sans PHP), il est inutile de laisser les droits d'exécution (-x). De même, s'il est statique, il n'y aura pas besoin d'écrire dedans (-w). On ajoute quand même le droit de se déplacer dans les répertoires (+X).
    # chmod -R a-xw /var/www/htdocs/mon_site 
    # chmod -R ug+X /var/www/htdocs/mon_site
    
    On commence par retirer les droits non-souhaités à tout le monde avant d'en donner au propriétaire et au groupe.

  • Pour un site dynamique, le serveur aura peut-être besoin d'écrire dans les dossiers et d'en exécuter une partie.
    # chmod -R a-xw /var/www/htdocs/mon_site
    # chmod -R u+xwX /var/www/htdocs/mon_site
    # chmod -R g+rX /var/www/htdocs/mon_site
    

    Là aussi, on commence par retirer tous les droits avant d'en donner au cas par cas.

ATTENTION : il sera certainement judicieux de modifier les permissions plus finement. Dans tous les cas, la meilleure pratique est de se poser la question concernant les droits.

À titre informatif, la plupart des hébergeurs appliquent uniquement les permissions suivantes :

  • Pour les répertoires : lecture et écriture pour le propriétaire et seulement lecture pour les autres. (755)
  • Pour un fichier, seul le propriétaire a le droit d'écrire dedans, les autres peuvent seulement le lire. (644)

Tout ceci peut se faire en quelques lignes :

### retrait des droits : 
# chmod -R a-rwx /var/www/htdocs/site     
### tout le monde peut lire les dossiers : 
# chmod -R a+rX /var/www/htdocs   
### seul le proprietaire peut ecrire : 
# chmod -R u+w /var/www/htdocs   

On retire d'abord l'ensemble des permissions. Ensuite, on donne accès en lecture aux dossiers et fichiers. Attention, à cette étape, il s'agit d'un X majuscule. Enfin, on accorde au propriétaire les droits d'écriture dans les dossiers et fichiers.

4.6. Gestion des entêtes avec relayd

Une gestion fine des entêtes peut vous intéresser. Cela peut notamment servir pour indiquer aux navigateurs de garder en cache plus longtemps les fichiers téléchargés et alléger la charge du serveur, ou encore régler des questions de sécurité.

Httpd n'est pas capable de gérer les entêtes (ou headers). Heureusement, tout est prévu : nous allons utiliser relayd et le placer avant httpd.

Inutile d'installer quoi que ce soit, relayd est déjà présent dans OpenBSD. Elle est pas belle la vie ?

La configuration de relayd est écrite dans le fichier /etc/relayd.conf que nous allons éditer.

À l'intérieur, et à titre d'exemple, nous allons mettre les lignes suivantes :

http protocol "http" {
  tcp { nodelay, sack, socket buffer 65536, backlog 100 }
  match request header remove "Proxy"
  match response header set "X-Xss-Protection" value "1; mode=block"

  return error
  pass
}

relay "www" {
  listen on 127.0.0.1 port 8080
  protocol "http"
  forward to destination
}

Voici ce que ces lignes signifient :

  • http protocol "http" { : On ouvre la configuration pour tout ce qui concerne le protocole http, qu'on appelle justement "http".
  • tcp { nodelay, …} : On ajoute quelques options pour sécuriser la connexion.
  • match request header remove "Proxy" : On retire un entête qui peut poser des soucis de sécurité. Cela se produit à l'arrivée de la requête et permet de ne pas envoyer de mauvais entêtes au serveur httpd.
  • match response header set "X-Xss-Protection" value "1;… " : On protège le site d'attaques XSS.
  • return error : On renvoie une erreur s'il y a eu le moindre souci.
  • pass : S'il n'y a pas eu de problèmes, on laisse passer.
  • relay "www" { : On va définir ici la redirection vers le serveur http.
  • listen on 127.0.0.1 on 8080 : On écoute sur le port 8080 uniquement en local.
  • protocol "http" : On utilise la configuration énoncée plus haut.
  • forward to destination : On renvoie vers le serveur qui doit initialement recevoir cette requête, c'est à dire httpd.

Justement, afin que relayd intercepte ce qu'httpd devait initialement recevoir directement, nous devons modifier un petit peu les règles du parefeu. Vous devrez éditer le fichier /etc/pf.conf pour compléter ainsi les règles concernant le serveur web :

anchor "relayd/*"
pass in on egress proto tcp to port www divert-to 127.0.0.1 port 8080 modulate state
pass in on egress proto tcp to port https divert-to 127.0.0.1 port 8443 modulate state

Si on résume, les choses se passent désormais ainsi :

  1. Un visiteur demande à voir votre site web, il se présente sur le port 80 ou 443.
  2. pf le renvoie à relayd qui se permet au passage de modifier quelques entêtes.
  3. relayd redirige le tout à httpd qui diffuse la page web demandée comme il le faisait d'habitude.

Après avoir réalisé vos modifications, n'oubliez pas d'activer relayd et de redémarrer les services, ainsi que recharger le parefeu :

# pfctl -f /etc/pf.conf
# rcctl enable relayd
# rcctl restart httpd
# rcctl start relayd

Vous pouvez consulter un exemple de configuration à la fin du document.

Notez cependant que ces modifications sont valables sur l'ensemble de vos sites, vous ne pouvez pas gérer les entêtes au cas par cas.

Pour aller plus loin sur relayd, vous pouvez lire la page du wiki OBSD4* correspondante

4.6.1. Le cas https

Si votre site propose une connexion chiffrée avec une adresse https://…, (c'est bien ! ), la configuration de relayd peut-être déroutante.

Ci-dessous, voici un exemple de configuration de relayd correspondante. Notez les mentions de tls :

http protocol "https" {
  tcp { nodelay, sack, socket buffer 65536, backlog 100 }
  match request header remove "Proxy"
  match response header set "X-Xss-Protection" value "1; mode=block"

  return error
  pass
  tls { \
    no tlsv1.0\
    ciphers "HIGH"\
  }
}

relay "tlsforward" {
  listen on 127.0.0.1 port 8443 tls
  protocol "https"
  forward with tls to destination
}

Toutefois, il faut que relayd puisse vérifier les certificats. Afin qu'il y accède, il faut les placer dans /etc/ssl/private/adresse.key pour la clé et dans /etc/ssl/adresse.crt pour le certificat. Ici, l'adresse sur laquelle écoute relayd est "127.0.0.1". Dans le cas où vous auriez récupéré un certificat avec acme-client, vous pouvez alors faire des liens symboliques ainsi :

# ln -s /etc/ssl/private/chezmoi.tld.key /etc/ssl/private/127.0.0.1.key
# ln -s /etc/ssl/chezmoi.tld-fullchain.pem /etc/ssl/127.0.0.1.crt

Inutile de préciser quoi que ce soit en plus dans la configuration de relayd ou httpd, tout fonctionne normalement comme prévu avec l'utilisation de vos certificats 😉

4.6.2. Httpoxy

Si votre site n'est accessible qu'en http (pas de chiffrement), alors je vous conseille vivement de vous prémunir contre une faille connue sous le doux nom de httpoxy. Cela peut permettre (en gros hein…) à un pirate de paraître venir de votre serveur lorsqu'il réalise une attaque.

Ou alors je mets tout en https, c'est plus simple non ?

Oui ça serait plus simple et mieux pour la sécurité de vos visiteurs.

Voici à quoi ressemblera le fichier relayd.conf minimal pour s'en protéger :

http protocol "http" {
    tcp { nodelay, sack, socket buffer 65536, backlog 100 }
    match request header remove "Proxy"
    return error
    pass
}

relay "www" {
    listen on 127.0.0.1 port 8080
    protocol "http"
    forward to destination
}

4.6.3. Autres entêtes de sécurité

En plus du précédent, comme proposé dans l'exemple à la fin, vous pouvez ajouter d'autres règles pour améliorer la sécurité de votre serveur en modifiant ces entêtes :

match request header remove "Proxy"
match response header set "X-Xss-Protection" value "1; mode=block"
match response header set "Frame-Options" value "SAMEORIGIN"
match response header set "X-Frame-Options" value "SAMEORIGIN"
match response header set "X-Robots-Tag" value "index,nofollow"
match response header set "X-Permitted-Cross-Domain-Policies" value "none"
match response header set "X-Download-Options" value "noopen"
match response header set "X-Content-Type-Options" value "nosniff"

Si vous n'hébergez qu'un seul nom de domaine, vous devriez ajouter ceci :

match response header set "Access-Control-Allow-Origin" value "$NDD"

Plus d'informations :

4.6.4. Optimisation du cache et de la bande passante

Que vous ayez une bande passante performante ou non, je vous conseille vivement d'optimiser le nombre de requêtes qu'un visiteur réalisera lorsqu'il visitera votre site. Pour cela, vous pouvez indiquer à son navigateur de garder les ressources (images, feuilles de style…) en cache pendant un temps assez long (21 jours dans l'exemple : 21 jours = 1814400 secondes).

Voici les éléments à ajouter dans la section "protocol" juste avant le mot clé "pass" :

match request path "/*.css" tag "CACHE"
match request path "/*.js" tag "CACHE"
match request path "/*.atom" tag "CACHE"
match request path "/*.rss" tag "CACHE"
match request path "/*.xml" tag "CACHE"
match request path "/*.jpg" tag "CACHE"
match request path "/*.png" tag "CACHE"
match request path "/*.svg" tag "CACHE"
match request path "/*.gif" tag "CACHE"
match request path "/*.ico" tag "CACHE"

match response tagged "CACHE" header set "Cache-Control" value "max-age=1814400"

L'idée est très simple, à chaque fois qu'un visiteur demande un fichier se terminant par l'une des extensions ".css, .js, .atom, … , .ico", on colle sur la requête une étiquette "CACHE". À la fin, lorsque relayd détecte une requête avec cette étiquette, il ajoute un entête "Cache-Control" avec une valeur assez grande pour que le navigateur ne tente pas de télécharger à nouveau ce fichier de sitôt.

D'autres astuces concernant les entêtes sont indiquées à la fin du document, que je vous invite à lire.

4.7. Les bases de données

Une base de données permet à une application de retrouver rapidement des informations reliées entre elles.

Prenons le cas d'un blog par exemple. Les commentaires peuvent être stockés dans une base de données. Chaque commentaire est écrit pour un certain article, par un visiteur donné, à une date précise. Le commentaire comme l'article ont un lien bien précis. L'utilisateur peut avoir donné son adresse e-mail pour être averti de nouveaux messages…

Vous l'aurez compris, toutes ces données s'entrecroisent, et il est plus efficace d'utiliser une base de données pour les retrouver rapidement.

Cependant, ce n'est pas forcément obligatoire. Surtout sur un serveur auto-hébergé, où vous n'aurez sans doute pas des milliers d'utilisateurs.

Comprenez donc bien que si vous pouvez choisir des applications qui n'ont pas besoin de base de données, c'est un avantage pour vous car c'est un élément en moins à administrer et sécuriser. Eh oui, car une base de données peut elle aussi subir des attaques.

Une alternative est d'utiliser dans ce cas SQLite, puisque ce moteur de base de données ne nécessite pas d'administration particulière, c'est l'application qui s'en charge. Tous les avantages d'une base de données avec ceux des fichiers simples en somme.

4.7.1. SQlite

SQlite est un moteur de base de données tout simplement génial.

Vous n'avez rien de particulier à faire pour l'administrer, c'est l'application qui en a besoin qui se chargera de créer la base. En plus, c'est très facile à sauvegarder puisqu'il s'agit dans ce cas d'un simple fichier à copier. Enfin, ce moteur sait se montrer léger et fonctionne bien même sur du matériel peu puissant.

Alors certains diront que ce n'est pas le moteur le plus performant. C'est vrai. Il reste plus efficace que pas de base de données du tout. À moins d'avoir des milliers de visiteurs sur votre site, vous ne verrez pas la différence avec un autre moteur de base de données. N'hésitez pas, il y a plus d'avantages que d'inconvénients à utiliser SQLite en auto-hébergement.

Pour l'installer, c'est tout bête : pkg_add sqlite3.

Afin de l'utiliser avec PHP, installez php-pdo_sqlite-7.2.10 et php-sqlite3-7.2.10.

4.7.2. MariaDB (MySQL)

MySQL est un autre moteur de base de données, sans doute le plus répandu. Puisqu'Oracle possède désormais MySQL et en distribue une version propriétaire, un fork a été créé qui s'appelle MariaDB. Ce dernier est entièrement libre et est empaqueté pour OpenBSD.

Veillez à vous renseigner sur la sécurisation de ce service pour compléter les informations suivantes.

Vous voudrez certainement utiliser MariaDB avec PHP. Installez dans ce cas les paquet php-mysqli-7.2.10 et php-pdo_mysql-7.2.10: et activez l'extension mysqli comme indiqué dans la partie sur PHP.

Afin d'installer MariaDB, il faut lancer les commandes suivantes :

# pkg_add mariadb-server
# /usr/local/bin/mysql_install_db

La deuxième commande prépare la base de données par défaut et les fichiers dont MariaDB aura besoin.

On ajoute ensuite les lignes suivantes au fichier /etc/login.conf afin de laisser l'utilisateur _mysqld travailler :

  mysqld:\
                :openfiles-cur=1024:\
                :openfiles-max=2048:\
                :tc=daemon:

On peut maintenant lancer la commande suivante pour prendre les changements en compte :

# [ -f /etc/login.conf.db ] && cap_mkdb /etc/login.conf

On démarre mysql :

# rcctl enable mysqld
# rcctl start mysqld

Très importante, la commande suivante permet de sécuriser un minimum l'installation de mysql :

# /usr/local/bin/mysql_secure_installation

Donner un mot de passe fort pour l'utilisateur root, et suivez les recommandations. Cela ressemblera à ça :

Setting the root password ensures that nobody can log into the MySQL
root user without the proper authorisation.

You already have a root password set, so you can safely answer 'n'.

Change the root password? [Y/n] n
 … skipping.

By default, a MySQL installation has an anonymous user, allowing anyone
to log into MySQL without having to have a user account created for
them.  This is intended only for testing, and to make the installation
go a bit smoother.  You should remove them before moving into a
production environment.

Remove anonymous users? [Y/n] Y
 … Success!

Normally, root should only be allowed to connect from 'localhost'.  This
ensures that someone cannot guess at the root password from the network.

Disallow root login remotely? [Y/n] Y
 … Success!

By default, MySQL comes with a database named 'test' that anyone can
access.  This is also intended only for testing, and should be removed
before moving into a production environment.

Remove test database and access to it? [Y/n] Y
 - Dropping test database…
ERROR 1008 (HY000) at line 1: Can't drop database 'test'; database dœsn't exist
 … Failed!  Not critical, keep moving…
 - Removing privileges on test database…
 … Success!

Reloading the privilege tables will ensure that all changes made so far
will take effect immediately.

Reload privilege tables now? [Y/n] Y
 … Success!

Cleaning up…

All done!  If you've completed all of the above steps, your MySQL
installation should now be secure.

Thanks for using MySQL!

MariaDB devra être accessible par le serveur web. Ce dernier étant dans un chroot, on lance la commande suivante qui nous permet de reproduire la structure de la racine tout en attribuant les droits nécessaires pour l'utilisateur _mysql :

# install -d -m 0711 -o _mysql -g _mysql /var/www/var/run/mysql

Il faut en plus mettre ces lignes dans le fichier /etc/my.cnf, afin de modifier les chemins pour le serveur httpd :

[client]
    socket = /var/www/var/run/mysql/mysql.sock

[mysqld]
    socket = /var/www/var/run/mysql/mysql.sock

Enfin, on relance mysql :

# rcctl restart mysqld

À partir de ce moment, vous pouvez créer et utiliser des bases de données avec MariaDB.

4.7.2.1. Créer une base de données

À titre d'exemple, on va créer une nouvelle base de données pour Wordpress. Adaptez-le à votre cas.

Entrez la commande mysql -u root -p afin "d'entrer" dans MariaDB (MySQL). Les commandes à exécuter sont indiquées ci-dessous avec la réponse attendue :

# mysql -u root -p
Enter password:
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 3
Server version: 10.0.23-MariaDB-log openBSD port: mariadb-server-10.0.23p0v1

Copyright (c) 2000, 2015, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> CREATE DATABASE wordpress_base;
Query OK, 1 row affected (0.01 sec)

MariaDB [(none)]> CREATE USER 'wp'@'localhost' IDENTIFIED BY 'motdepasse';
Query OK, 0 rows affected (0.01 sec)

MariaDB [(none)]> GRANT ALL PRIVILEGES ON wordpress_base.* TO 'wp'@'localhost';
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> exit
Bye

Et voilà, vous pouvez utiliser cette base dans votre application.

Quelques explications tout de même :

  • CREATE DATABASE wordpress_base; : On crée la base de données pour Wordpress, appelée wordpress_base,
  • CREATE USER 'wp'@'localhost' IDENTIFIED BY 'motdepasse'; : On crée un utilisateur wp avec son mot de passe,
  • La ligne suivante accorde à l'utilisateur wp les droits suffisants sur la base créée juste avant.

    GRANT ALL PRIVILEGES ON wordpress_base.* TO 'wp'@'localhost';
    

4.7.3. PostgreSQL

PostgreSQL est un autre moteur de base de données, entièrement libre.

Pour l'installer, il faut le paquet postgresql-server.

Afin de l'utiliser avec PHP, installez php-pgsql-7.2.10 et php-pdo_pgsql-7.2.10. Veillez à bien lire le contenu du fichier

/usr/local/share/doc/pkg-readmes/postgresql*

Ensuite, créez une base par défaut :

# su - _postgresql
$ mkdir /var/postgresql/data
$ initdb -D /var/postgresql/data -U postgres -A scram-sha-256 -E UTF8 -W
$ exit

L'utilisateur par défaut s'appelle donc postgres.

Des options supplémentaires seront à adapter à votre cas dans le fichier :

/var/postgresql/data/postgresql.conf

Par exemple, pour que le serveur httpd qui est enfermé dans un chroot puisse accéder à la base :

unix_socket_directories = '/var/www/tmp/postgresql, /tmp'

Les permissions sur ce dossier doivent d'ailleurs être modifiées ainsi pour que postgresql puisse écrire dedans :

# mkdir -p /var/www/tmp/postgresql
# chown _postgresql:www /var/www/tmp/postgresql

Démarrez le serveur postgresql avec :

# rcctl enable postgresql
# rcctl start postgresql

Pour se connecter à postgresql, on utilise la commande :

# su _postgresql -c psql

Voici quelques commandes permettant de gérer PostgreSQL.

  • Modifier le mot de passe administrateur

    # psql -U postgres -c "ALTER USER postgres WITH PASSWORD 'mot_de_passe'";
    
  • Ajouter un utilisateur nommé "toto" à la base :

    # psql -U postgres -c "CREATE USER toto WITH PASSWORD 'mot_de_passe';"
    
  • Créer une nouvelle base et donner à toto tous les droits dessus :

    # psql -U postgres 
    \connect template1
    CREATE DATABASE "nouvelle_base" WITH ENCODING 'UTF-8';
    GRANT ALL PRIVILEGES ON DATABASE "nouvelle_base" TO toto;
    ALTER DATABASE "nouvelle_base" OWNER TO toto;
    \q
    

4.7.4. Sauvegarder / Restaurer une base de données

Ici, nous verrons comment sauvegarder et restaurer vos bases de données. Si vous n'en utilisez pas, alors passez votre chemin.

4.7.4.1. Avec SQLite

Il vous suffit de copier le fichier sqlite présent dans le dossier de votre site web. Oui, c'est tout ! 😁

Pour la copie, c'est comme vous voulez. Utilisez cp ou openrsync, pas besoin de vous compliquer pas la vie.

4.7.4.2. Avec MariaDB

Pour MariaDB ou MySQL, la sauvegarde s'appelle un "dump" et se réalise via la commande suivante :

# mysqldump -u root -p nom-de-la-base > /var/sauvegarde/base-sauvee

Bien entendu, vous aurez adapté cette commande en changeant root pour le nom d'utilisateur qui a accès à cette base ainsi que le nom de la base. Normalement, root a accès à toutes les bases.

Le mot de passe à entrer est celui de l'utilisateur.

Pour restaurer la base de données plus tard, cela se fait en trois étapes :

  1. On s'assure que l'ancienne base est supprimée :
    # mysql -u root -p -e "DROP DATABASE nom-de-la-base"
    

  2. On crée à nouveau cette base mais vide :
    # mysql -u utilisateur -e "CREATE DATABASE nom-de-la-nouvelle-base"
    

  3. Enfin, on importe le "dump" dans cette nouvelle base propre :
    # mysql -u utilisateur -p nom-de-la-nouvelle-base < /var/sauvegarde/base-sauvee
    

Vous aurez remarqué le sens du chevron "<" qui est en sens inverse lors de la restauration.

4.7.4.3. Avec PostgreSQL

La sauvegarde d'une base de données avec PostgreSQL est bien pensée. Vous allez enregistrer dans un fichier toutes les instructions permettant à PostgreSQL de créer une base identique si besoin.

La sauvegarde dans un fichier n'est pas très compliquée et se déroule ainsi :

# pg_dump nom-de-la-base > /var/sauvegarde

Et pour restaurer la base plus tard, procéder ainsi :

# psql -U postgres nom-de-la-base < /var/sauvegarde

Pour plus d'informations, je vous laisse lire la documentation officielle très bien écrite, mais en anglais.

4.8. Exemples de services WEB

Cette section propose des exemples de services que vous pouvez auto-héberger. Puisque les applications sont régulièrement mises à jour, il conviendra de ne pas reproduire tête baissée les procédures indiquées, et de vérifier que la démarche correspond à la version du service que vous souhaitez installer.

Après l'installation, il est vivement conseillé de suivre les publications et nouvelles concernant ces applications pour mettre à jour si de nouvelles versions sont disponibles.

Comme vous le constaterez, la méthode d'installation est sensiblement la même pour la plupart des applications :

  1. On crée un dossier pour le nouveau site dans /var/www/htdocs ;
  2. On télécharge l'application, souvent sous forme d'archive que l'on décompresse ;
  3. On déplace les fichiers de l'application dans le dossier prévu à cet effet ;
  4. On change les permissions sur les fichiers :
    # chown -R www:daemon /var/www/htdocs/lesite
    
  5. On ajoute une section dans /etc/httpd.conf ;
  6. On recharge httpd avec rcctl reload httpd ;
  7. On termine l'installation en allant sur le nouveau site.

Je suppose ici que vous avez déjà procédé à l'installation de httpd et de PHP.

4.8.1. Un cloud avec NextCloud

NextCloud est un service qui vous permet de synchroniser vos documents, contacts, rendez-vous sur n'importe quelle machine grâce à ses multiples clients. Bien qu'un paquet soit disponible et livré avec OpenBSD, on va présenter l'installation manuelle pour avoir la dernière version.

Vous pouvez aussi installer le paquet nextcloud puis lire les précisions données dans /usr/local/share/doc/pkg-readme/nextcloud.

4.8.1.1. Installation de Nextcloud

On va commencer par créer un dossier pour Nextcloud :

# mkdir /var/www/htdocs/nextcloud

Ensuite, sans surprise, on le télécharge après s'être placé dans un dossier temporaire.

# cd /tmp
# ftp "https://download.nextcloud.com/server/releases/nextcloud-15.0.0.zip"

Il faut maintenant vérifier l'intégrité de l'archive. Pour cela, on va télécharger la somme sha256 :

# ftp "https://download.nextcloud.com/server/releases/nextcloud-15.0.0.zip.sha256"

Et on vérifie l'archive :

# sha256 -C nextcloud-*.sha256 nextcloud*.zip
(SHA256) nextcloud-15.0.0.zip: OK

On décompresse cette archive puis on modifie les droits pour que ces nouveaux fichiers appartiennent au serveur web :

# unzip nextcloud*.zip
# mv nextcloud /var/www/htdocs/
# chown -R www:daemon /var/www/htdocs/nextcloud

On peut désormais éditer le fichier /etc/httpd.conf afin d'ajouter une section pour nextcloud :

server "cloud.chezmoi.tld" {
        listen on * port 80
        block return 301 "https://$SERVER_NAME$REQUEST_URI"
}

server "cloud.chezmoi.tld" {
        listen on * tls port 443
        root "/htdocs/nextcloud" 
        directory index index.php
        hsts
        tls {
            certificate "/etc/ssl/chezmoi.tld-fullchain.pem"
            key "/etc/ssl/private/chezmoi.tld.key"
        }

        # Set max upload size to 500M (in bytes)
        connection max request body 524288000

        # First deny access to the specified files
        location "/README"                      { block }
        location "/data*"                       { block }
        location "/config*"                     { block }
        location "/build*"                      { block }
        location "/tests*"                      { block }
        location "/config*"                     { block }
        location "/lib*"                        { block }
        location "/3rdparty*"                   { block }
        location "/templates*"                  { block }
        location "/data*"                       { block }
        location "/.ht*"                        { block }
        location "/.user*"                      { block }
        location "/autotest*"                   { block }
        location "/occ*"                        { block }
        location "/issue*"                      { block }
        location "/indie*"                      { block }
        location "/db_*"                        { block }
        location "/console*"                    { block }


        location "/*.php*" {
                fastcgi socket "/run/php-fpm.sock"
        }

        location "/.well-known/acme-challenge/*" {
            root "/acme"
            request strip 2
        }
}

Avant de relancer les services, on installe les dépendances PHP dont Nextcloud aura besoin. Notez que selon ce que vous souhaitez faire avec Nextcloud, vous devrez peut-être installer davantage de modules, ceux ci-dessous sont le minimum retenu pour cet exemple.

# pkg_add php-bz2 php-curl php-gd php-pdo_sqlite php-intl php-zip\
    pecl72-redis redis libmcrypt oniguruma icu4c-wwwdata

N'oubliez pas d'activer ces extensions.

# cd /etc/php-7.2.sample
# for i in *; do ln -sf ../php-7.2.sample/$i ../php-7.2/; done
# rcctl restart php72_fpm

Enfin, on recharge httpd et PHP avec :

# rcctl reload httpd
# rcctl restart php72_fpm

Pour terminer l'installation, ouvrez un navigateur à l'adresse de votre cloud, par exemple https://cloud.chezmoi.tld/ dans l'exemple ci-dessus.

Ne reste plus qu'à suivre les étapes :

Si vous avez des erreurs à propos de l'UTF-8 qui apparaissent, lancez les commandes suivantes pour résoudre ce problème dû au chroot :

# mkdir -p /var/www/usr/share/locale/UTF-8/
# cp /usr/share/locale/UTF-8/LC_CTYPE /var/www/usr/share/locale/UTF-8/

Autre remarque, afin d'augmenter la limite en taille des fichiers que vous aurez à envoyer, vous devez modifier le fichier /etc/php-7.2.ini pour changer les valeurs dans les variables suivantes :

post_max_size = 500M
upload_max_filesize = 500M

Ces limites sont relativement élevées. N'hésitez pas à réduire ces valeurs selon vos besoins.

Il sera aussi certainement nécessaire d'installer les fichiers pour le chroot comme indiqué au paragraphe correspondant.

Ici, nous avons utilisé la base de données SQLite. Rien ne vous empêche d'utiliser MySQL (MariaDB) ou PostgreSQL si vous préférez. Référez-vous dans ce cas à la partie sur les bases de données.

4.8.1.2. Cache avec redis

Dans cet exemple, je vous propose l'utilisation de redis qui mettra en cache des éléments de votre cloud pour de meilleures performances. Il faut l'activer pour qu'il fonctionne :

# rcctl enable redis
# rcctl start redis

Éditez ensuite le fichier de configuration de nextcloud (/var/www/htdocs/nextcloud/config/config.php) pour y écrire :

'memcache.local' => '\OC\Memcache\Redis',
'redis' => array(
'host' => 'localhost',
'port' => 6379,
'timeout' => 0.0,
),

Cette partie est à rajouter avant le tout dernier ); en fin de fichier.

4.8.1.3. Note à propos de libsodium

Pour profiter de différentes fonctionnalités cryptographiques dans Nextcloud, vous pouvez installer libsodium.

# pkg_add libsodium pecl72-libsodium

Malheureusement, selon ce tuto, il y a une erreur d'écriture dans le fichier /etc/php-7.2.sample/libsodium.ini : il devrait être écrit dedans :

extension=sodium.so

Corrigez-le avant d'activer cet élément de PHP.

4.8.1.4. Sauvegarde de Nextcloud

Notez que si vous souhaitez sauvegarder votre instance de NextCloud, il suffit de copier les fichiers présents dans (d'après notre exemple) :

/htdocs/nextcloud

N'oubliez pas de sauvegarder la base de données. Toutefois, pensez à mettre NextCloud en mode "maintenance" le temps de la sauvegarde. Pour cela, éditez le fichier config/config.php pour mettre l'option maintenance à true :

<?php

 "maintenance" => true,

Bien sûr, vous remettrez sur false une fois la sauvegarde terminée.

En cas de doute, vous pouvez lire cette page qui détaille la sauvegarde de NextCloud, ou bien entendu vous référer à la documentation officielle.

4.8.1.5. Cron pour Nextcloud

Pour terminer, il faut prévoir une tâche cron pour nextcloud qui doit travailler en arrière-plan de façon régulière. Entrez alors crontab -e puis écrivez :

*/15  * * * * /usr/bin/ftp -Vo - https://chezmoi.tld/cron.php >/dev/null

4.8.1.6. Accès WebDAV

Si vous voulez utiliser un accès webdav, c'est bien expliqué dans le manuel d'utilisation de Nextcloud :

https://docs.nextcloud.com/server/stable/user_manual/files/access_webdav.html

4.8.2. Un Webmail

Le webmail vous servira à consulter votre messagerie à partir d'un navigateur web.

4.8.2.1. RainLoop

RainLoop est un excellent webmail qui est facile à installer et à mettre à jour. Il permet non seulement de consulter les messages présents sur votre serveur mais aussi ceux présents chez d'autres hébergeurs, un peu comme le fait Thunderbird. De plus, il intègre par défaut un support pour le chiffrement PGP, bien que partiel.

Pour que RainLoop fonctionne correctement, vous devrez installer l'extension php-curl et l'activer comme décrit plus haut.

Nous allons mettre RainLoop dans un dossier /var/www/htdocs/webmail que nous allons créer et dans lequel nous nous plaçons :

# mkdir -p /var/www/htdocs/webmail
# cd /var/www/htdocs/webmail

On télécharge l'archive puis on la décompresse :

# ftp "https://www.rainloop.net/repository/webmail/rainloop-community-latest.zip"
# unzip rainloop*.zip

Afin d'attribuer des permissions raisonnables aux fichiers de RainLoop, on exécute les commandes suivantes :

find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
chown -R www:daemon .

Il ne nous reste plus qu'à configurer httpd. Comme d'habitude, on rajoute dans le fichier /etc/httpd.conf une nouvelle section :

server "webmail.chezmoi.tld" {
        listen on * tls port 443
        root "/htdocs/webmail"
        directory index index.php
        # 35M maxi, la valeur par défaut de smtpd
        connection max request body 36700160
        hsts
        tls {
            certificate "/etc/ssl/chezmoi.tld-fullchain.pem"
            key "/etc/ssl/private/chezmoi.tld.key"
        }
        location "/data*"                { block }

        location "/*.php*" {
                fastcgi socket "/run/php-fpm.sock"
        }
}

On recharge httpd : rcctl reload httpd puis on ouvre dans un navigateur la page d'administration du webmail située à l'adresse suivante : https:/chezmoi.tld/?admin.

Par défaut, le login administrateur est admin et le mot de passe 12345. Changez-les tout de suite.

Pour la gestion des pièces jointes, qui est maximum de 35M par défaut avec le serveur mail smtpd, vous devriez changer les valeurs suivantes dans la configuration avancée de php.

post_max_size = 35M
upload_max_filesize = 35M
4.8.2.1.1. Configuration de RainLoop

RainLoop permet de consulter des messages provenant de serveurs différents. La configuration se déroule à l'adresse chezmoi.tld/?admin. Ainsi, si vous vous dirigez dans l'onglet "Domains", vous pouvez en voir plusieurs pré-configurés.

Nous ajoutons un nouveau domaine (le vôtre) en cliquant sur "+ Add Domain".

Une fenêtre s'ouvre. Complétez le champ "Name" avec le nom de domaine de votre serveur. Pour la configuration IMAP et SMTP, vous pourriez réaliser la même configuration que pour n'importe quel client. J'indique ici une configuration qui fonctionnera avec la mise en place d'un serveur mail telle que décrite dans le présent document.

Cliquez sur "Test" Afin de vérifier que tout fonctionne comme prévu.

Dirigez-vous maintenant vers la page principale (sans le ?admin) de votre webmail pour vous y connecter. Attention, il faut rentrer votre adresse mail complète comme login :

4.8.2.2. Roundcubemail

Nous allons ici installer le très connu roundcube. Cette application est complète, toutefois relativement complexe à installer. Vous voudrez peut-être installer le paquet roundcubemail déjà tout prêt, mais peut-être à une version plus ancienne, et lire le fichier /usr/local/share/doc/pkg-readmes/roundcubemail.

Installons tout d'abord quelques dépendances qu'il faudra activer:

# pkg_add sqlite3
# pkg_add php-pspell-7.2.10 php-zip-7.2.10 libmcrypt
# pkg_add php-intl-7.2.10 

On doit ensuite modifier la configuration de PHP. On édite le fichier /etc/php-7.2.ini pour y mettre à la fin :

[suhosin]
suhosin.session.encrypt = 0

Une fois cette modification effectuée, relancez PHP :

# rcctl enable php72_fpm
# rcctl restart php72_fpm

On va mettre roundcube dans le dossier /var/www/htdocs/roundcube.

On télécharge l'archive de roundcube qu'on décompresse :

# cd /var/www/htdocs/
# ftp -o roundcube.tgz https://github.com/roundcube/roundcubemail/releases/download/1.3.8/roundcubemail-1.3.8-complete.tar.gz
# tar xvzf roundcube.tgz

Maintenant, on renomme le nouveau dossier roundcubemail* puis on crée les dossiers nécessaires au bon fonctionnement de roundcube :

# mv roundcubemail-* roundcube
# mkdir -p roundcube/temp roundcube/logs

Nous allons créer la base sqlite pour roundcube. On fabrique un dossier qui contiendra la base de données :

# mkdir /var/www/htdocs/roundcube/db

La commande suivante crée la base :

# cd /var/www/htdocs/roundcube
# sqlite3 -init SQL/sqlite.initial.sql db/sqlite.db
-- Loading resources from roundcube/SQL/sqlite.initial.sql
SQLite version 3.24.0 2018-06-04 19:24:41
Enter ".help" for usage hints.

(Tapez .exit pour quitter sqlite3)

Enfin, on modifie les permissions de tous ces nouveaux fichiers :

# cd /var/www/htdocs/
# chown -R www:daemon roundcube
# chmod 0775 roundcube/db
# chmod 0660 roundcube/db/sqlite.db

On ajoute le nouveau site dans la configuration de httpd. Pour cela, on édite le fichier /etc/httpd.conf et on ajoute quelque chose comme :

server "webmail.chezmoi.tld" {
        listen on * port 80
        block return 301 "https://$SERVER_NAME$REQUEST_URI"
        no log
}

server "webmail.chezmoi.tld" { 
        listen on * tls port 443 
        root "/htdocs/roundcube" 
        directory index index.php
        no log

        hsts 
        tls {
            certificate "/etc/ssl/chezmoi.tld-fullchain.pem"
            key "/etc/ssl/private/chezmoi.tld.key"
        }
        location "*.php*" {
            fastcgi socket "/run/php-fpm.sock"
        }
        # Deny Protected directories
        location "/config*" { block }
        location "/temp*" { block }
        location "/logs*" { block }
        location "/README" { block }
        location "/INSTALL" { block }
        location "/LICENSE" { block }
        location "/CHANGELOG" { block }
        location "/UPGRADING" { block }
        location "/bin*" { block }
        location "/SQL*" { block }
        location "/db*" { block }
        location "*.md" { block }
        location "\.*" { block }
} 

Rechargez httpd et PHP puis allez à la page d'installation de votre nouveau webmail avec un navigateur : https://webmail.chezmoi.tld/installer.

Suivez les indications données. La plupart des choses n'ont pas besoin d'être modifiées. Vérifiez tout de même que :

  • Pour la base de données, vous choisissez SQLite.
  • Le nom de la base de données (Database name) doit être celui-ci (avec tous les /…):

    ////htdocs/roundcube/db/sqlite.db

  • Les autres champs pour la base de données doivent être vides.
  • Pour smtp_server, la valeur doit être localhost.

Dans le navigateur sera générée la configuration. Enregistrez-la dans le fichier

/var/www/roundcubemail/config/config.inc.php

Vérifiez bien qu'il contient au moins ceci (attention au nombre de /) :

$config['db_dsnw'] = 'sqlite:////htdocs/roundcube/db/sqlite.db?mode=0660';
$config['smtp_server'] = 'localhost';

Vous avez une dernière page de test, puis vous pouvez allez à l'URL de votre webmail pour voir que tout fonctionne.

Bien que tout semble être en état de marche, n'oublions pas la sécurité. Modifiez le fichier config.inc.php pour désactiver l'installateur.

$config['enable_installer'] = false;

Puis supprimez le dossier d'installation totalement :

# rm -r /var/www/htdocs/roundcube/installer

Ça y est, votre webmail est prêt!

À l'avenir, pour mettre roundcube à jour, lisez le fichier UPGRADING et la section Update manually.

4.8.3. Héberger son blog

4.8.3.1. Blogotext

Blogotext est un moteur de blog léger et pourtant puissant et esthétique. Il pourra vous permettre en outre d'envoyer et partager des fichiers, faire office d'agrégateur de flux RSS, marque page de liens, prise de notes… C'est un outil génial et complet !

Son installation est très simple et ne nécessite que peu de dépendances, à savoir le paquet sqlite3. Vous y ajouterez php-curl* et php-intl* s'ils ne sont pas déjà installés.

Pour télécharger blogotext, on peut utiliser ftp :

# ftp -o /tmp/blogotext.tag.gz "https://api.github.com/repos/BlogoText/blogotext/tarball/3.7.6"

On décompresse l'archive à partir du dossier /var/www/htdocs :

# cd /var/www/htdocs
# tar xvzf /tmp/blogotext.tar.gz

Un dossier blogotext-3.7.6 est créé. On le renomme en blogotext pour plus de simplicité :

# mv Blogotext-blogotext* blogotext

Maintenant, on modifie les permissions pour que ces nouveaux fichiers appartiennent au serveur web :

# chown -R www:daemon /var/www/htdocs/blogotext

On peut alors éditer le fichier /etc/httpd.conf afin d'ajouter une section pour blogotext :

server "blog.chezmoi.tld" {
    listen on * port 80
    block return 301 "https://$SERVER_NAME$REQUEST_URI"
}

server "blog.chezmoi.tld" {
    listen on * tls port 443
    root "/htdocs/blogotext" 
    directory index index.php

# taille maximale que l'on peut envoyer en bytes
    connection max request body 136700160
    hsts
    tls {
        certificate "/etc/ssl/chezmoi.tld-fullchain.pem"
        key "/etc/ssl/private/chezmoi.tld.key"
    }

    location "/*.php*" {
        fastcgi socket "/run/php-fpm.sock"
    }
}

Pour prendre en compte ces changements, on recharge httpd avec

# rcctl reload httpd

Vous pouvez maintenant terminer l'installation dans un navigateur à l'adresse de votre blog https://blog.chezmoi.tld/.

Pour poster de nouveaux articles et administrer votre blog, rendez-vous à l'adresse https://blog.chezmoi.tld/admin/auth.php. Notez que par sécurité, vous pouvez renommer le dossier admin sur votre serveur.

4.8.3.2. Dotclear

Dotclear est un autre moteur de blog. Vous pouvez utiliser n'importe quelle base de données avec ce dernier, mais SQLite reste un choix prudent et simple en auto-hébergement.

Pour installer dotclear, nous allons commencer par préparer la configuration du serveur web (http). À nouveau, nous supposons que vous avez déjà installé PHP.

Dans le fichier /etc/httpd.conf, ajoutez un nouveau site :

server "blog.chezmoi.tld" {
        listen on * port 80
        block return 301 "https://$SERVER_NAME$REQUEST_URI"
}

server "blog.chezmoi.tld" {
        listen on * tls port 443
        root "/htdocs/dotclear" 
        directory index index.php

        # taille maximale que l'on peut envoyer en bytes
        connection max request body 136700160
        hsts
        tls {
            certificate "/etc/ssl/chezmoi.tld-fullchain.pem"
            key "/etc/ssl/private/chezmoi.tld.key"
        }

        location "/*.php*" {
                fastcgi socket "/run/php-fpm.sock"
        }
}

Ensuite, on crée le dossier qui va accueillir dotclear.

# mkdir -p /var/www/htdocs/dotclear

On télécharge le fichier d'installation de dotclear :

# ftp -o /var/www/htdocs/dotclear/dotclear-loader.php https://download.dotclear.org/loader/dotclear-loader.php

Modifiez les permissions sur le dossier qui contiendra dotclear puis rechargez httpd :

# chown -R www:daemon /var/www/htdocs/dotclear
# rcctl reload httpd

Terminez l'installation dans un navigateur à l'URL suivante :

http://blog.chezmoi.tld/dotclear-loader.php

Si vous avez choisi SQLite, il faudra juste compléter le nom du fichier pour la base en le baptisant à votre souhait.

Vous pouvez lire la documentation officielle de dotclear concernant l'installation.

Une fois celle-ci terminée, pensez à supprimer le fichier d'installation :

# rm /var/www/htdocs/dotclear/dotclear-loader.php 

4.8.4. Gestionnaires de contenus (CMS)

4.8.4.1. Wordpress

Wordpress est un moteur relativement lourd mais qui peut permettre de créer n'importe quel site. Si vous recherchez un CMS plus léger et facile à installer, regardez du côté de PluXML.

En attendant, nous sommes dans la partie "travaux pratiques", alors au boulot !

On supposera que vous avez réalisé une installation de PHP complète. Quelques dépendances sont à installer, dont la base de données MariaDB :

# pkg_add php-mysqli-7.2.10 mariadb-server
# cd /etc/php-7.2.sample
# for i in *; do ln -sf ../php-7.2.sample/$i ../php-7.2/; done
# rcctl restart php72_fpm

Vous devez maintenant créer une base de données dans MariaDB, le clone libre de MySQL. Référez-vous à la partie dédiée à cette manipulation. Veillez à retenir le nom de la base choisie, l'utilisateur et le mot de passe.

On télécharge ensuite la dernière version de wordpress :

# ftp -o /tmp/wordpress.tar.gz "https://wordpress.org/latest.tar.gz"

On décompresse l'archive dans le dossier /var/www/htdocs

# cd /var/www/htdocs
# tar xvzf /tmp/wordpress.tar.gz

On modifie les permissions du nouveau dossier :

# chown -R www:daemon /var/www/htdocs/wordpress

On ajoute maintenant une section dans /etc/httpd.conf

server "blog.chezmoi.tld" {
        listen on * tls port 443
        root "/htdocs/wordpress"
        directory index index.php
        hsts
        tls {
            certificate "/etc/ssl/chezmoi.tld-fullchain.pem"
            key "/etc/ssl/private/chezmoi.tld.key"
        }
        # Set max upload size to 35M (in bytes)
        connection max request body 36700160

        # protected files and dir
        location "/.*"                { block }
        location "/upload/*.php"      { block }
        location "/files/*.php"       { block }

        # Any other PHP file
        location "/*.php*" {
                fastcgi socket "/run/php-fpm.sock"
        }
}

Enfin, on recharge httpd : rcctl reload httpd.

Dirigez-vous à l'adresse du nouveau site pour terminer l'installation et remplir les informations concernant la base de données qui vient d'être créée.

L'installation de Wordpress est terminée 😁 Vous pouvez désormais ajouter du contenu et personnaliser votre site.

Si toutefois Wordpress ne vous convenait pas, regardez le paragraphe suivant qui parle de PluXML, nettement plus simple à gérer.

4.8.4.2. PluXML

PluXML est une application très légère qui ne nécessite aucune base de données mais qui pourtant s'avère efficace dans la création d'un site.

Son installation est des plus simples comme vous pourrez le constater.

On commence par télécharger l'archive contenant PluXML après s'être placés dans un dossier temporaire :

# cd /tmp
# ftp -o pluxml.zip "http://telechargements.pluxml.org/download.php"

Vous avez récupéré une archive .zip que l'on décompresse :

# unzip pluxml.zip

Cela nous permet maintenant de déplacer le dossier contenant PluXML à un emplacement approprié pour httpd :

# mv PluXml /var/www/htdocs/pluxml

N'oublions pas de modifier les permissions :

# chown -R www:daemon /var/www/htdocs/pluxml

Il ne nous reste plus qu'à ajouter un nouveau site dans la configuration de httpd. Éditez le fichier /etc/httpd.conf pour y mettre :

server "chezmoi.tld" {
    listen on * port 80
    block return 301 "https://$SERVER_NAME$REQUEST_URI"
}

server "chezmoi.tld" {
    listen on * tls port 443
    root "/htdocs/pluxml/"
    directory index index.php
    hsts
    tls {
        certificate "/etc/ssl/chezmoi.tld-fullchain.pem"
        key "/etc/ssl/private/chezmoi.tld.key"
    }

    location "*.php*" {
        fastcgi socket "/run/php-fpm.sock"
    }

    # On cache le fichier version:
    location "/version" { block }

    # Ligne très importante pour éviter le vol de mot de passe
    location "/data/configuration/users.xml" { block }
}

Parfait ! Maintenant, il ne vous reste plus qu'à recharger httpd puis à consulter votre site dans un navigateur pour achever l'installation :

Une fois terminée, pensez à supprimer le fichier d'installation de PluXML :

# rm /var/www/htdocs/pluxml/install.php

Vous pouvez désormais ajouter de nouveaux articles ou des pages statiques pour créer votre site. N'hésitez pas à échanger avec la communauté sur le forum de PluXML.

4.8.4.3. Drupal

Drupal est un gestionnaire de contenu très répandu mais aussi relativement lourd. Cependant, vous pourrez l'utiliser pour créer toutes sortes de sites.

Avant toutes choses, vous devez avoir déjà installé PHP avec au moins les paquets php-curl, php-gd, un support de base de données et appliqué la configuration relative au chroot. Vous pouvez utiliser n'importe quelle base de données entre SQLite, MySQL ou PostgreSQL. SQLite est le plus intéressant en auto-hébergement et le plus simple.

On télécharge Drupal en utilisant le lien que vous pouvez retrouver à cette page.

# cd /tmp
# ftp -o drupal.tgz https://www.drupal.org/download-latest/tar.gz

Une fois l'archive récupérée, on extrait les fichiers puis on les place dans un dossier accessible par le serveur httpd qui sera ici /var/www/htdocs/drupal :

# tar xvzf drupal.tgz
# mv drupal-*/ /var/www/htdocs/drupal

N'oubliez pas de changer les permissions :

# chown -R www:daemon /var/www/htdocs/drupal

Puisque nous en sommes à configurer la partie serveur httpd, éditez le fichier /etc/httpd.conf pour y ajouter votre nouveau site :

server "chezmoi.tld" {
        listen on * port 80
        block return 301 "https://$SERVER_NAME$REQUEST_URI"
        no log
}

server "chezmoi.tld" {
        listen on * tls port 443
        root "/htdocs/drupal"
        directory index index.php
        connection max request body 36700160
        hsts
        tls {
            certificate "/etc/ssl/chezmoi.tld-fullchain.pem"
            key "/etc/ssl/private/chezmoi.tld.key"
        }

        location "*.php*" {
                fastcgi socket "/run/php-fpm.sock"
        }
}

À titre d'exemple, voici les manipulations à faire pour utiliser MariaDB (mysql) avec drupal. Ces manipulations ne sont pas à effectuer si vous utilisez SQLite.

Il faut créer un utilisateur pour la base de données qui aura le droit de créer une nouvelle table. La table s'appellera drupal_base et l'utilisateur drupaluser. On entre # mysql -u root -p puis :

MariaDB [(none)]> CREATE DATABASE drupal_base;
Query OK, 1 row affected (0.01 sec)

MariaDB [(none)]> CREATE USER 'drupaluser'@'localhost' IDENTIFIED BY 'motdepasse';
Query OK, 0 rows affected (0.01 sec)

MariaDB [(none)]> GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX,
ALTER, CREATE TEMPORARY TABLES ON drupal_base.* TO 'drupaluser'@'localhost';
Query OK, 0 rows affected (0.02 sec)

MariaDB [(none)]> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> exit
Bye

On a presque fini, courage. Rechargez la configuration de httpd avec la commande habituelle

# rcctl reload httpd

Vous pouvez maintenant terminer l'installation en ouvrant dans un navigateur https://chezmoi.tld/ afin d'être redirigé vers la page d'installation.

Et voilà, vous êtes prêts à fabriquer votre site.

4.8.5. CardDAV et CalDAV avec Baïkal

Baïkal est un serveur Cal et CardDAV permettant de synchroniser votre calendrier et vos contacts. Il ne fait que ça, c'est pourquoi il le fait bien tout en restant léger.

Vous aurez besoin pour l'utiliser de PHP et de SQLite.

Vérifiez quelle est la dernière version de Baikal. Vous pouvez ensuite la télécharger avec ftp:

# ftp -o /tmp/baikal.zip "https://github.com/fruux/Baikal/releases/download/0.4.6/baikal-0.4.6.zip"

On se déplace dans le dossier web pour décompresser baikal et modifier les droits sur les fichiers :

# cd /var/www/htdocs/
# unzip /tmp/baikal.zip
# chown -R www:daemon baikal

Ajoutez une nouvelle section dans le fichier /etc/httpd.conf pour configurer httpd. Notez qu'on ne configure ici qu'un accès via une adresse en "https" :

server "dav.chezmoi.tld" {
    listen on * tls port 443
    root "/htdocs/baikal/html" 
    directory index index.php
    hsts
    tls {
        certificate "/etc/ssl/chezmoi.tld-fullchain.pem"
        key "/etc/ssl/private/chezmoi.tld.key"
    }

    location "/.well-known/caldav" { 
        block return 301 "https://$SERVER_NAME/dav.php" 
    }
    location "/.well-known/carddav" { 
        block return 301 "https://$SERVER_NAME/dav.php" 
    }

    location "/.ht*" { block }
    location "/Core*" { block }
    location "/Specific*" { block }

    location "*.php*" {
        fastcgi socket "/run/php-fpm.sock"
    }
}

Reste à recharger httpd avec rcctl reload httpd. Vous pouvez désormais vous rendre à l'adresse https://dav.chezmoi.tld pour terminer l'installation.

4.8.5.1. Configuration de Thunderbird pour Baïkal

Pour utiliser votre calendrier, vous pouvez récupérer l'excellente extension lightning pour Thunderbird.

Pour la télécharger, c'est par ici. Enregistrez le fichier .xpi puis ouvrez-le dans Thunderbird à partir du menu des modules accessible dans le menu de Thunderbird remarquable par ses 3 traits horizontaux en haut à droite.

Il faudra cliquer sur le petit engrenage pour choisir d'installer à la main l'extension précédemment téléchargée :

Ci-dessous, vous pourrez lire des instructions issues de guillaume-leduc.fr pour utiliser votre instance de Baïkal avec Thunderbird.

Vous pouvez créer un nouvel agenda en faisant un clic-droit dans la zone où sont listés tous les calendriers.

Lors de la configuration de votre agenda CalDAV, vous devrez renseigner l'adresse suivante pour un agenda "sur le réseau" :

https://dav.chezmoi.tld/cal.php/calendars/UTILISATEUR/ID_AGENDA/

Vous remplacerez UTILISATEUR et ID_AGENDA selon l'adresse visible dans votre navigateur. N'oubliez pas le / final. Dans l'exemple ci-dessous, ça donne une URL qui se termine par /toto/default/ :

Pour un carnet d'adresses, l'URL à renseigner est la suivante :

https://dav.chezmoi.tld/card.php/addressbooks/UTILISATEUR/CARNET/

4.8.5.2. Configuration de Rainloop pour Baïkal

Si vous utilisez le webmail RainLoop, sachez qu'il est possible d'utiliser la synchronisation des contacts avec votre instance de Baïkal.

Dans l'interface d'administration de Rainloop, allez dans l'onglet "Contacts" puis cochez "Enable contacts" et "Allow contact sync" :

Ensuite, connectez-vous en simple utilisateur. Dans les paramètres de ce dernier accessibles en haut à droite, vous trouverez un onglet "Contact" permettant de préciser l'adresse de votre instance Baïkal sur le même modèle que pour Thunderbird, autrement dit :

https://dav.chezmoi.tld/card.php/addressbooks/UTILISATEUR/CARNET/

4.8.6. Un Wiki

Il existe tellement de moteurs de wiki qu'il est difficile de faire un choix. Ces derniers sont souvent très configurables et permettent d'en faire des blogs voire des sites complets.

Nous allons nous intéresser ici à l'installation de dokuwiki, un des moteurs les plus connus et les plus pratiques grâce à ses multiples extensions et le peu de dépendances qu'il nécessite. Vous aurez besoin de PHP et SQLite.

L'installation est semblable à la plupart des sites web comme vous pourrez le voir, c'est pourquoi elle ne sera pas exhaustive.

Téléchargement de dokuwiki :

# ftp -o /tmp/dokuwiki.tgz "http://download.dokuwiki.org/src/dokuwiki/dokuwiki-stable.tgz"

Extraction de l'archive :

# cd /var/www/htdocs
# tar xvzf /tmp/dokuwiki.tgz

On renomme le dossier et on change les droits :

# mv dokuwiki-* wiki
# chown -R www:daemon wiki

La configuration de httpd peut se réaliser ainsi dans le fichier /etc/httpd.conf:

server "wiki.chezmoi.tld" {
    listen on * port 80
    block return 301 "https://$SERVER_NAME$REQUEST_URI"
    no log
}

server "wiki.chezmoi.tld" {
    listen on * tls port 443
    root "/htdocs/wiki"
    directory index doku.php
    # Set max upload size to 35M (in bytes)
    connection max request body 36700160
    hsts
    tls {
        certificate "/etc/ssl/chezmoi.tld-fullchain.pem"
        key "/etc/ssl/private/chezmoi.tld.key"
    }

    location "*.php*" {
        fastcgi socket "/run/php-fpm.sock"
    }

    location "/data*"         { block }
    location "/conf*"         { block }
    location "/bin*"          { block }
    location "/inc*"          { block }
}

Rechargez httpd avec rcctl reload httpd, puis ouvrez dans un navigateur l'adresse de votre wiki pour terminer l'installation.

Une fois l'installation terminée, supprimez le fichier install.php

# rm /var/www/htdocs/wiki/install.php

4.8.7. Lecteur de flux RSS

Vous pouvez installer sur votre serveur un outil qui vous permettra de lire en un seul endroit les nouveautés publiées sur vos sites favoris grâce à leurs flux RSS. C'est nettement plus pratique que consulter les pages WEB une par une.

4.8.7.1. KrISS : simple mais efficace

KrISS est un lecteur de flux qui tient en un seul fichier PHP. Oui, un seul ! Pourtant, il est complet et rapide, tout ce qu'il faut pour une utilisation personnelle.

Ceux qui souhaiteraient proposer un service d'agrégateur de flux à plusieurs personnes pourront très bien installer KrISS dans différents dossiers, un par utilisateur.

L'installation est simple comme tout, il faut télécharger le fichier de KrISS puis le placer sur votre serveur web (http).

  • Préparez votre serveur pour PHP et ajoutez-y l'extension curl. Réalisez aussi la configuration relative au chroot afin de résoudre les noms de domaine.
  • Téléchargez KrISS :
    ftp -o /tmp/index.php https://raw.github.com/tontof/kriss_feed/master/index.php
    
  • Créez le dossier qui contiendra KrISS :
    # mkdir -p /var/www/htdocs/kriss
    
  • Déplacez le fichier index.php à l'endroit souhaité :

    # mv /tmp/index.php /var/www/htdocs/kriss
    

  • Ajustez les permissions :
    # chown -R www:daemon /var/www/htdocs/kriss
    

  • Ajustez éventuellement la configuration de /etc/httpd.conf, mais ça a sûrement déjà été fait lors de la configuration de PHP :

    server "chezmoi.tld" {
        root "/htdocs/kriss"
        listen on * tls port 443
        hsts
        tls {
            certificate "/etc/ssl/chezmoi.tld-fullchain.pem"
            key "/etc/ssl/private/chezmoi.tld.key"
        }
        location "*.php*" {
            fastcgi socket "/run/php-fpm.sock"
        }
    
        location "/kriss/" {
            directory index index.php
        }
    }
    
  • Relancez httpd avec rcctl reload httpd puis ouvrez votre navigateur sur l'emplacement de KrISS afin de terminer l'installation.

Profitez 😉

4.8.7.2. TinyTinyRSS : application complète

Tiny Tiny RSS est un autre agrégateur de flux. Ce dernier est très complet et conviendra davantage à ceux souhaitant proposer ce service à plusieurs personnes. Toutefois, son installation est loin d'être simple, et il s'avère souvent plus pratique d'avoir plusieurs instances de KrISS à la place. Mais libre à vous d'utiliser votre outil favori.

Pour l'installer, vous devez avoir déjà :

Nous allons utiliser PostgreSQL par souci de performance. On va créer une base uniquement pour Tiny Tiny RSS. Nous faisons le choix de passer par un utilisateur ttrss qui aura accès à la base :

# psql -U postgres -c "CREATE USER ttrss \
        WITH PASSWORD 'mot_de_passe_de_l_utilisateur';"

# psql -U postgres 
\connect template1
CREATE DATABASE "ttrssdb" WITH ENCODING 'UTF-8';
GRANT ALL PRIVILEGES ON DATABASE "ttrssdb" TO ttrss;
ALTER DATABASE "ttrssdb" OWNER TO ttrss;
\q

Nous pouvons enfin passer à la configuration de ttrss. On le télécharge dans le dossier /var/www/htdocs/ttrss :

# cd /var/www/htdocs
# git clone --depth=1 https://tt-rss.org/git/tt-rss.git ttrss

Ensuite, nous modifions les permissions pour le serveur web (http) :

# chown -R www:daemon /var/www/htdocs/ttrss

On édite /etc/httpd.conf pour y ajouter notre nouveau site :

server "rss.chezmoi.tld" {
    listen on * port 80
    block return 301 "https://$SERVER_NAME$REQUEST_URI"
    no log
}

server "rss.chezmoi.tld" {
    listen on * tls port 443
    root "/htdocs/ttrss"
    directory index index.php
    hsts
    tls {
        certificate "/etc/ssl/chezmoi.tld-fullchain.pem"
        key "/etc/ssl/private/chezmoi.tld.key"
    }

    location "*.php*" {
        fastcgi socket "/run/php-fpm.sock"
    }
}

On recharge la configuration de httpd :

# rcctl reload httpd

Vous pouvez désormais terminer l'installation en ouvrant votre navigateur à l'adresse https://rss.chezmoi.tld/install/.

On vous demande les identifiants pour accéder à la base de données. Ce sont ceux que vous avez créés juste avant pour l'utilisateur ttrss.

Cliquez ensuite sur "Initialize database" :

Cliquez sur "Save Configuration" pour l'enregistrer. Vous pouvez bien sûr modifier cette configuration selon vos besoins avant.

Vous pouvez maintenant vous diriger à l'adresse http://rss.chezmoi.tld pour vérifier que tout fonctionne bien. Les identifiants par défaut sont "admin" et "password", qu'il faudra changer au plus vite.

Si tout s'est bien passé, vous pouvez supprimer l'installateur :

# rm -r /var/www/htdocs/ttrss/install

Vous souhaiterez certainement mettre à jour régulièrement la liste des flux de façon automatique. Si vous avez lu la documentation relative à TinyTinyRSS, vous savez qu'il faut exécuter le fichier update.php. Par exemple, dans une tâche cron :

@hourly /usr/local/bin/php-7.2 /var/www/htdocs/ttrss/update.php --feeds --quiet

Il vous sera peut-être demandé de modifier les permissions sur certains répertoires. Vous devez alors entrer :

chown -R 777 /var/www/htdocs/ttrss/cache/images
chown -R 777 /var/www/htdocs/ttrss/cache/upload
chown -R 777 /var/www/htdocs/ttrss/cache/export
chown -R 777 /var/www/htdocs/ttrss/feed-icons
chown -R 777 /var/www/htdocs/ttrss/lock

4.8.8. Statistiques des visites sur vos sites

4.8.8.1. Avec Webalizer

Webalizer est un outil qui peut générer graphiques et tableaux à partir des logs (journaux) de votre serveur. En un clin d'œil vous pourrez trouver à propos de votre site :

  • Horaires de visites ;
  • Nombre de clics ;
  • Quantité de données chargées ;
  • Pages 404 (pratique pour traquer les liens morts) ;
  • D'où viennent les visiteurs…

D'autres outils similaires existent, en particulier matomo. Ce dernier est toutefois moins facile à mettre en place (base de données MySQL) et nécessite l'insertion de code html dans toutes vos pages web. Il est aussi moins efficace si les visiteurs utilisent des addons Firefox comme noscript ou μblock. Cependant, les données récoltées sont plus pertinentes. Vous voudrez donc peut-être compléter l'installation de webalizer avec matomo.

Quoi qu'il en soit, nous allons voir ici une méthode pour obtenir de belles statistiques avec webalizer.

Comme d'habitude, on commence par l'installer avec la commande magique :

# pkg_add webalizer

Pour le configurer, nous allons utiliser comme base le modèle fourni. On le copie par exemple dans /etc/ :

# cp /usr/local/share/examples/webalizer/sample.conf /etc/webalizer.chezmoi.tld.conf

Éditez ce nouveau fichier pour l'adapter à vos besoins. Voici quelques options pratiques que vous voudrez certainement changer :

  • LogFile /var/www/logs/access.log : Emplacement des journaux du serveur web.
  • OutputDir /var/www/htdocs/chezmoi.tld/stats : Vous choisissez où seront enregistrées les pages html générées. Référez-vous à la partie sur httpd pour configurer votre serveur web (http) et accéder aux statistiques avec un navigateur. Attention de bien créer ce répertoire au préalable, sinon Webalizer plantera avec un message d'erreur.
  • HideSite *chezmoi.tld et HideReferrer chezmoi.tld/ : On cache les liens provenant des clics réalisés sur votre site vers votre site.
  • HideURL *.css , HideURL *.woff : On cache les extensions de fichiers non souhaitées.
  • IgnoreURL /favicon.ico : On ignore certaines URL lorsque les statistiques sont générées.
  • Color* : Pour changer les couleurs, car le thème par défaut, n'est pas très attrayant tout de même.
  • HTMLHead … : tout ce qui sera rajouté dans l'entête de la page html générée. Vous pouvez de cette façon ajouter quelques lignes CSS pour modifier l'apparence, par exemple :

    HTMLHead <style type="text/css">
    HTMLHead body {
    HTMLHead background: radial-gradient(circle,#2569A0,#000046);
    HTMLHead }
    HTMLHead </style>
    

    Vous trouverez un exemple de configuration de webalizer à la fin du document

    Vous pouvez générer une première fois les statistiques avec la commande suivante :

    # webalizer -c /etc/webalizer.chezmoi.tld.conf
    

Et hop, toutes les pages html et les graphiques sont dans le dossier défini par la variable OutputDir, il suffit de vous y rendre avec un navigateur web pour les étudier.

Cependant, vous devrez régler encore quelques petits détails. Par exemple, la partie des "Referers" qui recense les sites sur lesquels le vôtre est cité doit être bien maigre. Il faut régler la façon dont httpd produit les logs. Rien de bien compliqué, il faut juste ajouter dans le fichier /etc/httpd.conf la ligne suivante dans le site pour lequel on veut des statistiques : log style combined.

Euh, on peut avoir un exemple siouplé?

Voici :

server "chezmoi.tld" {
    listen on * tls port 443
    root "/htdocs/chezmoi.tld"
    directory index index.html
    log style combined

    hsts
    tls {
        certificate "/etc/ssl/chezmoi.tld-fullchain.pem"
        key "/etc/ssl/private/chezmoi.tld.key"
    }
}

N'oubliez pas de recharger httpd avec rcctl reload httpd.

Mais on doit lancer la commande webalizer manuellement ? C'est nul ce truc !

On n'en reste pas là bien entendu. Afin que les statistiques soient générées par exemple tous les jours, nous pourrions profiter du fichier /etc/daily.local.

De plus, il faut éviter que les logs n'aient été archivés avant d'avoir été traités par webalizer. Nous allons donc modifier la configuration de l'outil qui compresse les logs régulièrement. Il s'agit de newsyslog. On édite le fichier /etc/newsyslog.conf qui ressemble à ça :

# $OpenBSD: newsyslog.conf,v 1.34 2015/10/14 20:54:07 millert Exp $
#
# configuration file for newsyslog
#
# logfile_name      owner:group     mode count size when  flags
/var/cron/log       root:wheel      600  3     10   *     Z
/var/log/aculog     uucp:dialer     660  7     *    24    Z
/var/log/authlog    root:wheel      640  7     *    168   Z
/var/log/daemon                     640  5     30   *     Z
/var/log/lpd-errs                   640  7     10   *     Z
/var/log/maillog                    640  7     *    24    Z
/var/log/messages                   644  5     30   *     Z
/var/log/secure                     600  7     *    168   Z
/var/log/wtmp                       644  7     *    $W6D4 B
/var/log/xferlog                    640  7     250  *     Z
/var/log/pflog                      600  3     250  *     ZB "pkill -HUP -u root -U root -t - -x pflogd"
/var/www/logs/access.log            644  4     *    $W0   Z "pkill -USR1 -u root -U root -x httpd"
/var/www/logs/error.log             644  7     250  *     Z "pkill -USR1 -u root -U root -x httpd"

C'est l'avant-dernière ligne que nous allons changer afin de lancer webalizer avant de faire tourner les logs du serveur web (http). Elle ressemblera à :

/var/www/logs/access.log            644  4     *    $W0   Z "/usr/local/bin/webalizer -c /etc/webalizer.chezmoi.tld.conf && pkill -USR1 -u root -U root -x httpd"

Pour vérifier que tout fonctionne bien, lancez newsyslog en le forçant à archiver les logs et en le faisant parler. Vous devriez obtenir quelque chose de la sorte :

# newsyslog -vF
/var/cron/log <3Z>: size (KB): 7.24 [10] --> trimming log….
/var/log/authlog <7Z>: age (hr): 88 [168] --> trimming log….
/var/log/daemon <5Z>: size (KB): 0.41 [30] --> trimming log….
/var/log/lpd-errs <7Z>: size (KB): 2.02 [10] --> trimming log….
/var/log/maillog <7Z>: age (hr): 16 [24] --> trimming log….
/var/log/messages <5Z>: size (KB): 0.45 [30] --> trimming log….
/var/log/secure <7Z>: age (hr): -1 [168] --> trimming log….
/var/log/wtmp <7B>: --> trimming log….
/var/log/xferlog <7Z>: size (KB): 0.00 [250] --> trimming log….
/var/log/pflog <3ZB>: size (KB): 64.26 [250] --> trimming log….
/var/www/logs/access.log <4Z>: --> trimming log….
/var/www/logs/error.log <7Z>: size (KB): 212.87 [250] --> trimming log….
/var/www/logs/mateteestmalade.log <7Z>: size (KB): 3.93 [250] --> trimming log….
Webalizer Xtended RB30 (06-Apr-2014) / [OpenBSD https://www.openbsd.org/] 5.9 amd64 / English
Copyright 2005-2014 by Patrick K. Frei
Based on Webalizer V2.23-08
Using logfile /var/www/logs/access.log (clf)
Using GeoIP Country Edition (/var/db/GeoIP/GeoIP.dat)
GEO-106FREE 20151201 Build 1 Copyright (c) 2015 MaxMind Inc All Rights Reserved
Creating output in /var/www/htdocs/chezmoi.tld/stats
Hostname for reports is 'chezmoi.tld'
Reading history file… webalizer.hist
Skipping bad record (1)
No valid records found!
Generating summary report

Il y a les messages de webalizer qui montrent qu'il a été exécuté.

Et voilà, les statistiques sont générées régulièrement et avant que les logs ne soient archivés.

4.8.8.2. Avec Matomo

Matomo est nettement plus lourd pour générer des statistiques. Si votre serveur a une puissance limitée, préférez webalizer.

Je ne vais pas détailler l'installation pas à pas dans cette partie. Je suppose donc que vous avez lu et compris la partie sur PHP ainsi que celle sur MySQL.

Pour PHP, installez et activez ces paquets : php-curl php-gd. Il y a aussi besoin des bibliothèques geoip et cli qui sont normalement intégrées dans le paquet PHP d'OpenBSD.

Installez une base MySQL (mariadb). Voici un récapitulatif tiré de la documentation de matomo:

# mysql -u root -p
mysql> CREATE DATABASE matomo_db_name_here;
mysql> CREATE USER 'matomo'@'localhost' IDENTIFIED BY 'password';
mysql> GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES ON matomo_db_name_here.* TO 'matomo'@'localhost';

Ensuite, on télécharge matomo dans le dossier /var/www/htdocs/matomo :

# ftp -o /tmp/matomo.zip "http://builds.matomo.org/matomo.zip" 
# cp /tmp && unzip /tmp/matomo.zip
# mv matomo /var/www/htdocs/

Configurez maintenant un nouveau site dans le fichier /etc/httpd.conf :

server "stats.chezmoi.tld" { 
    listen on * tls port 443 
    root "/htdocs/matomo/"
    directory index index.php

    hsts 
    tls {
        certificate "/etc/ssl/chezmoi.tld-fullchain.pem"
        key "/etc/ssl/private/chezmoi.tld.key"
    }

    location "*.php*" {
        fastcgi socket "/run/php-fpm.sock"
    }
}

Modifiez les permissions sur ce dossier :

# chown -R www:daemon /var/www/htdocs/matomo

Rechargez httpd avec rcctl reload httpd puis dirigez-vous avec un navigateur sur l'adresse du site fraîchement activé pour terminer l'installation de matomo.

N'oubliez pas d'ajouter à vos pages web le code d'intégration donné.

4.8.8.3. Avec goaccess

Plus proche de webalizer que de Matomo dans son fonctionnement, goaccess propose une interface plus moderne. Il peut en outre générer des rapports au format html, mais aussi vous laisser consulter les statistiques dans terminal en temps-réel.

Afin de profiter de statistiques incrémentales au fil du temps, il faut installer la saveur "tokyocabinet" du paquet :

	# pkg_add goaccess-1.3p1-tokyocabinet

Pensez à regarder l'exemple donné dans le paquet : /usr/local/share/examples/goaccess/goaccess.conf

Cela vous indique qu'il faut, ici aussi, utiliser l'option log style combined dans la configuration d'httpd.

Vous pouvez créer un fichier de configuration pour goaccess qu'on appelera ici /etc/goaccessrc

# format des [logs #logs]
time-format %T %z
date-format %d/%b/%Y
log-format %v %h %^ %^ [%d:%t] "%r" %s %b "%R" "%u"
# Base de donénes pour la géolocalisation
geoip-database /var/db/GeoIP/GeoLite2-Country.mmdb
# Ne s'arrête pas si une ligne ne peut être parsée
num-test 0
# Enregistre les données sur le fichier pour avoir
# des statistiques incrémentales
load-from-disk true
keep-db-files true
# Dossier où seront enregistrées le statistiques
db-path /var/goaccessdb/

On crée le dossier qui contiendra les données de goaccess : mkdir -p /var/goaccessdb/.

Afin de générer les statistiques dans la page /var/www/htdocs/monsite/stats.html, on lance la première fois:

zcat /var/www/logs/chezmoi.tld.log.*.gz | cat /var/www/logs/chezmoi.tld.log | \
    goaccess -o /var/www/htdocs/chezmoi.tld/stats.html -p /etc/goaccessrc
    --load-from-disk false

Ensuite, ceci suffira tant que c'est fait avant la rotation des logs (voir le paragraphe sur webalizer).

goaccess /var/www/logs/chezmoi.tld.log -o /var/www/htdocs/chezmoi.tld/stats.html -p /etc/goaccessrc

Si vous constatez des erreurs de ce type

Fatal error has occurred
Error occurred at: src/tcabdb.c - tc_adb_create - 126
Unable to open an abstract database: /var/goaccessdb//8mcs9SUehdb_cumts.tcb#lcnum=1024#ncnum=512#lmemb=128#nmemb=256#bnum=32749#opts=l#mode=wct

Avant de créer les statistiques, vous devez augmenter la limite du nombre de fichiers qui peuvent être ouverts avec la commande ulimit -n 256. Ensuite, goaccess fonctionnera comme prévu.

5. SFTP : Serveur de transfert de fichiers

Le protocole SFTP ressemble beaucoup au célèbre FTP qui sert surtout à transférer des fichiers, mais se base sur un tunnel SSH. À vrai dire, chaque utilisateur disposant d'un accès SSH peut envoyer et télécharger des données en SFTP avec ses identifiants habituels. Un des avantages intéressant est de pouvoir reprendre un chargement partiel là où il en était, très utile pour envoyer/recevoir des fichiers volumineux.

Si vous voulez déployer un serveur SFTP pour un plus grand nombre d'utilisateurs, la mise en place d'un "chroot" est conseillée. Cette procédure est décrite plus loin dans le document car un poil plus complexe.

5.1. Transferts en ligne de commande

Pour copier des fichiers, vous pouvez utiliser la commande sftp qui s'utilise ainsi :

sftp -P <port> utilisateur@chezmoi.tld

Si vous avez désactivé l'identification par mot de passe au profit des clés, indiquez quelle est votre clé privée ainsi :

sftp -P <port> -o IdentityFile=~/.ssh/clessh utilisateur@chezmoi.tld

Vous voilà alors devant une invite de commande.

Voici quelques commandes utiles :

  • put fichier : sert à envoyer un fichier.
  • get fichier : télécharge un fichier.
  • ls : liste les documents sur le serveur.
  • cd repertoire : se déplace dans un autre répertoire sur le serveur.
  • lcd repertoire : se déplace dans un autre répertoire sur l'ordinateur client.
  • mkdir : crée un dossier sur le serveur.
  • quit : ferme la session.
  • help : liste les commandes disponibles 😁.

Rien de bien compliqué finalement, mais vous préférerez peut-être un client graphique comme expliqué ci-dessous.

5.2. Transferts avec un client graphique

5.2.1. Avec Filezilla

Le logiciel Filezilla peut se télécharger ou s'installer directement via le gestionnaire de paquets de votre distribution. Vérifiez qu'il s'agit bien d'une version à jour.

Ouvrez Filezilla, puis cliquez sur la petite icône en haut à gauche "Gestionnaire de sites". Une nouvelle fenêtre s'ouvre :

Cliquez sur "Nouveau Site", puis remplissez les champs ainsi :

  • Hôte : chezmoi.tld
  • Port : 222 (à remplacer par le port SSH)
  • Protocole : SFTP - SSH File Transfert Protocol
  • Type d'authentification : Normale
  • Identifiant : votre identifiant
  • Mot de passe : votre mot de passe

Il ne vous reste plus qu'à cliquer sur Connexion. Sélectionnez les fichiers que vous souhaitez envoyer ou récupérer, puis faites un clic-droit pour les télécharger. La même chose est possible avec des glisser/déposer.

D'autres clients graphiques existent, on pourra notamment citer WinSCP disponible sous Windows.

5.2.2. Avec votre gestionnaire de fichiers

Selon votre système d'exploitation, il y a fort à parier que votre gestionnaire de fichiers (Dolphin sous KDE ou Nautilus sous Gnome par exemple) soit lui même capable d'ouvrir une session SFTP. Comme chemin vers le dossier, indiquez simplement :

sftp://utilisateur@chezmoi.tld:222

Remplacez 222 par le port ssh du serveur (22 si vous ne mettez rien). Bien sûr, "utilisateur" est aussi à remplacer (par exemple jean_eudes ou toto).

Cela donne sur Nautilus :

ou encore avec Thunar (XFCE) :

5.2.3. Avec sshfs

sshfs est un outil qui permet de monter un dossier disponible via SFTP comme s'il s'agissait d'un point de montage de votre système. Peu importe votre gestionnaire de fichiers, vous pourrez copier vos documents comme s'il s'agissait d'un dossier classique.

sshfs s'utilise tout simplement ainsi :

sshfs -d utilisateur@chezmoi.tld:/dossier/distant /mnt/sftp 

Ensuite, le dossier /mnt/sftp contiendra le contenu du dossier distant.

Dans le cas où vous utilisez une identification par clé uniquement, indiquez quelle clé privée utiliser ainsi :

sshfs -d utilisateur@chezmoi.tld:/dossier/distant /mnt/sftp -o IdentityFile=/home/toto/.ssh/rqfdkj

5.3. SFTP avec chroot

L'idée ici est d'enfermer dans un dossier les utilisateurs appartenant au groupe sftpusers. Cela leur évitera de copier n'importe où leurs documents, mais aussi de supprimer des éléments importants du serveur.

À titre d'exemple, nous allons mettre le chroot dans le dossier /var/sftp. Chaque utilisateur aura dans ce dernier un dossier qui lui sera propre. Il ne pourra pas en sortir. Les utilisateurs auront l'impression qu'il s'agit d'une nouvelle racine /. Un dossier "docs" leur permettra d'envoyer ses fichiers.

Créons de suite le groupe en question : groupadd sftpusers.

Éditez le fichier /etc/ssh/sshd_config puis ajoutez les lignes suivantes :

Match Group sftpusers
		ChrootDirectory /var/sftp/%u
		ForceCommand internal-sftp
		AllowTcpForwarding no

Pensez à bien modifier la ligne déjà existante qui contient Subsystem.

Si vous souhaitez ne permettre que l'identification par clé; précisez dans cette section :

PasswordAuthentication no

Ensuite, relancez SSH : rcctl reload sshd

Créez maintenant un dossier /sftp dans le dossier /var/ pour que les utilisateurs y soient automatiquement placés à leur connexion.

# mkdir -p /var/sftp

Modifiez les permissions pour assurer une sécurité supplémentaire :

# chown root:wheel /var/sftp
# chmod 700 /var/sftp

Chaque utilisateur du groupe sftpusers sera placé dans ce dossier dès qu'il se connectera au serveur. Notez que ces utilisateurs ne pourront qu'utiliser le protocole sftp, et donc la commande sftp (ou un client graphique), mais pas scp ou openrsync au travers d'un tunnel ssh.

5.3.1. Ajouter un compte SFTP

Ajouter un compte SFTP revient à créer un nouvel utilisateur et mettre ce dernier dans le groupe sftpusers.

Il faut quand même faire attention à plusieurs points :

  • L'utilisateur ne doit pouvoir faire que du SFTP. On va donc lui attribuer le shell "nologin" qui ne permet pas de lancer des commandes.
  • Il faut s'assurer que seul l'utilisateur a les droits d'écriture dans son dossier. On lui créera un dossier docs prévu à cet effet.

Voici la marche à suivre :

  • Création d'un groupe sftpusers si ce n'est pas déjà fait : groupadd sftpusers.
  • Ajout d'un utilisateur avec création du dossier personnel à l'endroit souhaité et ajout dans le groupe sftpusers.
    # useradd -G sftpusers -s /sbin/nologin -m utilisateur
    

  • On modifie le mot de passe avec passwd utilisateur .
  • On crée le dossier pour l'utilisateur :
    # mkdir -p /var/sftp/utilisateur
    
  • On crée le dossier dans lequel l'utilisateur aura le droit d'écrire :
    # mkdir -p /var/sftp/utilisateur/docs
    # chown utilisateur:sftpusers /var/sftp/utilisateur/docs
    

    Finalement, personne d'autre ne doit pouvoir accéder à la racine de l'utilisateur :

    # chown root:wheel $CHROOT/$user
    

    L'utilisateur peut maintenant utiliser le protocole SFTP. Il sera enfermé dans son dossier précédemment créé.

    Je vous invite à créer un script pour vous faciliter cette procédure :

    #!/bin/sh
    # addsftpuser.sh : 
    	if [ $# -ne 1 ]; then
    			echo "usage: $0 user"
    			exit
    	fi
        # CHANGE MOI
    	CHROOT=/var/sftp/
    	user="$1"
    	mkdir -p "${CHROOT}"
    	useradd -G sftpusers -s /sbin/nologin -m "${user}"
    	mkdir -p "${CHROOT}/${user}/docs
    	chown "${user}":sftpusers "${CHROOT}/${user}/docs"
    	chown root:wheel "${CHROOT}/${user}"
    exit
    

Si vous avez activé l'identification par clé, vous remplirez le fichier .ssh/authorized_keys dans le dossier personnel de l'utilisateur : celui placé dans /home.

6. Héberger son courrier électronique

Devenir responsable de ses communications est un pas de géant vers l'autonomie et la liberté. Cette partie explique l'installation d'un serveur de courriel à la maison. Aucune base de données ne sera utilisée, puisque cela ne représente aucun intérêt en auto-hébergement. Restons simples !

La mise en place d'un serveur mail est souvent considérée comme délicate. On va donc détailler l'installation pas à pas en petites étapes simples :

Nous verrons en passant comment ajouter de nouveaux comptes mail sur votre serveur et comment configurer votre client de messagerie pour l'utiliser.

Par défaut, si vous ne touchez à rien, les démons de votre serveur sont capables d'envoyer des messages vers l'extérieur. Ça reste limité et n'a rien à voir avec un service de messagerie complet.

Notez que certains fournisseurs d'accès à internet bloquent les mails sortant (port 25). Renseignez-vous avant d'avoir une mauvaise surprise. À défaut, regardez une proposition au paragraphe parlant de service smtp externe.

Je vous propose deux configurations :

6.1. Configuration de votre zone DNS pour les mails

Le système de mail passe par des enregistrements qui lui est propre. Nous devons donc procéder à quelques modifications chez notre registre ou dans notre zone. Ajoutez deux nouveaux champs :

  • Un champ de type A qui pointe vers votre IP (sans doute déjà présent):
    chezmoi.tld IN A 192.0.2.2
    
    Bien sûr, remplacez 192.0.2.2 par votre IP.
  • Un champ de type MX qui pointe vers le A précédent
    chezmoi.tld. IN MX 1 chezmoi.tld.
    

    Notez l'importance du "." final.

Certains spécifient un champ A différent du domaine principal afin de gérer des backups (serveurs de mail secondaires) plus tard. Ce n'est pas nécessaire du tout, mais si vous y tenez, voici à quoi ça ressemblera :

mail1.chezmoi.tld IN A 192.0.2.2
mail1.chezmoi.tld. IN MX 1 mail1.chezmoi.tld.

Ça sera tout pour cette partie.

6.2. Création des certificats

Ces certificats permettront de chiffrer la communication entre votre serveur et le logiciel qui récupère vos mails. De plus, cela rend chaque communication authentique.

Pour obtenir ou créer des certificats, je vous renvoie à la partie consacrée. Que vous utilisiez letsencrypt ou bien des certificats auto-signés n'a pas grande importance, les deux fonctionnent très bien. Veillez juste à bien prendre note de l'emplacement des certificats sur votre serveur.

Par la suite, nous feront comme si nous utilisions les certificats obtenus avec letsencrypt.

6.3. Un serveur mail en 10 minutes

Voici une configuration pour les plus pressés. Avec cette dernière :

  • Les comptes mail sont les utilisateurs du système. Un compte utilisateur = un compte mail.
  • Les mails seront enregistrés dans un dossier ~/Maildir situé dans le dossier personnel de chaque utilisateur.
  • Un utilisateur "toto" aura pour adresse mail "toto@chezmoi.tld".
  • Pour ajouter un compte, référez-vous à la commande adduser Le shell /sbin/nologin sera de préférence à attribuer dans la plupart des cas.
  • Il ne vous est pas possible de gérer plusieurs domaines.
  • C'est plus difficile à gérer si vous avez de nombreux utilisateurs. Pour une dizaine seulement, c'est amplement suffisant et efficace.

La configuration sera plus détaillée et expliquée dans la partie avec utilisateurs virtuels. Ici, c'est pour les pressés.

C'est parti ? 😁

6.3.1. Fichier smtpd.conf

Voici le contenu du fichier /etc/mail/smtpd.conf :

# Configuration generale
## Tables 
table aliases file:/etc/mail/aliases

## Certificats
pki chezmoi.tld key "/etc/ssl/private/chezmoi.tld.key"
pki chezmoi.tld cert "/etc/ssl/chezmoi.tld-fullchain.pem"

### Messages locaux
listen on lo0 

### Reception
listen on egress tls pki chezmoi.tld 
### Envoi avec client de messagerie
listen on egress port submission tls-require pki chezmoi.tld auth 


# ACTIONS
action "envoi" relay 

## On applique les alias systeme
action local_maildir maildir alias <aliases>
## On delivre l'enveloppe dans un dossier maildir
action in_maildir maildir 

# Correspondances
## Reception
### Message du systeme pour les utilisateurs locaux
match for local action local_maildir
### Message pour les utilisateurs virtuels
match from any for domain "chezmoi.tld" action in_maildir

## Envoi
match for any action "envoi"
match auth from any for any action "envoi"

C'est tout 😁

6.3.2. Configuration de dovecot

Installez dovecot avec # pkg_add dovecot.

Dans le fichier /etc/dovecot/local.conf; indiquez :

# On écoute en IPV4 et IPV6.
listen = *, [::]

# On stocke en Maildir
mail_location = maildir:~/Maildir

# imap > pop
protocols = imap

# Securisation. Editez ces lignes
ssl = yes
ssl_cert = </etc/ssl/chezmoi.tld-fullchain.pem
ssl_key = </etc/ssl/private/chezmoi.tld.key
disable_plaintext_auth = yes

# methodes d'authentification
passdb {
        driver = bsdauth
}

userdb {
        driver = passwd
}

Et voilà ! Vous étiez prévenus, c'est fait en 10 minutes.

Si vous voulez davantage de détails, notamment sur dovecot, allez lire la suite. 😉

6.4. Serveur mail avec utilisateurs virtuels

6.4.1. Préambule

Cette désignation fait référence à des utilisateurs qui sont bien réels, mais qui ne sont pas des comptes UNIX à proprement parler qui peuvent accéder à un shell (la ligne de commande).

Ainsi, un nouveau compte mail ne sera pas créé avec adduser, mais en éditant un simple fichier texte contenant le nom d'utilisateur et un hash de son mot de passe.

Dans tous les cas, vérifiez bien que le paquet opensmtpd-extras est installé. Il est nécessaire pour profiter des tables de mots de passe.

6.4.1.1. Un utilisateur responsable des mails : _vmail

On va créer utilisateur en charge de tous les mails. Il portera le doux nom de "_vmail" 😁. Ce dernier ne servira qu'à ça et n'aura donc pas accès au shell, c'est plus sûr 😁 :

# useradd -m -g =uid -c "Virtual Mail" -d /var/vmail -s /sbin/nologin _vmail

Un nouveau dossier est créé : /var/vmail. Les messages des utilisateurs seront dedans, mais bien organisés : dans ce dossier, il y aura des sous-répertoires portant le nom des utilisateurs virtuels. Ainsi, les messages seront enregistrés dans, par exemple :

/var/vmail/chezmoi.tld/batman/Maildir
/var/vmail/chezmoi.tld/utilisateur/Maildir
/var/vmail/chezmoi.tld/ninja/Maildir
…

6.4.1.2. /etc/mail/virtuals

Ce fichier contient la liste des utilisateurs, un par ligne. Il fonctionne comme le fichier /etc/mail/aliases :

heros@chezmoi.tld batman@chezmoi.tld,superman@chezmoi.tld
batman@chezmoi.tld _vmail
superman@chezmoi.tld _vmail
kiki@chezmoi.tld _vmail

Eh oui, toutes ces adresses vont pour l'utilisateur _vmail.

Notez que sur la première ligne, on a fait un alias.

6.4.1.3. /etc/mail/passwd

Même logique ici, une ligne pour un mot de passe :

batman@$NDD:$2b$09$lerdFpdQtnu.Bs5EpAsVbeF851GjdD0aza8IDhho38i1DOHk.ujzi::::::
superman@$NDD:$2b$09$VRU/CYJUS3QZHVUFP70xIOURPbiNQeyOEZHoZo6NOY3uO.XSpd2MW::::::

Chaque ligne est constituée des éléments suivants, séparés par des : :

  • L'adresse mail du compte ;
  • Le mot de passe chiffré ;
  • Des options. Dans cet exemple, on n'en a pas précisé, il y a donc 6 : en fin de ligne.

Afin de chiffrer le mot de passe, utilisez la commande encrypt ainsi :

encrypt -p

Ça vous demande d'entrer le mot de passe. Lorsque vous validez avec "Entrée", un hash du mot de passe s'affiche, il reste à le mettre dans /etc/mail/passwd.

6.4.1.4. Permissions des fichiers d'identification

Les fichiers précédents ne doivent pas être lisibles par un simple utilisateur de passage. Faisons en sorte que seul l'administrateur (root) puisse écrire dedans et rendons-les lisible par les démons qui en auront besoin : dovecot et smtpd. Ce n'est pas une obligation, mais c'est une précaution qui ne peut blesser personne 😉.

Afin de séparer les privilèges, dovecot et smtpd fonctionnent à partir d'utilisateurs aux accès restreints, respectivement _smtpd et _dovecot. Tout ceci permet de protéger votre serveur si un jour, l'un de ces services était compromis.

Nous allons créer un groupe _maildaemons dans lequel nous mettrons les deux utilisateurs cités ci-dessus afin de faciliter la gestion des permissions :

# groupadd _maildaemons
# usermod -G _maildaemons _smtpd
# usermod -G _maildaemons _dovecot

dovecot n'est peut-être pas installé à ce stade de la lecture, installez-le avant la dernière commande : # pkg_add dovecot.

On définit maintenant le propriétaire et le groupe des fichiers contenant les mots de passe et identifiants :

# chown root:_maildaemons /etc/mail/passwd /etc/mail/virtuals

Enfin, on ne permet qu'à root d'écrire dans ces fichiers et au groupe _maildaemons d'en lire le contenu :

# chmod 640 /etc/mail/passwd /etc/mail/virtuals

Si vous vérifiez, vous voyez que les permissions et propriétaires sont corrects :

# ls -l /etc/mail/passwd
-rw-r-----  1 root  _maildaemons  17226 Nov 12 08:40 /etc/mail/passwd

6.4.2. Configuration d'Opensmtpd

Opensmtpd (smtpd) est le serveur mail par défaut sur OpenBSD. Il est déjà installé, reste à le configurer.

Cependant, avant toutes choses, ouvrez et redirigez les ports suivants : 25 (smtp), 587 (submission) et 993 (imaps). Nous ne préoccupons pas du port 465 (smtps) car il est déprécié.

Pour configurer opensmtpd, on édite /etc/mail/smtpd.conf. Ce dernier sera mis en œuvre dans l'ordre de lecture.

Ce dernier se décompose en 3 parties :

  • Les options générales du serveur ;
  • Les actions qui pourront être réalisées sur les mails, qu'on appelle "enveloppes" ;
  • Les critères pour reconnaître les enveloppes et y appliquer les actions qui correspondent.

Le voici, à adapter à vos besoins :

# Configuration generale
## Tables 
table aliases file:/etc/mail/aliases
table passwd passwd:/etc/mail/passwd
table virtuals file:/etc/mail/virtuals

## Certificats
pki chezmoi.tld key "/etc/ssl/private/chezmoi.tld.key"
pki chezmoi.tld cert "/etc/ssl/chezmoi.tld-fullchain.pem"

## Ecoute pour recevoir/envoyer
### Messages locaux
listen on lo0 
### Reception
listen on egress tls pki chezmoi.tld 
### Envoi avec client de messagerie
listen on egress port submission tls-require pki chezmoi.tld auth <passwd> 

# ACTIONS 
action "envoi" relay 
action local_maildir mbox alias <aliases>
action virtual_maildir maildir "/var/vmail/%{dest.domain}/%{dest.user}/Maildir" virtual <virtuals>

# Correspondances
## Reception
### Message pour les utilisateurs locaux
match for local action local_maildir
### Message pour les utilisateurs virtuels
match from any for domain chezmoi.tld action virtual_maildir

## Envoi
match auth from any for any action "envoi"
match for any action "envoi"

Vous n'avez quasiment rien à modifier dans ce fichier, mis à part chezmoi.tld à remplacer par votre nom de domaine.

STOOOP! On veut des détails!

Regardons les lignes de ce fichier les unes après les autres.

Tous d'abord, les premières lignes correspondent à des options générales.

  • table aliases … : On précise dans quel fichier se trouvent les alias entre les utilisateurs. Ce fichier permet de faire suivre des messages.
  • table passwd … : On définit le fichier contenant les mots de passe chiffrés qu'on a créés auparavant.
  • table virtuals … : Le fichier contenant la liste des utilisateurs virtuels.
  • pki … : On indique où se trouve la clé et le certificat correspondant servant à identifier le serveur. Modifiez les emplacements selon ce que vous avez obtenu dans le paragraphe sur la gestion des certificats.
  • listen on lo0 : le serveur mail va écouter en local au cas où le système envoie des messages.
  • listen on egress tls pki chezmoi.tld : smtpd écoute (sur le port 25) pour recevoir des courriels d'autres serveurs. Ici, la connexion profite du chiffrement tls si possible en utilisant le certificat configuré plus haut, repéré par son nom de domaine.
  • listen on egress port submission tls-require pki chezmoi.tld auth <passwd> : Cette ligne indique que le serveur écoute sur le port submission avec indispensablement une connexion chiffrée en tls (tls-require). Aussitôt, celui qui se connecte sur ce port doit s'identifier (auth) par rapport au contenu de la teble <passwd>. Cette ligne permet à un utilisateur virtuel de se servir d'un client de messagerie pour envoyer des courriels à partir de son ordinateur.

Ensuite, sont définies quelques actions qui seront appliquées ensuite aux mails. Il peut s'agir d'envoyer un courriel à l'extérieur ou bien de distribuer une enveloppe à un utilisateur du serveur.

  • action "envoi" relay : le serveur relaie l'enveloppe. Dit plus simplement, il l'envoit à l'adresse écrite dessus, au serveur mail SMTP du destinataire.
  • action local_mbox mbox alias <aliases> : On distribue l'enveloppe dans une boîte de type mbox d'après la table de correspondance <aliases>. C'est utile pour les messages internes au système.
  • action virtual_maildir maildir "/var/vmail/%{dest.domain}/%{dest.user}/Maildir" virtual <virtuals> : Dans cette action, on distribue une enveloppe dans un dossier de type maildir selon la table des utilisateurs virtuels. Remarquez que le chemin de la boîte maildir est précisé de façon à correspondre au dossier indiqué plus haut.

Enfin, on regarde si on doit envoyer un message ou le délivrer pour appliquer les actions définies.

Notez que si rien n'est précisé, on considère que la règle s'applique pour un message venant du serveur : le from local est sous-entendu. Sinon, from any permet d'envoyer un message à partir de votre ordinateur, en passant par le serveur.

  • match for local action local_mbox : on délivre les messages système.
  • match from any for domain chezmoi.tld action virtual_maildir : si le message vient de l'extérieur et est pour le nom de domaine du serveur, on le distribue aux utilisateurs virtuels.
  • match auth from any for any action "envoi" : lorsqu'un message provient d'un client extérieur au serveur et authentifié avec son mot de passe (avec votre client de messagerie par exemple), on envoie le message.
  • match for any action "envoi" : si les messages provenant de l'intérieur du serveur doivent en sortie, on les envoie.

Nous passons maintenant à une étape simple mais importante afin que les mails soient correctement émis. Il faut indiquer dans le fichier /etc/myname votre nom de domaine sur une seule ligne. Il s'agit du domaine que vous avez indiqué dans le champ MX de votre zone DNS :

chezmoi.tld

Nous pouvons maintenant activer et relancer le serveur smtpd :

# rcctl enable smtpd
# rcctl restart smtpd

Voilà pour opensmtpd 😁.

6.4.3. Dovecot pour l'IMAP

Dovecot va être utilisé comme serveur IMAP, afin de pouvoir récupérer son courrier à partir d'un client comme Thunderbird.

On installe dovecot comme d'habitude :

# pkg_add dovecot

On édite maintenant le fichier /etc/dovecot/local.conf pour y mettre le contenu suivant :

# On écoute en IPV4 et IPV6.
listen = *, [::]

# imap > pop
protocols = imap

# Securisation. Editez ces lignes
ssl = yes
ssl_cert = </etc/ssl/chezmoi.tld-fullchain.pem
ssl_key = </etc/ssl/private/chezmoi.tld.key
disable_plaintext_auth = yes

# tres important comme on a modifie les permissions
# sur /etc/mail/passwd
service auth {
    user = $default_internal_user
    group = _maildaemons
}

# methodes d'authentification
passdb {
    args = scheme=blf-crypt /etc/mail/passwd
    driver = passwd-file
}

# Les messages sont dans /var/vmail et appartiennent à _vmail
userdb {
    driver = static
    args = uid=_vmail gid=_vmail home=/var/vmail/%d/%n/ 
}

L'exemple ci-dessus est commenté pour vous aider à comprendre ce qui y est fait.

Pensez à adapter l'emplacement des certificats aux variables ssl_cert et ssl_key. Chaque section est commentée pour que vous compreniez à quoi elles servent.

Par ailleurs, une configuration ssl est déjà pré-configurée dans le fichier /etc/dovecot/conf.d/10-ssl.conf. C'est censé nous faciliter la vie avec un script qui génère un certificat auto-signé, mais comme on a déjà nos certificats et configuré cette partie, il risque de ne pas trop aimer. Dans ce fichier, commentez donc toutes les lignes restantes :

## Fichier /etc/dovecot/conf.d/10-ssl.conf
#ssl_cert = </etc/ssl/dovecotcert.pem
#ssl_key = </etc/ssl/private/dovecot.pem

Afin que dovecot fonctionne correctement, il faut maintenant éditer le fichier /etc/login.conf pour ajouter quelques lignes : (voir le fichier /usr/local/share/doc/pkg-readmes/dovecot*)

dovecot:\
    :openfiles-cur=512:\
    :openfiles-max=2048:\
    :tc=daemon:

On prend en compte les changements récents sur ce fichier avec la commande suivante :

# [ -f /etc/login.conf.db ] && cap_mkdb /etc/login.conf

Pour terminer cette partie, on active dovecot et on relance les différents éléments constituant le serveur mail.

# rcctl enable dovecot
# rcctl start dovecot
# rcctl restart smtpd

Il vous est désormais possible d'utiliser un client de messagerie afin de consulter votre courrier.

6.4.4. Ajouter un nouveau compte mail

Vous devez remplir les fichiers /etc/mail/virtuals et /etc/mail/passwd avec une ligne en plus. Ensuite, lancez les commandes suivantes pour que smtpd prenne vos changements en compte :

smtpctl update table virtuals
smtpctl update table passwd

Ou alors, relancez smtpd avec rcctl.

6.5. Redirection de mail

Il est simplissime de transférer les mails reçus sur une adresse vers un autre compte de messagerie.

Par exemple, vous disposez d'une adresse bibi@chezmoi.tld et souhaitez que tous les messages reçus par bibi soient transférés automatiquement à jean-eudes@ouaf.xyz.

Pour ça, il suffit d'éditer le fichier /etc/mail/virtuals, puis d'y ajouter une ligne comme celle-ci :

bibichezmoi.tld: jean-eudes@ouaf.xyz

Dans le fichier /etc/mail/aliases, vous pouvez aussi faire des redirections avec les utilisateurs du serveur, très utile pour l'adminstration système. On peut dans ce cas ne spécifier que le nom d'utilisateur.

root: jean
hostmaster: root
postmaster: root
webmaster:  arthur
jean: toto@serveurmail.net

De façon générale, ça donne :

utilisateur: adresse1.mail.com, adresse2.mail.com

Afin que ce changement soit pris en compte, il reste à lancer la commande suivante :

# rcctl restart smtpd

C'est tout! Je vous l'avais dit que c'était simple.

6.6. Configurer son client de messagerie

Pour consulter vos mails sur le serveur, vous pouvez utiliser un client de messagerie comme l'excellent Thunderbird, logiciel-libre respectueux de votre vie privée.

Voici les paramètres qu'il faudra indiquer au logiciel pour envoyer et recevoir des courriels. Notez que tous ne vous seront peut-être pas demandés :

  • Nom du serveur : chezmoi.tld
  • Adresse électronique : toto@chezmoi.tld
  • Nom d'utilisateur : l'adresse mail complète indiquée dans /etc/mail/virtuals
  • Serveur entrant : IMAP
    • port : 993
    • SSL : SSL/TLS
  • Serveur sortant : SMTP
    • port : 587
    • SSL : STARTTLS

Vous souhaiterez peut-être plutôt utiliser un webmail, afin d'accéder à votre messagerie à partir d'un navigateur web.

6.6.1. Enregistrements DNS facultatifs pour clients

Pour simplifier la configuration des clients de messagerie, vous pouvez ajouter dans votre zone DNS les enregistrements suivants, compris par la plupart des logiciels existants :

_submission._tcp.example.com	86400	IN	SRV	0 1 587	chezmoi.tld
_imap._tcp.example.com		86400	IN	SRV	0 0 0	.
_imaps._tcp.example.com		86400	IN	SRV	0 1 993	chezmoi.tld

6.7. Ne pas perdre de messages : MX

Il est possible que des mails n'arrive pas à votre serveur si votre serveur est hors-ligne pendant plus d'une semaine. Normalement, tous les serveurs de messagerie tenteront de renvoyer un mail qui n'a pas pu être délivré.

Cependant, c'est plus rassurant de prévoir le coup en configurant une solution de secours. Il vous faut pour cela :

  • Un second serveur (ahem… 😕)
  • Ou un ami avec un serveur 😁

Ce serveur gardera vos messages en file d'attente le temps que le vôtre redevienne disponible.

De votre côté, il vous suffit d'ajouter à votre zone un nouveau champ MX avec un "poids" plus élevé que le vôtre. Ce champ pointe vers le serveur secondaire :

@                     IN MX 10  chezmoi.tld.
@                     IN MX 70  mail.copain.eu.

Dans l'exemple ci-dessus, votre serveur a un poids inférieur (10) que celui de du serveur secondaire (70). Ce dernier sera utilisé si le premier n'est pas disponible.

De son côté, votre ami, pour peu qu'il utilise lui aussi opensmtpd n'aura qu'à ajouter les lignes suivantes à son /etc/mail/smtpd.conf afin de se constituer serveur mail de secours :

action relaybackup relay backup helo "chezmoi.tld"
…
match from any for domain chezmoi.tld action relaybackup

L'idéal, c'est de lui rendre la pareille 😉.

6.8. Ne pas être mis dans les spams

En l'état, vous pouvez recevoir et envoyer des messages. Cependant, il se peut que certains serveurs de messagerie considèrent vos mails comme des spams. Heureusement, il existe quelques petites manipulations pour rendre vos messages légitimes. Nous allons les détailler dans les paragraphes suivants. Gardez à l'esprit qu'elles se complètent sans se suffire à elles-mêmes.

6.8.1. Reverse DNS

Chez votre Fournisseur d'Accès à internet, cherchez les options correspondant à votre adresse IP. Vous pourrez configurer un reverse DNS ou en français DNS inverse.

Alors que votre nom de domaine est relié à l'IP du serveur, il faut aussi configurer la réciproque, c'est-à-dire relier à votre IP le nom de domaine.

Un petit mail à votre fournisseur permettra de savoir comment s'y prendre si vous ne trouvez pas 😉.

Si vous ne pouvez pas faire cette manipulation, ce n'est pas une catastrophe, du moment que vous pouvez mettre en place SPF et DKIM (voir paragraphes suivants).

6.8.2. SPF

Ajoutez un champ DNS de type SPF dans votre zone DNS qui correspond au champ A utilisé pour vos mails (chez votre registrar ou sur votre serveur de noms si vous l'hébergez aussi) tel que celui-ci :

chezmoi.tld.   SPF "v=spf1 a mx ~all"

ou bien sous forme de champ TXT si le SPF n'est pas disponible :

chezmoi.tld. TXT "v=spf1 a mx ~all"

6.8.3. Signature DKIM

Cette technique consiste à signer les messages émis par le serveur à l'aide d'une clé privée. On ajoute ensuite dans un champ DNS la clé publique correspondante qui permettra au destinataire de vérifier que le mail reçu provient bien de votre serveur.

Moi pas compris!

Je reprends. Nous allons créer une clé privée et une clé publique.

La clé privée servira à signer les messages. On l'appelle "privée" car vous devez être la seule personne capable de signer (comme pour vos chèques ou vos impôts). La clé publique est là pour vérifier que la signature est bien authentique. On peut voir ça comme une pièce de puzzle unique, qui est la seule à pouvoir entrer dans l'empreinte créée par la signature.

On installe dkimproxy comme d'habitude :

# pkg_add dkimproxy

6.8.3.1. Génération des clefs OpenSSL

Les commandes suivantes permettent de fabriquer la paire de clés qui servira à signer les mails émis :

  1. Création du dossier pour les clefs
    # mkdir -p /etc/dkimproxy/private                    
    

  2. On protège le dossier
    # chown _dkimproxy:wheel /etc/dkimproxy/private 
    

  3. On modifie les permissions
    # chmod 700 /etc/dkimproxy/private                   
    

  4. On va dans le dossier
    # cd /etc/dkimproxy/private                          
    

  5. On génère les clefs
    # openssl genrsa -out private.key 1024               
    # openssl rsa -in private.key -pubout -out public.key
    

  6. On protège les clefs
    # chown _dkimproxy:wheel private.key public.key      
    # chmod 400 private.key
    

6.8.3.2. Configuration DKIM

Afin de configurer la signature des messages envoyés, il faut éditer le ficher /etc/dkimproxy_out.conf ainsi :

listen    127.0.0.1:10027
relay     127.0.0.1:10028
domain    chezmoi.tld
signature dkim(c=relaxed)
signature domainkeys(c=nofws)
keyfile   /etc/dkimproxy/private/private.key
selector  pubkey
Euh, c'est quoi tout ça?

Quelques menues explications :

  • Les lignes listen et relay indiquent l'adresse avec le port où dkimproxy recevra respectivement les mails à chiffrer et où il les fera suivre. Tout se passe dans votre serveur, donc à l'adresse 127.0.0.1.
  • domain décrit votre nom de domaine : à modifier selon votre cas.
  • keyfile permet d'indiquer où se trouve le chemin vers la clé servant à signer les mails.
  • selector définit l'identifiant qui sera présent dans le champ DNS que l'on va définir ensuite.

Bien, reste à indiquer à opensmtpd de signer les mails. On va donc ajouter dans le fichier /etc/mail/smtpd.conf une ligne pour écouter sur le port 10028 en local, afin d'envoyer les mails que dkimproxy aura signé. On leur colle l'étiquette "DKIM" pour les repérer ensuite.

listen on lo0 port 10028 tag DKIM   

Les messages qui auront l'étiquette "DKIM" peuvent être envoyés. On n'envoie plus les mails s'ils ne sont pas passés par dkimproxy.

match tag DKIM for any action "envoi"
match auth tag DKIM from any for any action "envoi"

Enfin, les messages pas encore signés doivent être envoyés à dkimproxy. On définit l'action correspondante :

action dkimproxy relay host smtp://127.0.0.1:10027 

S'ensuit les règles de correspondance qui vont bien, à placer à la fin du fichier smtpd.conf:

match auth from any for any action dkimproxy
match for any action dkimproxy

Le fichier /etc/mail/smtpd.conf ressemble désormais à ça :

# Configuration generale
## Tables 
table aliases file:/etc/mail/aliases
table passwd passwd:/etc/mail/passwd
table virtuals file:/etc/mail/virtuals

## Certificats
pki chezmoi.tld key "/etc/ssl/private/chezmoi.tld.key"
pki chezmoi.tld cert "/etc/ssl/chezmoi.tld-fullchain.pem"

### Ecoute pour messages signes avec dkimproxy
listen on lo0 port 10028 tag DKIM   
### Messages locaux
listen on lo0 

### Reception
listen on egress tls pki chezmoi.tld 
### Envoi avec client de messagerie
listen on egress port submission tls-require pki chezmoi.tld auth <passwd> 


# ACTIONS
action "envoi" relay 
action dkimproxy relay host smtp://127.0.0.1:10027 
action spamassassin relay host smtp://127.0.0.1:10025 

action local_mbox mbox alias <aliases>
action virtual_maildir maildir "/var/vmail/%{dest.domain}/%{dest.user}/Maildir" virtual <virtuals>

# Correspondances
## Reception
### Message pour les utilisateurs locaux qui lisent avec la commande "mail"
match for local action local_mbox
### Message pour les utilisateurs virtuels
match from any for domain "chezmoi.tld" action virtual_maildir

## Envoi
### Mail sortant portant une signature DKIM
match tag DKIM for any action "envoi"
match auth tag DKIM from any for any action "envoi"

### Mail en envoi pas encore signe avec DKIM
match auth from any for any action dkimproxy
match for any action dkimproxy

Ça va? Vous suivez toujours? Je vois à votre regard pétillant que vous attendez la fin avec impatience ! 😁

Courage, c'est presque fini. 😉

6.8.3.3. Enregistrements DNS

Pour terminer, nous allons ajouter un nouveau champ dans vos DNS auprès de votre registrar ou dans votre zone. Eh oui, encore ! On va en réalité indiquer le nécessaire pour pouvoir vérifier la signature des messages qui auront un drapeau "pubkey".

Il s'agira d'un champ DKIM ou TXT selon ce qui est disponible. Remplissez-le ainsi :

  • Nom de domaine : pubkey._domainkey.
  • Contenu : v=DKIM1; k=rsa; p=… Recopiez à la place des points de suspension le contenu du fichier public.key, que vous pouvez afficher avec la commande cat :

    # cat /etc/dkimproxy/private/public.key
    

    Ce qui nous donnera dans la zone DNS votre domaine :

    pubkey._domainkey    IN TXT    ( "v=DKIM1; k=rsa; t=s;p=v+Fb…vhP/oB")
    

6.8.3.4. Gestion du service DKIM

Finalement, activez dkimproxy puis rechargez opensmtpd avant de tester si vous avez réussi à configurer correctement l'envoi de vos mails.

# rcctl enable dkimproxy_out
# rcctl start dkimproxy_out
# rcctl restart smtpd

6.8.3.5. Vérifications

Pour vérifier que vos messages envoyés ne sont pas considérés comme spam, suivez les indications du site mail-tester. Vous allez envoyer un message à l'adresse donnée, et normalement, vous devriez obtenir au moins une note de 8/10 :

Il se peut qu'on vous parle d'un enregistrement dmarc. Libre à vous de l'ajouter à vos DNS, mais ce n'est pas obligatoire. À vrai dire, le score obtenu est déjà meilleur qu'avec nombre de "grands" services de messagerie (testez avec gmail pour rigoler : 6.1/10 lors de mon dernier test…).

6.9. Utiliser un relai SMTP externe

Si votre fournisseur d'accès à internet bloque le port smtp (25), vous serez bien embêtés pour envoyer des messages. Deux solutions s'offrent à vous :

  • Changer de FAI 😁
  • Utiliser un relai smtp externe avec identification. Ce dernier peut relayer les messages envoyés par votre serveur. C'est bien évidemment cette situation que nous allons détailler, notamment grâce à l'aide de l'article de PengouinBSD.

Nous supposerons que vous disposez d'un accès par smtp sur un autre serveur (votre fournisseur de mail habituel). Vous envoyez déjà des courriels avec ce dernier à l'aide d'un identifiant et d'un mot de passe. Mettez ces derniers dans un fichier /etc/mail/secrets sous cette forme :

# echo "id_secret utilisateur:motdepasse" > /etc/mail/secrets

Bien sûr, vous aurez remplacé les éléments suivants :

  • "utilisateur" : Nom d'utilisateur à votre compte mail habituel. C'est souvent votre adresse mail.
  • "motdepasse" : Mot de passe pour vous connecter à votre compte mail habituel.
  • "id_secret" : Il s'agit du nom que vous voulez donner à ce relai. C'est un repère. On se servira de ce nom ensuite pour désigner ce relai afin de ne pas avoir à enregistrer vos identifiants secrets dans le fichier /etc/mail/smtpd.conf qui est lisible par tous les utilisateurs du système.

Avant d'aller plus loin, modifiez les permissions sur ce fichier afin que seul smtpd puisse le lire et root le modifier :

# chmod 640 /etc/mail/secrets
# chown root:_smtpd /etc/mail/secrets

Ensuite, modifiez le ficher /etc/mail/smtpd.conf comme ceci afin d'indiquer d'envoyer les messages à l'aide de ce service externe :

…
table secrets file:/etc/mail/secrets
…
listen on lo0
…

action "relay" relay host smtp+tls://id_secret@smtp.exemple.com \
		auth <secrets> mail-from "@chezmoi.tld"

…
match from any for any action "relay"

Un peu d'explications ne feront pas de mal, surtout pour que vous sachiez quoi modifier :

  • table secrets : On indique où se situe le fichier contenant les identifiants secrets pour joindre le relai smtp définit plus haut.
  • action "relay" relay … : on définit l'action qui permet d'envoyer les mails par le biais du serveur smtp externe qui sert de relai. Il faut ici modifier "id_secret" par le repère définit plus haut. Ainsi, on n'écrit pas directement vos identifiants, c'est plus sûr puisque le fichier /etc/mail/smtpd.conf est lisible par tous les utilisateurs de votre serveur. Vous devez aussi changer le nom de domaine du serveur relai smtp.exemple.com.
  • smtp+tls : il s'agit du protocole utilisé pour communiquer avec le relai. Ça peut être smtp pour une session smtp normale avec STARTTLS si possible, smtp+tls pour une utilisation de STARTTLS obligatoire, smtp+notls si l'identification n'est pas chiffrée ou bien smtps pour une connexion SSL. À vous de choisir ce que votre fournisseur propose (espérons smtp+tls qui est plus sûr).
  • auth <secrets> : on utilise la table contenant les identifiants secrets.
  • mail-from "@chezmoi.tld" : On précise le nom de domaine de votre serveur pour que le courriel soit bien marqué comme venant de votre serveur et non du relai.

Pour finir, rechargez smtpd pour profiter de cette nouvelle configuration :

rcctl restart smtpd

Pour un autre exemple, vous pouvez consulter le fil de discussion sur obsd4a.net ou encore le manuel de configuration pour smtpd.

6.10. Installer un antispam

Votre serveur n'est actuellement pas à l'abri des spams. Il existe plusieurs façons pour lutter contre ces nuisances. Nous allons commencer par étudier une méthode simple avec spamassassin pour s'en protéger.

Notez qu'il existe des techniques plus efficaces mais plus difficiles à mettre en place puisque les gros fournisseurs de messagerie disposent de nombreuses adresses IP. Pour ceux que le sujet intéresse, vous pouvez consulter la documentation de spamd et de bgpd. Nous en parlerons rapidement dans un second temps.

D'autres programmes très complets pour lutter contre le spam existent comme rspamd si vous souhaitez vous renseigner.

Houla, ça fait beaucoup pour faire la même chose !

Pour ma part, je trouve rassurant de lire que l'équipe OpenBSD utilise spamassasin et spamd pour protéger ses listes de diffusion.

Ça tombe bien, ce sont les deux outils détaillés dans ce manuel 😁.

6.10.1. Spamassassin

Nous allons faire simple et nous appuyer sur l'excellent spamassassin. Notez qu'avec ce dernier, j'ai dû recevoir une dizaine de spams au début le temps qu'il s'entraîne. Il a très vite appris et ces gêneurs arrivent désormais en quantité homéopathique.

C'est parti, on commence par installer les paquets utiles :

# pkg_add p5-Mail-SpamAssassin spampd

Pour que spampd puisse faire le lien entre le serveur smtpd et spamassassin qui vérifie les messages, il doit tourner en arrière-plan. On active donc ce service :

# rcctl enable spampd

Vous pouvez préciser certaines options pour spampd afin d'être sûr qu'il fonctionne comme prévu :

# rcctl set spampd flags "--relayhost=127.0.0.1:10026"

Ensuite, on démarre le service :

# rcctl start spampd

Il en va de même pour spamassassin qui doit être actif :

# rcctl enable spamassassin
# rcctl start spamassassin

Nous allons maintenant faire passer tous les messages entrants par spamassassin qui va les vérifier. Pour cela, il faut les envoyer sur le port 10025. S'il ne s'agit pas de spam, alors spampd se charge de les renvoyer sur le port 10026. Tous les messages arrivant ainsi recevront l'étiquette "SPAMASSASSIN", pour que l'on sache qu'il faut les distribuer.

Voici donc les lignes à ajouter au fichier /etc/mail/smtpd.conf :

…
# Messages verifies par spamassassin
listen on lo0 port 10026 tag SPAMASSASSIN
…
action spamassassin relay host smtp://127.0.0.1:10025 
…
# Message venant du système
accept from local for local alias <aliases> deliver to maildir "~/Maildir"
# Message SPAMASSASSIN
match tag SPAMASSASSIN from any for domain "chezmoi.tld" action virtual_maildir
### Messages a faire verifier par spamassassin
match from any for domain "chezmoi.tld" action spamassassin
…

Référez-vous à l'exemple plus complet à la fin du document si vous le souhaitez pour bien comprendre comment les choses fonctionnent.

Actuellement, spamassassin modifie le sujet des mails spams en indiquant clairement leur nature. Vous pouvez modifier la configuration de spamassassin pour que les spams soient directement supprimés mais c'est déconseillé en cas de faux positifs.

Spamassassin ajoute un entête "X-spam" aux messages indésirables. On va modifier l'action de distribution pour ajouter le mot-clé "junk" afin que ces messages soient automatiquement classés dans le dossier des spams lorsqu'ils seront livrés :

# Dans /etc/mail/smtpd.conf
action virtual_maildir maildir "/var/vmail/%{dest.domain}/%{dest.user}/Maildir" junk virtual <virtuals>

À ce point du document, le serveur smtp fonctionne ainsi :

6.10.2. Gestion des spams et dovecot

On peut laisser l'antispam faire son travail tranquille dans son coin. Toutefois, c'est intéressant de lui indiquer les quelques mails indésirables qu'il a pu laisser passer afin qu'il apprenne et devienne de plus en plus efficace.

Si vous utilisez dovecot afin de consulter vos messages avec un client IMAP, il est possible de marquer comme spam les messages que vous déplacez dans le dossier "Junk" (par exemple). De la même façon vous pouvez marquer un message comme légitime si vous le retirez du dossier "Junk".

Notez que cette fonctionnalité pourra être mise en place quel que soit l'antispam que vous utilisez.

L'installation va se dérouler en trois étapes :

  1. Installation du plugin.
  2. Activation et configuration du plugin.
  3. Création des scripts d'apprentissage relatifs à chaque antispam.

Tout ceci est décrit dans la documentation de dovecot

Pour configurer dovecot de cette façon, nous commençons par installer le plugin pigeonhole qui donnera accès à sieve.

# pkg_add dovecot-pigeonhole

On active ce plugin en ajoutant les lignes suivantes à la fin du fichier /etc/dovecot/local.conf:

protocol imap {
  mail_plugins = $mail_plugins imap_sieve
}

Enfin, toujours dans le même fichier, on configure ce plugin :

plugin {
  sieve_plugins = sieve_imapsieve sieve_extprograms

  # De n'importe ou vers le dossier spam
  imapsieve_mailbox1_name = Junk
  imapsieve_mailbox1_causes = COPY
  imapsieve_mailbox1_before = file:/usr/local/lib/dovecot/sieve/report-spam.sieve

  # Du dossier des spams vers n'importe ou
  imapsieve_mailbox2_name = *
  imapsieve_mailbox2_from = Junk
  imapsieve_mailbox2_causes = COPY
  imapsieve_mailbox2_before = file:/usr/local/lib/dovecot/sieve/report-ham.sieve

  sieve_pipe_bin_dir = /usr/local/lib/dovecot/sieve

  sieve_global_extensions = +vnd.dovecot.pipe +vnd.dovecot.execute
}

On crée maintenant deux fichiers dans le dossier /usr/local/lib/dovecot/sieve/.

  • Le premier s'appelle report-spam.sieve:

    require ["vnd.dovecot.pipe", "copy", "imapsieve", "environment", "variables"];
    
    if environment :matches "imap.user" "*" {
      set "username" "${1}";
    }
    
    pipe :copy "sa-learn-spam.sh" [ "${username}" ];
    

  • Le second s'appelle report-ham.sieve

    require ["vnd.dovecot.pipe", "copy", "imapsieve", "environment", "variables"];
    
    if environment :matches "imap.mailbox" "*" {
      set "mailbox" "${1}";
    }
    
    if string "${mailbox}" "Trash" {
      stop;
    }
    
    if environment :matches "imap.user" "*" {
      set "username" "${1}";
    }
    
    pipe :copy "sa-learn-ham.sh" [ "${username}" ];
    

On fait maintenant en sorte que sieve tienne compte de ces fichiers. Avant tout, il faut recharger dovecot :

# rcctl restart dovecot

Ensuite, compilez les scripts sieve :

sievec /usr/local/lib/dovecot/sieve/report-spam.sieve
sievec /usr/local/lib/dovecot/sieve/report-ham.sieve

Ces deux fichiers font appel à deux scripts : sa-learn-spam.sh et sa-learn-ham.sh. Le contenu de ces derniers va dépendre de l'antispam que vous utilisez. Ils serviront à apprendre à votre antispam si un message est légitime ou non. Lisez la suite pour terminer.

6.10.2.1. Scripts d'apprentissage pour spamassassin

Puisque nous utilisons spamassassin dans ce guide, voici comment remplir les scripts d'apprentissages pour ce dernier. Nous mettrons ces scripts dans le dossier /usr/local/lib/dovecot/sieve.

Voici le contenu du fichier sa-learn-spam.sh

#!/bin/sh
if [ $# -eq 1 ]; then
    /usr/local/bin/spamc -u ${1} -L spam -C report
fi
exit 0

Et ensuite le contenu du fichier sa-learn-ham.sh

#!/bin/sh
if [ $# -eq 1 ]; then
    /usr/loca/bin/spamc -u ${1} -L ham -C report
fi
exit 0

Afin que ces scripts puissent être lancés, rendez-les exécutables avec cette commande :

# chmod +x /usr/local/lib/dovecot/sieve/sa-learn-*.sh

Pour terminer, n'oubliez pas de recharger dovecot :

# rcctl reload dovecot

Et voilà, désormais, les scripts d'apprentissages seront appelés selon le dossier dans lequel les utilisateurs déplaceront les mails. Si vous souhaitez en savoir plus, vous pouvez lire cette page.

6.10.2.2. Filtrer les messages. Exemple : ranger les spams reçus dans Junk

Indiquer qu'un message reçu est un spam, c'est bien. Le ranger directement dans le dossier des spams (Junk), c'est mieux. On le fait déjà grâce à opensmtpd et le mot clé "junk" dans /etc/mail/smtpd.conf. Cette partie n'est donc qu'un exemple sur lequel vous appuyer. Apprenez-en plus sur le wiki de dovecot sur le tri des messages avec sieve.

C'est très facile à mettre en place avec dovecot et sieve. Il faut juste que ce soit dovecot plutot que smtpd qui se charge de la livraison des mails afin qu'il puisse vérifier si un entête "X-Spam-Status = YES" est présent dans le message. C'est ainsi que spamassassin indique la nature d'un spam, d'autres antispams comme rspamd indiquent un autre entête ("X-Spam" en l'occurrence).

Pour que la livraison passe donc par dovecot, modifiez le fichier /etc/mail/smtpd.conf afin d'indiquer une action "lmtp" :

…
action lmtpdelivery lmtp "/var/dovecot/lmtp" rcpt-to virtual <virtuals>
…
# Les messages scannes par spamassassin sont envoyes a dovecot
match tag SPAMASSASSIN from any for domain <domains> action lmtpdelivery
…

Avant de recharger smtpd, on indique certains éléments à dovecot en éditant le fichier /etc/dovecot/local.conf :

  • Gestion du protocole lmtp : protocols = imap lmtp
  • Emplacement des dossiers Maildir (avant, c'était indiqué dans le fichier smtpd.conf dans l'action virtual_maildir si vous voulez vérifier) mail_location = maildir:/var/vmail/%d/%n/Maildir

Ensuite, on configure la partie concernant sieve afin qu'il trie les mails détectés comme spam au travers d'un script /usr/local/lib/dovecot/sieve/default.sieve :

protocol lmtp {
    mail_plugins = $mail_plugins sieve
}

plugin {
    sieve_default = /usr/local/lib/dovecot/sieve/default.sieve
}

Enfin, remplissez le fichier /usr/local/lib/dovecot/sieve/default.sieve ainsi :

require "fileinto";
if header :contains "X-Spam-Flag" "YES" {
  fileinto "Junk";
}

Vous pouvez désormais relancer smtpd et dovecot :

# rcctl restart dovecot smtpd

Et voilà, les mails sont directement triés.

6.10.3. Antispam avec spamd

Spamd fait semblant d'être un serveur mail afin de filtrer les spams et embêter les spammeurs. Il a été écrit dans l'optique d'être très efficace et ne pas ralentir la machine. Bien sûr, il transmet les mails légitimes au serveur smtpd ensuite.

Ce qui est rigolo, c'est qu'il va faire en sorte de ralentir les spammeurs en communiquant tout doucement avec eux et leur faire consommer inutilement leur ressources 😁 .

Enfin, avantage non négligeable, il est présent par défaut dans OpenBSD.

N'hésitez pas à consulter l'exemple de configuration.

6.10.3.1. Comment ça marche?

Deux méthodes sont possibles et compatibles. La première consiste à laisser traîner sur le web une fausse adresse mail. Tous les messages envoyés à cette adresse sont émis par des robots spammeurs : l'origine de ces derniers est alors mise sur liste noire.

L'autre méthode est le "greylisting". Afin de reconnaître les pourriels, spamd va mettre en attente ceux qui contactent le serveur. Ils sont mis sur liste grise.

Normalement, un serveur expéditeur légitime réessaie automatiquement de délivrer le message après un certain temps. Lors du 2e essai, ce serveur est mis sur liste blanche et le message est correctement distribué.

Les spammeurs ne vont pas réessayer de délivrer le message. Dans ce cas, ils seront oubliés après un délai assez long, et vous n'aurez pas reçu le spam.

Attention : Cette méthode, bien que très efficace, suppose que l'expéditeur fait les choses comme il faut. Ce n'est malheureusement pas toujours le cas, notamment pour certains sites marchands. Pensez-y. C'est heureusement facile d'ajouter un serveur sur liste blanche. Vous devriez de toute manière utiliser une adresse poubelle comme guerrilamail dans ces cas de figure.

Afin d'enregistrer les vilains expéditeurs, il faudra exécuter la commande spamd-setup régulièrement.

6.10.3.2. Mise en place

On commence par activer spamd au démarrage, en indiquant les options dont il aura besoin, puis on le lance :

# rcctl enable spamd
# rcctl set spamd flags "-v -G 25:4:864"
# rcctl start spamd

Le premier chiffre correspond au nombre de minutes qu'un expéditeur doit attendre avant de réessayer de nous renvoyer son mail (puisque les spammeurs envoient des salves de mails très rapidement). Le second correspond au temps qu'une entrée reste dans la liste grise, et le dernier le temps pendant lequel une entrée restera sur la liste blanche (en heures).

En complément, je vous invite à activer spamlogd qui gardera en mémoire les expéditeurs légitimes de mail dans le temps sans repasser par la case "liste grise", tant que ces derniers envoient des mails régulièrement. Il enregistre aussi sur liste blanche les serveurs auxquels vous envoyez des messages. Attention, il faut bien avoir précisé le mot clé "log" dans la configuration du parefeu, comme précisé un peu plus loin.

# rcctl enable spamlogd
# rcctl start spamlogd

spamd se place juste avant smtpd. On va éditer la configuration du parefeu en conséquence. Il va envoyer à spamd tout le flux destiné au serveur smtp, qui relaiera ensuite le mail normalement s'il est légitime.

Voici ce qu'il faut donc ajouter dans /etc/pf.conf :

table <spamd-white> persist
table <nospamd> persist file "/etc/mail/nospamd"
pass in on egress proto tcp to any port smtp divert-to 127.0.0.1 port spamd
pass in on egress proto tcp from <nospamd> to any port smtp
pass in log on egress proto tcp from <spamd-white> to any port smtp

Dans l'ordre des lignes :

  • On définit la table <spamd-white> qui contient les IP d'expéditeurs connus comme légitimes
  • On crée un fichier /etc/mail/nospamd qui contiendra les IP des expéditeurs légitimes définis par vos soins.
  • On dévie tout ce qui devait arriver sur le port smtp pour aller dans spamd.
  • On laisse passer les IP enregistrées par spamd dans la liste blanche (en mémoire). spamd et pf partagent ici la même table.
  • On laisse passer toutes les IP qui sont dans la table <nospamd> directement.

Voilà pour le parefeu. N'oubliez pas de le recharger :

# pfctl -ef /etc/pf.conf

Il est nécessaire de régulièrement charger la liste noire des spammeurs dans pf afin que spamd fonctionne bien. Nous allons nous servir d'une tâche cron pour ça. Saisissez # crontab -e, puis décommentez la ligne suivante :

0  *  *  *  *  sleep $((RANDOM \% 2048)) && /usr/libexec/spamd-setup

Pour l'édition, référez-vous aux rappels sur l'utilisation de vi.

Nous lançons ici spamd-setup à des intervalles de temps aléatoires, espacés au maximum d'une heure.

6.10.3.3. Piéger les spammeurs

Vous pouvez piéger les spammeurs en laissant traîner sur le web une fausse adresse mail. Si spamd voit un message arriver pour cette adresse, alors il sait déjà que c'est un spam : il peut donc le mettre sur liste noire. Vous voilà protégés pour l'avenir.

Afin de glisser cette "adresse-piège" sur le web sans que ça soit visible par les humains, vous pouvez l'insérer ainsi dans le code html de votre site :

<a href="mailto:piege@chezmoi.tld"></a>

Sinon, copiez-la sur des pastebins publics.

Pour indiquer à spamd cette adresse piège, il faut ajouter les options suivantes à spamdb (attention au "b" final, ce n'est pas spamd). :

# spamdb -T -a 'piege@chezmoi.tld'

Bien entendu, cette adresse piège ne doit pas être créée et ne risque pas de servir à quiconque.

Pour aller plus loin, vous pouvez consulter cette page qui propose une publication automatique de fausses adresses sur des sites publics.

6.10.3.4. Utiliser des listes noires ou blanches pré-existantes

Malgré ce que certains disent, les gens sympas, ça existe ! Ces derniers ont rassemblé une liste de spammeurs qu'ils rendent publique. Afin de les utiliser avec spamd, il faut éditer le fichier /etc/mail/spamd.conf.

Voyons l'exemple par défaut livré de base : la liste nixspam.

Dans le fichier /etc/mail/spamd.conf, nous mettrons les lignes suivantes :

all:\
        :nixspam

# Nixspam recent sources list.
# Mirrored from http://www.heise.de/ix/nixspam
nixspam:\
        :black:\
        :msg="Your address %A is in the nixspam list\n\
        See http://www.heise.de/ix/nixspam/dnsbl_en/ for details":\
        :method=http:\
        :file=www.openbsd.org/spamd/nixspam.gz

Au début du fichier, vous lisez all. Précisez ensuite le nom des listes qui sont configurées en-dessous en les séparant par des ":". Nous allons en ajouter dans les paragraphes suivants.

Les listes peuvent être récupérées directement en précisant leur URL, ou bien être des fichiers présents sur votre serveur.

6.10.3.4.1. Utiliser la liste noire de bsdly

Peter N.M.Hansteen publie une liste d'IP piégées avec ses propres SPAMTRAPS.

Il met sur liste noire les IP cherchant à télécharger trop souvent sa liste pour éviter les surcharges sur son serveur. On va donc les récupérer régulièrement en ajoutant à votre crontab, toutes les heures à 20 minutes passées :

20 * * * *   /usr/local/sbin/bsdly-spamd

Le script bsdly-spamd ne fait que récupérer la liste de Peter :

#!/bin/sh
# update bsdly.net traplist into DST
URL="https://www.bsdly.net/~peter/bsdly.net.traplist"
# alternative URL
#URL="https://home.nuug.no/~peter/bsdly.net.traplist"
DST=/var/db/bsdly.traplist

ftp -o "${DST}" "${URL}"

Ensuite, indiquez dans /etc/mail/spamd.conf d'ajouter le contenu du fichier /var/db/bsdly.traplist à la liste noire :

all:\
		:nixspam:bgp-spamd:bsdlyblack:

nixspam:\
		:black:\
		:msg="Your address %A is in the nixspam list\n\
		See http://www.heise.de/ix/nixspam/dnsbl_en/ for details":\
		:method=https:\
		:file=www.openbsd.org/spamd/nixspam.gz

bsdlyblack:\
		:black:\
		:msg="SPAM.  Your address %A has sent spam within the last 24 hours.  See http://www.bsdly.net/~peter/traplist.shtml for details.":\
		:method=file:\
		:file=/var/db/bsdly.traplist
6.10.3.4.2. Utiliser les listes noire et blanches de uceprotect

Le site uceprotect devrait vous plaire si vous n'aimez par les spams. Ils proposent des listes d'IP mises à jour toutes les heures. Il est possible de récupérer les listes en entier comme on l'a fait avec bsdly.net.traplist, mais cela consommera moins de bande passante de ne récupérer que les changements avec rsync. C'est mieux pour vous et pour uceprotect.

Dans le crontab, on appelle le script qui mettra à jour toutes les heures (Ne mettez pas à jour les listes plus souvent, sinon vous serez bloqués par leur serveur) :

10 * * * *     /usr/local/sbin/uceprotect-spamd 

Le contenu du script uceprotect-spamd est le suivant :

#!/bin/sh

RSYNC="/usr/bin/openrsync -a"
URLS="rsync-mirrors.uceprotect.net::RBLDNSD-ALL/dnsbl-1.uceprotect.net
rsync-mirrors.uceprotect.net::RBLDNSD-ALL/dnsbl-2.uceprotect.net
rsync-mirrors.uceprotect.net::RBLDNSD-ALL/ips.backscatterer.org
rsync-mirrors.uceprotect.net::RBLDNSD-ALL/ips.whitelisted.org"
OUT="/var/db/RBLDNSD-ALL/"
mkdir -p "${OUT}"

for URL in ${URLS}; do
		${RSYNC} "${URL}" "${OUT}"
done

On charge ces listes dans /etc/mail/spamd.conf. Il y a des listes noires et des listes blanches :

all:\
		:nixspam:bgp-spamd:bsdlyblack:\
		rbldnsd-1:rbldnsd-2:rbldnsd-backscatterer:rbldnsd-white:

…

rbldnsd-1:\
		:black:\
		:msg="Your address %A is listed on UCEPROTECT-Level 1\n \
		see http://www.uceprotect.net/en":\
		:method=file:\
		:file=/var/db/RBLDNSD-ALL/dnsbl-1.uceprotect.net

rbldnsd-2:\
		:black:\
		:msg="Your address %A is listed on UCEPROTECT-Level 2\n \
		see http://www.uceprotect.net/en":\
		:method=file:\
		:file=/var/db/RBLDNSD-ALL/dnsbl-2.uceprotect.net

rbldnsd-backscatterer:\
		:black:\
		:msg="Your address %A is listed on www.backscatterer.org":\
		:method=file:\
		:file=/var/db/RBLDNSD-ALL/ips.backscatterer.org

rbldnsd-white:\
		:white:\
		:method=file:\
		:file=/var/db/RBLDNSD-ALL/ips.whitelisted.org

N'hésitez pas à faire un don à uceprotect.net, leur travail est impressionnant.

6.10.3.4.3. Solution communautaire avec bgpd

Vous avez normalement déjà configuré le parefeu pour qu'il laisse passer les IP contenues dans le fichier /etc/mail/nospamd dans le paragraphe sur le greylisting

Cependant, cette précaution peut ne pas toujours suffire. Je vous propose alors de profiter de bgp-spamd. Ce service communautaire propose de récupérer des listes de spammeurs et d'expéditeurs légitimes. Pour l'instant, seuls des serveurs vérifiés et de confiance participent à ce service, mais chacun peut en profiter. Vous serez alors tranquilles pour la plupart des cas.

Il repose sur le service bgpd qui va se charger de récupérer une autre liste d'IP légitimes. On le configure ainsi dans le fichier /etc/bgpd.conf:

spamdAS="65066"

AS 65001
fib-update no                # Mandatory, to not update the local routing table
nexthop qualify via default  # Make sure the nexthop is valid

group "spamd-bgp" {
        remote-as $spamdAS
        multihop 64

	# us.bgp-spamd.net
        neighbor 64.142.121.62

	# eu.bgp-spamd.net
	neighbor 217.31.80.170

	# IPv6 eu.bgp-spamd.net
	neighbor 2a00:15a8:0:100:0:d91f:50aa:1
}

deny to any
deny from any

allow from group "spamd-bgp"
# 'match' is required, to remove entries when routes are withdrawn
# This updates the <bgp-spamd-bypass> table in PF
match from group spamd-bgp community $spamdAS:42  set pftable "bgp-spamd-bypass"

Il y aura dans le groupe spamd-bgp toutes les IP connues comme légitimes. Elles seront ajoutées dans une table pour pf nommée bgp-spamd-bypass.

Il faut donc ajouter ces quelques lignes dans le fichier /etc/pf.conf afin de laisser passer les expéditeurs légitimes :

set limit table-entries 400000    
table <bgp-spamd-bypass> persist

#[…]

# Sous la section concernant spamd
pass in log quick on egress proto tcp from <bgp-spamd-bypass> to any port smtp

Référez-vous à l'exemple de pf.conf à la fin du document en cas de doute.

Relancez le parefeu :

# pfctl -ef /etc/pf.conf

Activez et démarrez maintenant bgpd :

rcctl enable bgpd
rcctl start bgpd

bgpd peut aussi récupérer des listes d'IP de spammeurs. On va donc créer un script qui permettra de les mettre dans un fichier. spamd se chargera de mettre sur liste noire ces IP :

Créez le script /usr/local/sbin/bgp-spamd.black.sh pour y mettre :

#!/bin/sh
AS=65066
bgpctl show rib community ${AS}:666 | \
    awk 'NR>6 {print $3}' > /var/db/spamd.black

/usr/libexec/spamd-setup

Ce script doit être appelé régulièrement. Nous allons utiliser la même technique qu'auparavant, à savoir une tâche cron. Tapez # crontab -e puis remplacez la ligne qui appelait spamd-setup par :

*/10  *  *  *  *  /usr/local/sbin/bgp-spamd.black.sh 
# chmod +x /usr/local/sbin/bgp-spamd.black.sh

Vous noterez que ce script appelle bien spamd-setup.

Nous avons presque terminé, il faut maintenant modifier le fichier de configuration de spamd situé à l'emplacement /etc/mail/spamd.conf :

# Configuration file for spamd.conf

all:\
	:nixspam:bgp-spamd:

# Nixspam recent sources list.
# Mirrored from http://www.heise.de/ix/nixspam
nixspam:\
	:black:\
	:msg="Your address %A is in the nixspam list\n\
	See http://www.heise.de/ix/nixspam/dnsbl_en/ for details":\
	:method=http:\
	:file=www.openbsd.org/spamd/nixspam.gz

bgp-spamd:\
	:black:\
	:msg="Your address %A has sent mail to a spamtrap\n\
	within the last 24 hours":\
	:method=file:\
	:file=/var/db/spamd.black:

6.10.3.5. Problèmes éventuels avec le greylisting

Trop de personnes utilisent encore un fournisseur de mail, comme Gmail. Ces derniers disposent de plusieurs serveurs et donc de plusieurs adresses IP. Malheureusement, le temps que l'adresse IP du premier serveur à tenter l'envoi d'un message soit mise sur liste blanche, c'est un autre de leurs serveurs avec une IP différente qui prend le relais. Au final, ils ne sont jamais mis sur liste blanche.

Ici, nous allons créer une liste des domains pour lesquels on ne veut pas faire de greylisting.

6.10.3.5.1. Liste blanche de fournisseurs habituels

Je vous propose de mettre sur liste blanche les adresses IPs des fournisseurs de mail relativement connus. Depuis qu'OpenBSD est disponible en version 6.3, nous pouvons utiliser la commande smtpctl spf walk très pratique pour récupérer ces informations.

Tout d'abord, on crée un fichier qui contient la liste des domaines à qui on épargne le greylisting. Ce fichier sera /etc/mail/nospamd_domains_list.txt :

gmail.com
hotmail.com
facebookmail.com
apple.com
microsoft.com
lists.openbsd.org
linkedin.com
freebsd.org
twitter.com
amazon.com
yahoo.com
yahoo.fr
live.fr
mail-out.ovh.net
mxb.ovh.net
gandi.net
laposte.net
protonmail.com

Complétez ce fichier à votre guise si vous remarquez que des serveurs restent indéfiniment sur liste grise.

Maintenant, on crée le script /usr/local/sbin/generate-nospamd qui va enregistrer dans le fichier /etc/mail/nospamd les IP des serveurs définis ci-dessus.

#!/bin/sh
# /usr/local/sbin/generate-nospamd
# Auteur :      thuban <prx@ybad.name>
# licence :     MIT

DOMAINS=$(cat /etc/mail/nospamd_domains_list.txt)
WHITELIST=/etc/mail/nospamd

echo "#$(date)" > "$WHITELIST"
for d in $DOMAINS; do
        echo "#$d" >> "$WHITELIST"
        echo "$d" | smtpctl spf walk >> "$WHITELIST" 
done
exit 0

Je vous invite à appeler ce script via /etc/daily.local afin de régulièrement mettre à jour la liste des IP. Ensuite, il faut penser à recharger la table dans le parefeu :

# /etc/daily.local
/usr/local/sbin/generate-nospamd
pfctl -t nospamd -T replace -f /etc/mail/nospamd

6.10.3.6. Consulter l'activité de spamd

Pour voir l'activité de spamd, lancez la commande spamdb pour voir apparaître des choses comme ça :

WHITE|62.4.1.33|||1462699174|1462699174|1465809574|1|0
GREY|182.70.43.24|abts-mum-dynamic-024.43.70.182.airtelbroadband.in|<Estella32@thunderguy.co.uk>|<toto@chezmoi.tld>|1473409924|1473424324|1473424324|1|0
GREY|14.183.132.63|static.vnpt.vn|<Abby5@toddelliott.com>|<kiki@chezmoi.tld>|1473410586|1473424986|1473424986|1|0

On peut lire dans l'ordre :

  • Si l'IP est sur liste blanche (WHITE) ou grise (GREY).
  • L'IP concernée.
  • L'heure où cette entrée a été vue la première fois.
  • Le moment où l'IP sera passée en liste blanche.
  • Le moment où l'IP sera retirée de la base de données.
  • Le nombre de fois où cette IP a été bloquée.
  • Le nombre de fois où cette IP a été autorisée.

Il n'y a pas à dire, les "temps" sont illisibles pour les humains. Utiliser la commande date pour avoir un format lisible :

$ date -r 1462699174
    Sun May  8 11:19:34 CEST 2016

Pour manuellement mettre sur liste blanche une IP que vous savez valide, utilisez :

# spamdb -a "62.4.1.37"

6.10.3.7. Partager les informations entre deux instances de spamd

Puisque vous avez demandé à un(e) ami(e) d'être un backup au cas où votre serveur mail serait indisponible (n'est-ce pas ? 😁), il est important que son serveur ait connaissance des spammeurs détectés par votre spamd. Sinon, les spammeurs pourraient passer par leur backup pour vous délivrer des messages gênants.

Heureusement, spamd peut partager ses listes. Vous devez le lancer avec les options -Y et -y :

  • -Y : suivi de l'adresse IP qui recevra les données recueillies par votre spamd. Vous pouvez appeler cette option à plusieurs reprises.
  • -y : suivi de l'interface réseau qui recevra les données des autres instances spamd.

Éditez le fichier /etc/rc.conf.local en fonction pour obtenir par exemple :

spamd_flags=-Y 211.217.177.100 -Y 41.21.12.117 -y em0

Avant de relancer spamd, créer un fichier /etc/mail/spamd.key qui servira de clé partagée :

# dd if=/dev/random of=/etc/mail/spamd.key bs=2048 count=1

Tous les serveurs qui communiqueront entre eux devront avoir le même fichier. Envoyez-le donc à vos amis 😁.

Ouvrez dans votre [parefeu #pf] le port 8025/udp (spamd-sync) au cas où il serait fermé.

#/etc/pf.conf
pass in quick on egress proto udp to any port spamd-sync

Enfin, relancez spamd :

# rcctl restart spamd

6.10.3.8. Générer des statistiques concernant spamd

Un script pour générer des une page web contenant des statistiques sur les performances de spamd est disponible sur le site de calomel. Je vous en copie une version légèrement modifiée ci-dessous, qui nécessite l'installation des paquets p5-Geo-IP et p5-Socket. Je vous invite à l'enregistrer sous le nom /usr/local/bin/spamd_stats.pl :

#!/usr/bin/perl
use Socket;
use Geo::IP;
# Changez la configuration ci-dessous

# Spamd log file (daemon by default)
$spamdfile = "/var/log/daemon";

# Path to output html file
$spamdhtmlfile = "/var/www/htdocs/chezmoi.tld/spamdstats.html";

# Spamd delay is seconds (-s)
$spamddelay = 1;

##############################
# End Configuration Settings #
##############################

#####Begin: define dates #####
@months=("Jan","Feb","Mar","Apr","May","Jun","Jul","Aug","Sep","Oct","Nov","Dec");
@days=("Sun","Mon","Tue","Wed","Thu","Fri","Sat");
($sec,$min,$hour,$mday,$mon,$year,$wday)=(localtime(time))[0,1,2,3,4,5,6];
$year=$year+1900;
#####End: define dates #####

#####Begin: read spamd file(s) and get totals #####
open(SOURCE, "gzcat -f $spamdfile | sort -u |") or die ("Can't open file! Permissions? UserID? gzcat?");
  while( <SOURCE> ) {
    if ((/spamd/) && (/disconnected after/)) {
      ($dates,$hostname,$daemonandid,$ip,$seconds)
       = ($_ =~ /(\w+[ ]{1,2}\d+ \d+:.\d:.\d+) (.*) (.*)\: (\d+\.\d+\.\d+\.\d+)\: disconnected after (\d+) seconds/);
      $totalseconds +=$seconds;
      $totalspammers++;
      $line{$ip}{hits}++;
      $line{$ip}{time} += $seconds;
      ($date) = ($_ =~ /(\w+[ ]{1,2}\d+ \d+:.\d:.\d+)/);
      push(@date_array, "$date");
    }
  }
close(SOURCE) or die "File didn't close: $!";
if ($totalspammers==0){$totalspammers=1;}
#####End: reading spamd file(s) and get totals #####

##### Begin: calculate, consolidate and put into array #####
my %collectem = ();
foreach my $ip (keys %line) {
  $totalips++;
  my $hits  = $line{$ip}{hits};
  my $time  = $line{$ip}{time};
  my $conn  = int(($line{$ip}{time}/$line{$ip}{hits})+0.5);
  my $phits = int((($line{$ip}{hits}/$totalspammers)*100)+0.4);
  my $ptime = int((($line{$ip}{time}/$totalseconds)*100)+0.4);
  my $iaddr = inet_aton($ip); 
  my $reverse  = gethostbyaddr($iaddr, AF_INET);
  my $gi = Geo::IP->new(GEOIP_MEMORY_CACHE);
  my $country = $gi->country_code_by_addr($ip);

  push (@arrayem, [$hits,$ip,$time,$conn,$phits,$ptime,$reverse,$country]);
}
##### End: calculate, consolidate and put into array #####

#####Begin: order data by hits, time then ip in decending order #####
sub orderem {
  $b->[0] <=> $a->[0]  or $b->[2] <=> $a->[2]  or $b->[1] cmp $a->[1];
}
#####End: order data by hits, time then ip in decending order #####

#####Begin: output to HTML #####
open(SPAMDHTMLSTATS, ">$spamdhtmlfile") or die ("Can't create file");

print SPAMDHTMLSTATS "<!DOCTYPE html>\n";
print SPAMDHTMLSTATS "<html lang=\"fr\"><head><meta charset=\"utf-8\">\n";
print SPAMDHTMLSTATS "<meta name=\"viewport\" content=\"width=device-width, initial-scale=1\"/>\n";
print SPAMDHTMLSTATS "<title>Statistiques Spamd sur $host Spamd</title>\n";
print SPAMDHTMLSTATS "<link rel=\"stylesheet\" type=\"text/css\" href=\"$style\"></head>\n";
print SPAMDHTMLSTATS "<body>\n";
print SPAMDHTMLSTATS "<header>";
print SPAMDHTMLSTATS "<h1>Spamd Stats sur $host</h1>\n";
print SPAMDHTMLSTATS "<ul>";
print SPAMDHTMLSTATS "<li>Script lancé le : <span>$days[$wday] $months[$mon] $mday $year à $hour:$min";
printf SPAMDHTMLSTATS (" en %4.0f seconde(s)</span></li>\n",time-$^T);
print SPAMDHTMLSTATS "<li>Intervalle de temps :  <span>$date_array[0] au $date_array[-1]</span></li></ul>";
print SPAMDHTMLSTATS "\n";

print SPAMDHTMLSTATS "<ul>\n";
printf SPAMDHTMLSTATS ("<li>Temps perdu pour les spammeurs:  <span>%4.2f h</span></li>\n",$totalseconds/3600);
printf SPAMDHTMLSTATS ("<li>Bande passante utilisée : <span>%4.2f MB</span></li>\n",($totalseconds/$spamddelay*80.606/1000000));
printf SPAMDHTMLSTATS ("<li>Temps moyen par piège : <span>%4.2f minutes</span></li>\n",($totalseconds/$totalspammers)/60);
print SPAMDHTMLSTATS "<li>Nombre d'IP utiques piégées : <span>$totalips</span></li>\n";
print SPAMDHTMLSTATS "<li>Nombre total de connexions : <span>$totalspammers</span></li>";
print SPAMDHTMLSTATS "</ul>\n";
print SPAMDHTMLSTATS "</header>\n";

print SPAMDHTMLSTATS "<section>\n";
print SPAMDHTMLSTATS "<table><caption>Statistiques anti-spamd</caption>\n";
print SPAMDHTMLSTATS "<thead>\n";
print SPAMDHTMLSTATS "<tr>\n<th>Pièges</th>";
print SPAMDHTMLSTATS "<th>Source IP</th>";
print SPAMDHTMLSTATS "<th>Temps (s)</th>";
print SPAMDHTMLSTATS "<th>Moyenne Sec/piège</th>";
print SPAMDHTMLSTATS "<th>% des pièges</th>";
print SPAMDHTMLSTATS "<th>% de temps</th>";
print SPAMDHTMLSTATS "<th>Reverse DNS</th>";
print SPAMDHTMLSTATS "<th>Pays</th>\n</tr>\n";
print SPAMDHTMLSTATS "</thead>\n";

print SPAMDHTMLSTATS "<tbody>\n";
@sortem = sort orderem @arrayem;
foreach $thingy (@sortem) {
    print SPAMDHTMLSTATS "<tr><td ><b>$thingy->[0]</b></td><td ><b>$thingy->[1]</b></td><td ><b>$thingy->[2]</b></td><td ><b>$thingy->[3]</b></td><td ><b>$thingy->[4]</b></td><td ><b>$thingy->[5]</b></td><td ><b>$thingy->[6]</b></td><td >$thingy->[7]</td></tr>\n";
}
print SPAMDHTMLSTATS "</tbody>\n";

print SPAMDHTMLSTATS "</table>\n";
print SPAMDHTMLSTATS "</section>\n";
print SPAMDHTMLSTATS "<footer>Généré avec <a href=\"https://dev.ybad.name/OpenBSD-stuff/spamd_stats.pl\">spamd_stats.pl</a></footer>\n";
print SPAMDHTMLSTATS "</body>\n";
print SPAMDHTMLSTATS "</html>";
close(SPAMDHTMLSTATS);
#####End: output to HTML #####

Modifiez les options suivantes au début du script selon votre situation :

  • $spamdfile = "/var/log/daemon"; : Le fichier contenant les logs de spamd. normalement, vous n'avez pas à le modifier, c'est le chemin par défaut.
  • $spamdhtmlfile = "/var/www/htdocs/chezmoi.tld/spamdstats.html"; : Le chemin de la page web qui contiendra les statistiques
  • $spamddelay = 1; : spamd parle lettre par lettres avec un spammeur. Ici, c'est le nombre de secondes entre chaque lettre. Là aussi, rien à changer sauf si vous avez ajouté l'option -s au démarrage de spamd.

Il s'utilise ainsi :

/usr/bin/perl /usr/local/bin/spamd_stats.pl

Vous obtiendrez alors quelque chose ressemblant à ceci :

Afin de générer les statistiques quotidiennement, ajoutez la commande ci-dessus dans le script /etc/daily.local 😉.

6.11. Vérifier que tout fonctionne bien

Vous voudrez peut-être tester votre serveur mail après tous ces efforts. Vous l'avez bien mérité. Vous pouvez bien entendu écrire à des amis, mais cela peut poser des soucis :

  • Il faudra attendre leur réponse ;
  • Ils ne vous retourneront pas toutes les informations dont vous pourriez avoir besoin ;
  • Il faut avoir des amis.

Il existe heureusement des robots auxquels on peut écrire un mail, qui vous répondront très vite en vous donnant de précieuses informations. Nous avons déjà parlé de mail-tester un peu plus haut. Il existe aussi les adresses suivantes :

  • echo@generic-nic.net
  • echo@nic.fr
  • autoreply@dmarctest.org
  • Le site https://glockapps.com/ permet de tester sa réputation.

Vous en trouverez d'autres sur cette page.

Vous pouvez aussi avoir des tests détaillés sur votre serveur mail est ses backup éventuels sur mxtoolbox.

7. Serveur de noms

7.1. Principes généraux du DNS

Le DNS (Domain Name System), c'est ce qui vous permet de reconnaître les noms de machines sur Internet. Ce sont les panneaux indicateurs et les annuaires téléphoniques du net.

C'est aussi ce qui indique où doit être envoyé le courrier, ainsi que plein d'autres détails techniques barbants dont la plupart des gens n'ont pas idée mais qui contribuent à la robustesse du réseau.

Ce système repose d'abord sur l'idée de zone. On commence par la zone racine, représentée par un point à l'extrémité d'une adresse. Cette zone racine contient les adresses des serveurs de noms autoritaires des tld (fr., de., dk., ph., com., net., org. etc). Chaque TLD constitue lui-même une zone contenant les adresses des serveurs de noms autoritaires pour les niveaux suivants.

(image issue et modifiée depuis wikipedia)

Ainsi, pour peu que l'on connaisse les adresses des serveurs de la zone racine (aussi appelés serveurs racines, ou serveurs root), on peut normalement connaître n'importe quelle adresse dans le système de noms Internet : il suffit de commencer à la racine et parcourir la chaîne, zone après zone.

Cette action de parcourir la zone s'appelle la résolution (de noms). Les serveurs qui effectuent cette recherche sont dits résolveurs. Les serveurs qui portent l'information relative à chaque zone sont dits autoritaires.

Lorsqu'un résolveur a récupéré l'adresse d'une machine, d'un site web ou autre, ce serveur va mettre l'adresse en cache, en mémoire, et ce pour la durée de validité des données, indiquée par le serveur autoritaire sous le nom de TTL ou Time To Live.

Cette durée de validité implique un délai de propagation, le temps que les différents résolveurs mettent à jour les informations de la zone considérée. Plus le TTL est élevé, plus les délais de propagation des informations d'une zone seront importants, mais plus le trafic réseau sera réduit. C'est donc un choix d'équilibre.

7.1.1. DNSSEC

Il y a quelques années, des gens très intelligents ont commencé à s'inquiéter : DNS étant critique, il était donc important qu'il soit sécurisé.

En fait, il est assez facile, lorsque vous surfez sur le web, de vous envoyer sur de fausses adresses. On a donc cherché à s'assurer que le DNS ne délivre que des adresses authentiques, autrement dit, dont on soit sûr qu'elles sont vraies.

Pour ce faire, chaque détenteur d'un nom de domaine écrit sa zone DNS, puis la signe à l'aide d'un algorithme cryptographique.

Les résolveurs sont alors chargés de vérifier que ces signatures sont bien valides.

Logique non ?

Concrètement, ça permet à chacun d'être sûr d'être sur le bon site web, pas sur celui d'un pirate. On peut aussi y publier des informations sûres : c'est le principe de DANE/TLSA qui consiste à publier les empreintes des certificats de chiffrements TLS (sites web, serveurs mail).

Ces notions sont revues et approfondies sur cet article de lord.re.

7.2. Résolveur validant avec cache : Unbound

Unbound est présent par défaut dans OpenBSD. Il permet en l'état de résoudre les noms de domaines et de garder le résultat en cache pour de meilleures performances. Votre serveur peut le faire lui-même plutôt que de compter sur le résolveur de votre fournisseur d'accès à internet (FAI). Nous allons lui ajouter la possibilité de valider les noms de domaines avec DNSSEC.

On édite le fichier /var/unbound/etc/unbound.conf pour le remplir ainsi :

server:
	interface: 127.0.0.1
	interface: ::1
	do-ip6: yes
	do-ip4: yes
	do-udp: yes
	do-tcp: yes

	# seul le serveur a le droit 
	# d'utiliser unbound en local
	access-control: 0.0.0.0/0 refuse
	access-control: ::0/0 refuse
	access-control: 127.0.0.0/8 allow
	access-control: ::1 allow

	hide-identity: yes
	hide-version: yes
        harden-glue: yes

	auto-trust-anchor-file: "/var/unbound/db/root.key"
	
	module-config: "validator iterator"

	prefetch: yes
	prefetch-key: yes

Notez que cette configuration ne permet pas à des clients en réseau local de faire des requêtes DNS à unbound. La résolution n'est que pour votre serveur. Sachez toutefois que c'est possible si l'envie vous prend d'avoir un résolveur avec cache pour vos machines locales.

Activez unbound avec les commandes habituelles :

# rcctl enable unbound
# rcctl start unbound

Pour indiquer au serveur de demander la résolution des noms de domaines à son instance d'unbound, on édite le fichier /etc/resolv.conf pour y mettre :

nameserver 127.0.0.1

Dans le cas où votre serveur se connecte via dhcp, ajoutez alors cette ligne à la fin du fichier /etc/dhclient.conf :

prepend domain-name-servers 127.0.0.1;

Ou bien donnez-lui pour instruction d'ignorer les résolveurs indiqués par votre fournisseur d'accès (toujours dans /etc/dhclient.conf):

ignore domain-name-servers, domain-name;

Et voilà, votre serveur se débrouille maintenant tout seul pour résoudre des noms de domaine.

Vous pouvez tester l'efficacité d'unbound avec la commande dig qui nous montre les résultats d'une résolution DNS :

$ dig ybad.name
[…]
;; Query time: 61 msec

Il a fallu ici 61 millisecondes pour avoir une réponse. Relancez une deuxième fois cette commande pour voir la différence :

$ dig 3hg.fr
[…]
;; Query time: 0 msec

L'adresse a été mise en cache, et sera vérifiée régulièrement (à l'issue d'une durée égale au TTL). C'est toujours un gain de performance bienvenu !

Pour aller plus loin dans la découverte d'unbound et ses nombreuses possibilités, vous pouvez consulter le wiki d'OBSD4*.

7.2.1. À propos du fichier racine

Si l'utilisateur système _unbound peut écrire dans le dossier /var/unbound/db/, alors il mettra automatiquement à jour les clés racine suivant la procédure de la RFC 5011 (si une nouvelle clé racine apparait et est signée et reste présente pendant 30 jours, alors elle est incluse comme clé racine).

Unbound renouvelle ses clés racine via la commande unbound-anchor à chaque redemarrage via rc.

Pensez à vérifier environ une fois par an que les adresses des serveurs racines sont à jour en consultant la date et/ou le numéro de série de la zone root IANA et le comparer avec le fichier /var/unbound/db/named.cache.

Pour information, vous pouvez récupérer manuellement un fichier racine si le votre n'est plus à jour avec la commande unbound-anchor.

/usr/sbin/unbound-anchor -a "/var/unbound/db/root.key"

7.3. Serveur de noms autoritaire avec NSD

Il y a encore un service que vous pouvez administrer par vous-même plutôt que de le laisser entre des mains extérieures : le serveur DNS autoritaire.

Outre le bonheur d'être indépendant, de contrôler ses données, sachez qu'un serveur autoritaire sait exactement qui demande à voir tel ou tel contenu. Si on se place dans le cas où un serveur est autoritaire pour des centaines de zones, ce dernier constitue alors un excellent moyen de collecter une liste de visiteurs pour des sites web. Autant laisser cette tâche à une personne de confiance : vous.

Si vous avez à cœur la vie privée de chacun, et souhaitez être totalement indépendant, il vous est possible d'utiliser NSD, le serveur de nom autoritaire par défaut d'OpenBSD, pour publier votre zone plutôt que de déléguer cette tâche à votre registre ou une autre entreprise privée. Il est conçu autour de l'idée d'une zone statique

7.3.1. Configuration simple de NSD

Pour configurer NSD, on édite le fichier /var/nsd/etc/nsd.conf.

server:
        server-count: 2
        hide-version: yes
        zonesdir: "/var/nsd/zones"
        ip-address: 192.168.1.2
        ip-address: 2001:db8:1:1::2
        debug-mode: no
        verbosity: 2

## master zones
zone:
        name: "chezmoi.tld"
        zonefile: "master/chezmoi.tld"

Ici NSD suit cette organisation : les zones sont classées selon si le serveur est autoritaire (master) ou esclave (slave). Chaque zone correspond à un fichier portant le nom du domaine. Par exemple /var/nsd/zones/master/chezmoi.tld. Vous pouvez bien sûr vous organiser différemment.

N'oubliez pas de modifier cet exemple avec l'adresse IP locale du serveur.

Une fois configuré, vous pouvez finalement lancer nsd comme d'habitude :

rcctl enable nsd
rcctl start nsd

Pensez à ouvrir et rediriger le port 53 (domain) en UDP et TCP, c'est celui utilisé par nsd.

Lorsque la configuration de NSD est correcte, vous pouvez alors mettre dans le registre les adresses publiques de votre serveur (ipv4 et/ou ipv6).

Un exemple de configuration complet est disponible à la fin du présent document.

7.3.2. Écrire un fichier de zone DNS

Les fichiers de zone DNS suivent un format standard, que tous les serveurs de noms autoritaires suivent, à quelques exceptions près.

On va montrer ici la zone d'exemple typique (un truc idéal qui n'arrive jamais dans la réalité).

Voici un fichier type de zone /var/nsd/zones/chezmoi.tld :

$TTL 2D

@           IN SOA    maitre.chezmoi.tld. hostmaster.chezmoi.tld. (
			; domaine A enregistre avant 
			; suivi de l'adresse mail pour
			; contacter le responsable du serveur.
			; Ici, cette adresse
			; est hostmaster@example.com. 
			; Oui, le "@" est remplace par un "."
                    2014110502      ; numero de serie a augmenter
                                    ; a chaque modification.
                    86400           ; Refresh
                    7200            ; Retry
                    3600000         ; Expire
                    172800 )        ; Negative Cache TTL

$ORIGIN chezmoi.tld.
@           IN NS       maitre
@           IN NS       secondaire

@           IN MX       10 mail1
@           IN MX       20 mail2

maitre      IN A        192.0.2.2
            IN AAAA     2001:db8:1:1::2

mail1       IN A        192.0.2.10
mail2       IN A        192.0.2.11

ipv4only    IN A        192.0.2.15
ipv6only    IN AAAA     2001:db8:1:1::400
dualstack   IN A        192.0.2.200
            IN AAAA     2001:db8:1:1::200

passerelle  IN      AAAA    %%ipv6_passerelle

maitre      IN      A       %%ip_pub_maitre
            IN      AAAA    %%ipv6_maitre

secondaire  IN      A       %%ip_pub_second
            IN      AAAA    %%ipv6_second
…
Ouhlala, c'est compliqué ton truc !

Pas d'inquiétudes, on va expliquer ensuite ce que tout ceci signifie. Courage 😁

7.3.2.1. Les enregistrements DNS et comment les utiliser…

Les enregistrements DNS sont (généralement) structurés ainsi (entre parenthèse le nom anglais officiel du champ) :

NOM(NAME)    CLASSE(CLASS)    TYPE    TTL    DONNÉE(RDATA)

Le nom correspond à ce que vous cherchez.

La classe désigne internet (IN). Au début d'internet, d'autres classes étaient utilisées. Aujourd'hui de nombreuses documentations omettent la classe du fait qu'il n'y en a qu'une seule en activité, et que la plupart des résolveurs fonctionnent bien sans. Néanmoins, il arrive que certains programmes ou processus de résolution DNS plantent si la classe n'est pas présente.

Le type désigne le type de donnée du champ.

Le TTL désigne le Time To Live soit le temps pour lequel la donnée est considérée comme valide.

Enfin la donnée correspond à l'information désignée par le nom de type TYPE.

Voyons ensemble les différents TYPE :

7.3.2.1.1. @, $ORIGIN, $TTL

$ORIGIN fait normalement référence au nom complet de la zone. Par exemple, chezmoi.tld.

Dans le cas où le fichier de zone ne comporte pas de directive $ORIGIN, le serveur de nom va en produire une avec le nom de la zone.

@ sera remplacé par $ORIGIN.

Si vous souhaitez davantage d'informations à propos de cette directive, vous pouvez lire cette documentation.

$TTL est la durée de validité par défaut des données. La valeur recommandée est de 1 jour (1D).

Chaque enregistrement DNS peut avoir son propre TTL (MX et NS sont normalement très stables, et peuvent donc par exemple avoir des TTL d'une semaine voir plus, ceci permet de réduire la charge réseau).

$ORIGIN et $TTL doivent être placés en premier.

7.3.2.1.2. SOA

Le premier enregistrement avec $ORIGIN et $TTL s'appelle le SOA, pour Source Of Authority. C'est un élément très important. Le premier champ après SOA désigne le serveur de nom d'origine, en l'occurrence maitre.chezmoi.tld. et le dernier champ désigne l'adresse de l'administrateur du domaine. hostmaster.chezmoi.tld. se transformera en hostmaster@chezmoi.tld . Le premier point sera transformé en @. Vous avez dû mettre un alias sur hostmaster lors de la mise en place du serveur mail. Si vous ne pouvez pas et devez utiliser un point dans la partie "username" (avant @) de l'adresse (Vous vous compliquez vraiment la vie !), vous devrez alors mettre un \ avant :

jean\.perrin.chezmoi.tld.

Il faut bien voir que le serveur Source d'autorité et l'adresse de l'administrateur du domaine ne sont pas forcément situés dans le domaine en question.

Le numéro de série peut-être de diverses formes, mais il doit toujours aller en augmentant à chaque mise à jour de la zone. Ça permet aux serveurs secondaires de repérer qu'il existe une version plus récente de la zone. Certains administrateurs utilisent la date suivie d'un numéro incrémenté (2017021312 pour une zone modifiée le 13/02/2017 pour la 12è fois - oui, ça peut arriver 😁). D'autres utilisent le timestamp du moment de l'édition (horodatage unix à la seconde près). D'autres se contentent de commencer à 1 et d'incrémenter. Chacun a ses avantages.

Les valeurs du SOA (refresh, retry, expire, négative), indiquées ici, ainsi que celle du TTL, sont celles recommandées par les normes (RFC). Il est tout-à-fait possible de mettre d'autres valeurs, toutefois celles indiquées ici ont fait leurs preuves.

Les valeurs sont par défaut en secondes. On peut aussi indiquer les valeurs en heures (H) jours (D) ou semaines (W).

Refresh et retry indiquent au bout de combien de temps les serveurs secondaires (esclaves), mais néanmoins toujours autoritaires pour la zone, doivent renouveler la zone. Aujourd'hui beaucoup de serveurs de noms signalent à leurs esclaves qu'ils doivent prendre les nouvelles informations. Ces valeurs ont donc moins d'importance.

Expire indique la date limite d'utilisation des informations pour le cas où les serveurs de noms de la zone ne sont plus accessibles. C'est bien différent du TTL.

La valeur negative est en fait le temps durant lequel une réponse NXDOMAIN (non existence de la donnée recherchée) sera conservée en cache.

7.3.2.1.3. A, AAAA

Encore une fois : {NOM, TTL, CLASSE, TYPE, RDATA}.

Les adresses de la machine maitre.chezmoi.tld sont donc enregistrées sous cette forme :

maitre          IN A        192.0.2.2
                IN AAAA     2001:db8:1:1::2
  • Le nom "maitre" n'a pas de point au bout, il est donc complété jusqu'à la racine : maitre.chezmoi.tld.
  • Le champ TTL est vide et correspond donc au TTL de la zone par défaut, 1 jour ici.
  • La classe est IN, ce qui correspond à INTERNET. C'est la seule classe active aujourd'hui et certaines documentations l'oublient. De nombreux serveurs n'en ont pas besoin. Néanmoins certains programmes plantent si elle n'est pas présente.
  • Le type est ici A (adresse ipv4) ou AAAA (adresse ipv6).
  • RDATA est la donnée en question, c'est-à-dire 192.0.2.2 pour A et 2001:db8:1:1::2 pour AAAA.

Rappelez-vous bien que le dernier point dans les adresses, implicite dans la plupart des documentations avec des adresses Internet, devient ici très important. Il représente la zone racine. Si une donnée d'adresse ne se termine pas par un point, elle sera complétée ou provoquera un bug.

7.3.2.1.4. CNAME

CNAME, pour Canonical NAME est un alias.

Dans l'exemple suivant, le nom canonique (réel) de www est maitre.

www IN CNAME maitre

C'est ce qu'on fait dans le cas des hôtes virtuels (ex : blog.chezmoi.tld, webmail.chezmoi.tld…).

7.3.2.1.5. NS

Une zone DNS devrait avoir au minimum 2 NS records d'après les règles communément admises. Techniquement la zone fonctionnera très bien avec un seul, pour autant que le serveur de nom derrière cet enregistrement n'ait jamais de problème.

Il n'y a pas de limite technique au nombre de serveurs NS (autoritaires) dans une zone, mais certains registres en mettent une (le registre du "dk." a par exemple une limite à 7 NS). Ça n'a l'air de rien, mais suivant les limites ou restrictions techniques mises en place par tous les intermédiaires, ça peut monter vite.

Par exemple, sur le registre dk. cité précédemment, un bureau d'enregistrement très populaire a déjà cinq serveurs. Si on enregistre le domaine chez eux, il y aura alors ces cinq serveurs dans la liste de serveurs autoritaires, c'est comme ça, vous n'y pouvez rien. Par contre, vous pouvez les mettre en esclaves. Mais ils seront présents. Reste la place pour votre serveur maître, et peut-être un autre serveur d'un ami, sur lequel vous avez la main «par délégation».

chezmoi.tld.   IN  NS   maitre.chezmoi.tld.

Cet enregistrement signifie : pour la zone chezmoi.tld, le serveur de nom autoritaire (NS) est maitre.chezmoi.tld. On aurait pu aussi l'écrire comme ça :

@     IN NS   maitre

Dans le premier cas, le @ se trouve remplacé par le $ORIGIN de la zone, soit en fait son nom (complet, jusqu'à la racine, c'est à dire avec un point final) et maitre est complété aussi en "maitre.chezmoi.tld.".

Dans le deuxième cas, le nom recherché n'a toujours pas de point donc on complète avec $ORIGIN.

Pour que les serveurs de noms soient connus du reste du monde, il vous faut les enregistrer dans le registre (la zone du tld, voir "les principes généraux du DNS"). C'est d'ailleurs un des deux seuls enregistrements à faire sur le registre, avec l'enregistrement des clés DNSSEC. En effet, une fois que les serveurs autoritaires sont publiés, tout se passe directement sur votre serveur.

Lors de l'enregistrement des NS sur le registre (via le bureau d'enregistrement, ou registrar), on fournit en général deux champs : le nom d'hôte complet de la machine, maitre.chezmoi.tld en l'occurrence, et l'adresse(s). On parle dans ce cas de Glue Record. Comment faire pour connaître l'adresse de maitre.chezmoi.tld puisque c'est lui-même qui a les adresses de la zone chezmoi.tld ? Dans ce cas, exceptionnellement, l'adresse sera écrite directement dans le registre.

Pour enregistrer des serveurs de noms autoritaires sur le registre, il vous faut vous connecter chez votre bureau d'enregistrement. Chez GANDI, c'est facile :

Cliquez d'abord sur "Domaines" :

Choisissez ensuite votre domaine :

Sur la gauche, vous pouvez voir une entrée "Glue Records" :

Vous pouvez ajouter un nouveau serveur glue en cliquant sur "Ajouter".

Dans l'exemple ci-dessous, ledzep.ouaf.xyz est un glue record déjà présent.

Entrez maintenant le nom de domaine de votre serveur autoritaire maitre puis l'adresse IP correspondante :

Validez, vous voyez apparaître ce nouveau glue record.

Maintenant que l'enregistrement glue est défini, cliquez sur le lien à gauche "Serveurs de nom".

Dans ce nouvel écran, ajoutez en premier (DNS1) l'enregistrement glue défini précédemment. Vous pouvez aussi ajouter des serveurs secondaires, comme celui de gandi ns6.gandi.net.

On prend ensuite pour exemple l'interface web du registre danois (dk-hostmaster).

(On doit fournir un nom d'hôte complet, ainsi qu'une adresse IP.)

Cette étape vous a permis de créer une glue ou colle, de votre serveur dans le registre. Il ne reste plus qu'à le marquer comme autoritaire (c'est généralement un autre espace de l'interface qu'il vous faut utiliser).

(On a ici la liste des adresses des serveurs de nom autoritaires pour la zone 22december.dk.)

Cette partie s'avère délicate car toujours différente d'un registre à l'autre. Certains ont des administrations centralisées, d'autres délèguent tout au bureau d'enregistrement. Il y a également le problème de la langue dans laquelle sont conçues et affichées ces interfaces. On vous conseille d'activer l'authentification à double jeton quand elle est disponible. C'est un peu plus laborieux, mais permet une gestion plus raisonnable et sécurisée de la zone.

Au sujet des registres, vous pouvez lire cet article.

7.3.2.1.6. MX

MX, c'est un peu comme NS, ça indique un service pour la zone, en l'occurrence le dépôt du courrier. L'enregistrement est un peu conçu de la même manière :

@     IN MX 10   mail1
@     IN MX 20   mail2

Pour la zone chezmoi.tld, le serveur de mail (MX) est mail1.chezmoi.tld.

Seule différence, le 10, qui indique la priorité. Quand on a plusieurs serveurs dans la zone, quel est le serveur qui doit recevoir le courrier en priorité ? Celui qui a le poids le plus faible.

En auto-hébergement, vous pouvez vous contenter d'utiliser le nom de domaine seul plutôt que de créer un sous-domaine mail correspondant à un champ A. Tout simplement :

@     IN MX 10   chezmoi.tld.

MX et NS ne peuvent pas être des redirections (CNAME).

Tout au plus accepte-t-on, avec réticence, des adresses IP. Mais normalement, les champs MX et NS pointent sur des noms d'hôtes.

7.3.3. Signer son domaine avec DNSSEC

7.3.3.1. Quelques détails sur la signature des zones DNS

DNSSEC utilise deux sortes de clés : ZSK (Zone Signing Key), légères et de courte durée et KSK (Key Signing Key) plus lourdes et de longue durée d'utilisation.

Pourquoi la différence ?

Il est recommandé que les clés qui signent les zones soient renouvelées régulièrement (approximativement tous les mois, certains le font toutes les semaines). Mais d'un autre côté, on peut difficilement mettre ça à jour tous les mois dans le registre.

On a donc créé en plus d'autres clés qui vont signer les premières, mais qu'on n'utilisera que pour cela, pas pour signer les zones en elles-mêmes. Ces clés seront plus solides, plus lourdes (on peut se permettre, puisqu'elles sont peu utilisées) et d'une plus longue durée de vie. Ce sont ces clés qui seront enregistrées dans le registre.

En fait, on ne va pas les enregistrer, mais mettre un condensat, une empreinte cryptographique, dans la zone supérieure. C'est le même principe que pour les serveurs de noms : chaque zone publie ses serveurs de noms (NS) dans la zone supérieure.

Il est important aussi que vous voyiez ici les notions de temps. Entre le TTL, la durée de vie et de validité des clés et des signatures, vous ne pouvez plus faire des changements et regarder le truc marcher immédiatement.

En particulier, vous devez publier à l'avance les clés qui seront utilisées prochainement. Ceci amène de nombreux administrateurs à avoir en permanence deux ZSK : une qui est utilisée actuellement et une autre qui sera utilisée à la fin de la période de validité de la clé actuelle. C'est d'ailleurs cette solution qui est présentée en dessous. Les clés KSK sont elles aussi publiées à l'avance (quoique rarement en double).

7.3.3.2. Mise en place

Comme décrit plus tôt, signer votre domaine DNS vous permet de préserver son intégrité.

Cette opération doit être renouvelée régulièrement (les signatures DNSSEC ont une date de fraîcheur limite).

Ceci requiert l'installation d'un signeur ainsi qu'un peu d'automatisation. On va décrire ici la solution ldnscripts qui est un script simple réalisé par 22decembre. Notez qu'il existe des outils plus complets/complexes comme OpenDNSSEC (beaucoup plus complexe à installer et administrer) ou KNOT.

ldnscripts ne nécessite pas d'ajouter d'outils particuliers mis à part ldns :

# pkg_add ldns-utils

Le reste sera géré en utilisant les outils déjà présents de base dans OpenBSD, à savoir les scripts /etc/weekly, /etc/monthly

Nous allons suivre la méthode proposée par l'auteur de ce script et installer ldnscripts à partir de l'archive que l'on décompresse :

$ cd /tmp
$ ftp https://framagit.org/22decembre/ldnscripts/-/archive/master/ldnscripts-master.tar.gz
$ tar xvzf ldnscripts-master.tar.gz
$ cd ldnscripts-master* 
# make install
7.3.3.2.1. Configuration

La configuration se déroule dans le fichier /etc/ns/ldnscripts.conf. Vous avez un modèle dans l'archive téléchargée précédemment qui ressemble à ça :

# repository where to find unsigned zone file and specific conf
NS_REP=/etc/ns

# serial : unixtime
SERIAL=unixtime

# algorithm to use. They are listed : ldns-keygen -a list
ALG=RSASHA512

# length of the zsk
ZSK_BITS=1024

KSK_BITS=2048

# validity of signatures in days
VALIDITY=9

#NSEC3
NSEC3_ALG=SHA-1
RUN=24

# Verbose - set to 1 if needed
VERBOSE=1

Les paramètres sont les suivants :

  • NS_REP correspond au dossier où sont les zones à signer. Chaque fichier de zone doit porter le nom du domaine que vous voulez servir. Par exemple /etc/ns/chezmoi.tld. Vous devez créer cette zone.
  • SERIAL : Le format du numéro de série de la zone. Ça peut être "unixtime" ou encore "date". Dans le doute, ne changez rien.
  • ALG : L'algorithme pour les clés. Vérifiez ce que votre registre supporte avant de changer ce paramètre.
  • ZSK_BITS et KSK_BITS : la longueur des clés ZSK et KSK respectivement.
  • VALIDITY : La durée de validité d'une signature en jours. Attention, ce paramètre doit être au moins aussi long que l'intervalle de ces mêmes signatures (voir la commande sign plus bas)
  • NSEC3_ALG et RUN : L'algorithme de signature et le nombre de fois que l'algorithme doit tourner pour générer la signature.
  • VERBOSE : À mettre à "1" si vous voulez des détails supplémentaires en utilisant ldnscripts.

Si vous souhaitez utiliser une configuration par domaine, c'est tout à fait possible en créant un fichier de configuration portant le nom /etc/ns/domaine.com.conf.

Sinon, le plus simple est d'avoir une seule configuration en copiant l'exemple de l'archive :

# cp ldnscript.conf /etc/ns/

C'est tout pour la configuration 😁

7.3.3.2.2. Initialisation

Pour commencer, on lance l'action init qui va créer tout le nécessaire : structure, premières clés… La commande à lancer est :

ldnscript init chezmoi.tld

Vous verrez alors des messages de ce type (le VERBOSE est actif ci-dessous) :

This script will initialize your zone chezmoi.tld with the general configuration or the
one set at /etc/ns/chezmoi.tld.conf.
If you are not happy with it, modify your configuration (by copying the conf file to /etc/ns/chezmoi.tld.conf and then editing it) and run this script again.
The script will create one KSK and two ZSK and finally sign the zone (which will triger a reload of your NSD server on the chezmoi.tld zone).
The key Kchezmoi.tld.+010+25115 has been generated with these arguments : -a RSASHA512 -b 1024 chezmoi.tld
The key Kchezmoi.tld.+010+34655 has been generated with these arguments : -a RSASHA512 -b 1024 chezmoi.tld
The key Kchezmoi.tld.+010+12321 has been generated with these arguments : -k -a RSASHA512 -b 2048 chezmoi.tld
A new KSK key has been generated.
Make sure to update the DS record in your registrar quickly.
The key is Kchezmoi.tld.+010+12321
DS content : 
chezmoi.tld. IN      DS      12321 10 2 f6f91afd522680a3c459e1956e75f8eda078f99b8cf07114f0d299161bff0145
create a complete zone file for chezmoi.tld with the current time as SOA
Signing zone
Zone is verified and complete

Un dossier /var/ldnscripts/chezmoi.tld/ est créé, il contient les clés ZSK et KSK.

Le fichier de zone signé est présent dans /var/nsd/zones/signed/chezmoi.tld. Adaptez donc la configuration de nsd pour l'utiliser :

server:
        zonesdir: "/var/nsd/zones"
        …

## master zones
zone:
    name: "chezmoi.tld"
    zonefile: "signed/chezmoi.tld"

À noter que NSD est un serveur statique. Heureusement, ldnscript le relance après chaque signature.

Attention, vous devez publier chez votre registre les clés publiques que vous trouverez dans les fichiers portant l'extension .key disponibles dans /var/ldnscript/chezmoi.tld/ksk. Selon votre registre, il faut aussi publier les enregistrements DS qui sont dans le fichier .ds (pas pour GANDI). Lisez la partie qui montre comment ajouter des clés chez le registre pour plus d'informations.

7.3.3.2.3. Utilisation courante

Nous n'avons pas fini, il faut maintenant mettre en place une routine de signature avec renouvellement des clés lorsque c'est nécessaire. Tout est prévu, rassurez-vous 😁 .

Parmi les actions proposées par ldnscript, on trouvera :

  • sign : Cette action signe la zone pour une durée égale à VALIDITY. On le lancera donc un peu avant la fin de validité d'une signature, mais aussi après chaque modification de la zone et la création / renouvellement d'une clé.
  • rollover qui va renouveler les clés. Il y aura normalement 3 clés afin de pré-publier les clés qui seront utilisées par la suite pour qu'elles soient bien répandues :
    • La clé à la retraite
    • La clé en cours d'utilisation
    • La future clé.

Ce script s'occupe aussi de supprimer les clés qui ne sont plus utilisées. Il faudra le lancer tous les mois.

  • zsk vous permet de créer de nouvelles clés ZSK manuellement. Elles seront mises en activité lors du prochain rollover. Lors de chaque rollover, une nouvelle clé zsk sera également automatiquement créée grâce à cette commande.
  • ksk crée une clé KSK sur le même principe.

Concrètement, voici ce que vous allez faire. Éditez le fichier /etc/monthly.local pour y ajouter :

/usr/local/sbin/ldnscript rollover all

Ensuite, nous devons nous assurer que les signatures sont renouvelées avant la fin du paramètre VALIDITY du fichier de configuration. On a mis 9 jours auparavant, afin de lancer la signature chaque semaine avec 2 jours d'avance. Éditez le fichier /etc/weekly.local :

/usr/local/sbin/ldnscript sign all

Enfin, tous les ans, vous créerez une nouvelle KSK ainsi :

/usr/local/sbin/ldnscript ksk chezmoi.tld

N'oubliez pas de publier cette clé. Le script rollover se chargera de supprimer l'ancienne automatiquement. Vous pourrez à ce moment-là retirer son enregistrement chez le serveur.

Et voilà, ça suffit, tout le reste est géré par ldnscript. Notez que dans l'exemple, on ne gère qu'une zone. Des scripts facilitant la gestion de plusieurs zones et leur vérification sont disponibles, regardez le site de l'auteur pour plus de détails.

7.3.3.3. Ajouter ou enlever des clés au registre

Lorsque vous renouvelez les KSK, vous devez publier la clé publique dans votre registre. Il faut le faire assez tôt pour qu'elle soit bien répandue avant que la précédente soit révoquée.

Lors de la création de la clé, ldnscript vous indiquera le numéro de la nouvelle clé (keytag) ainsi que son condensat (DS) qui vous servira pour la publication dans le registre.

La clé publique se situe dans le fichier /var/ldnscripts/zones/chezmoi.tld/ksk/Kchezmoi.tld*.key.

7.3.3.3.1. GANDI

On présente comment ajouter cette clé dans le système du bureau d'enregistrement Gandi. Dirigez-vous dans votre tableau de bord :

(On voit ici la page d'entrée de Gandi pour le domaine ouaf.xyz. En bas à gauche, vous avez le lien vers la gestion de DNSSEC.)

(Ici on voit la clé KSK enregistrée par Gandi. Ceci correspond au contenu du fichier /var/ldnscripts/zones/ouaf.xyz/ksk/Kouaf.xyz.+010+39369.key. On voit le numéro de l'algorithme et le keytag qui correspondent avec le numéro du fichier.)

Pour enregistrer une nouvelle clé chez Gandi, cliquez sur "Ajouter une clé". Vous devez copier la clé publique dans la grande zone de texte Clé publique. Vérifiez aussi la correspondance avec l'algorithme.

À la fin du processus, Gandi aura calculé le DS (Condensat) de votre clé. Vous devriez vérifier qu'il correspond bien avec celui qui se trouve sur votre serveur, dans le fichier /var/ldnscripts/zones/chezmoi.tld/ksk/Kchezmoi.tld.*.ds.

7.3.3.3.2. Registre danois

On présente ici la méthode du registre danois:

(On doit copier l'empreinte DS dans le champ Digest. Les autres champs doivent bien entendu correspondre.)

(Les algorithmes compatibles avec le registre danois.)

Certains bureaux d'enregistrements vont également vous proposer de récupérer automatiquement les clés et vous demander de valider qu'il s'agit bien de celle-ci. Cette méthode est assez sûre (pas de risque d'erreur lors d'un copier-collé de votre part) mais requiert que vous soyez très attentif à ce que le bureau ne vous propose pas une autre clé (ce qui constituerait un cas d'empoisonnement du DNS). C'est par contre une méthode très sûre dans le cadre du renouvellement des clés. En effet la zone, une fois signée, est sûre et on peut récupérer et enregistrer sereinement les nouvelles clés.

Vous pouvez également envoyer vos clés publiques par courriel. Dans ce cas, prenez la précaution de signer votre courriel avec GPG ou TLS.

Quelle que soit la méthode utilisée pour enregistrer les clés sur les registres, il est fréquent que le bureau d'enregistrement vérifie automatiquement la clé avec celles qui sont publiées par votre serveur. Vous devez donc vous assurez que vos clés soient effectivement publiques avant cette étape.

Une fois qu'une clé est révoquée, l'enregistrement DS de la clé précédente peut être enlevé.

7.3.4. Ajouter un serveur DNS esclave

Que signifie ajouter un serveur DNS esclave ? Il n'y a pas là de racisme ou autre référence à une période bien sombre de l'histoire.

Il s'agit d'ajouter un serveur de nom (NS) dans votre domaine (chez le registre et dans votre zone) et le configurer pour qu'il serve lui aussi votre zone (qu'il fournisse les informations à propos de votre domaine). Il est un esclave (il obéit), mais il n'en est pas moins autoritaire (les informations qu'il délivre sont toutes aussi valables que celles que délivrerait votre premier serveur).

On parle aussi de serveur secondaire.

Ceci permet, si votre serveur principal (serveur maître) est inaccessible (coupure de réseau, le démon NSD est planté, pluie de météorites ou n'importe quelle autre raison), à votre zone d'être toujours annoncée.

Vous pouvez donc demander à un ami qui aurait un serveur de nom déjà installé (pas forcement OpenBSD, et pas forcement NSD non plus, bien que ce soit cette solution qui sera décrite) de se mettre en esclave sur votre domaine. Ou vous pouvez installer vous-même ce serveur. L'important étant qu'ils ne soient pas dans le même réseau, voire d'une manière générale, assez éloignés l'un de l'autre (quelques milliers de km constituent une bonne protection contre les coupures de réseau/d'électricité simultanées 😉).

Notez qu'il est tout à fait possible d'être maître et esclave l'un de l'autre, en échange de bons procédés.

On va décrire ici les deux côtés du système. Vous pouvez donc être l'administrateur du serveur maître, du serveur esclave, ou bien des deux à la fois. Ceci étant assez standard, il est possible d'utiliser d'autres logiciels, il suffit de lire la documentation relative et d'adapter (monter un serveur Bind secondaire, etc…).

7.3.4.1. Un peu d'authentification

Oui, je sais, c'est laborieux. En même temps, on veut faire les choses bien, non ? En l'occurrence l'authentification va permettre de garantir à nouveau que notre zone est mise à jour par le bon serveur.

Il s'agit de créer un secret partagé et identique sur les deux serveurs (maître et secondaire). Cette opération peut-être réalisée sur l'un ou l'autre serveur, voire sur un autre ordinateur.

Nous allons utiliser la commande ldns-keygen disponible dans le paquet ldns-utils que vous devriez déjà avoir installé si vous avez suivi la partie précédente. Il va nous permettre de créer une paire de clés qui contiendra un code "secret".

$ cd /tmp
$ ldns-keygen -a hmac-sha256 -b 160 chezmoi.tld

Vous avez deux fichiers créés, affichez le contenu de la clé privée :

$ cat Kchezmoi.tld.+159+54791.private
Private-key-format: v1.2
Algorithm: 159 (HMAC_SHA256)
Key: H8D/Ka9RerEtmC0jN5hSQeATxNI=

Copiez la chaîne de caractère "Key" dans la configuration de nsd pour le maître et l'esclave dans la partie secret. N'oubliez pas de préciser le bon algorithme :

key:
        name: "transfert"
        algorithm: hmac-sha256
        secret: "H8D/Ka9RerEtmC0jN5hSQeATxNI="

Le nom de la clé ("transfert ici") n'est pas important en soi, c'est juste pour se repérer.

Vous pouvez supprimer les fichiers de clé situés dans /tmp sans problème désormais.

7.3.4.2. Sur le serveur maître

Dans la configuration du serveur de nom, on rajoute deux lignes pour informer le serveur esclave qu'il doit récupérer le domaine. Pour ça, on rajoute les instructions notify et provide-xfr.

# master zone 
zone:
       name: "chezmoi.tld"
       zonefile: "signed/chezmoi.tld"  
       notify: 192.0.2.1 transfert
       provide-xfr: 192.0.2.1 transfert
       
key:
        name: "transfert"
        algorithm: hmac-sha256
        secret: "H8D/Ka9RerEtmC0jN5hSQeATxNI="

À chaque fois que la zone sera mise à jour sur votre serveur de nom, celui-ci informera le serveur à l'adresse 192.0.2.1 et la zone sera mise à jour sur ce dernier.

De nombreux services en ligne (bureau d'enregistrement notamment) vous proposent d'héberger gratuitement votre zone en esclave. Mais dans ce cas, ça ne sert à rien de les notifier : les serveurs pêchent la zone à intervalle régulier. Conservez juste le provide, sans authentification : NOKEY à la place du nom de la clé.

Pour utiliser le serveur secondaire de gandi.net, regardez cette page. On vous précise que le serveur a pour IP 217.70.177.40.

Reste plus qu'à l'indiquer dans votre zone et dans le registre (voir plus haut) que les serveurs secondaires sont bien là et fourniront l'info.

$ORIGIN chezmoi.tld.
$TTL 86400

@           IN SOA    maitre.chezmoi.tld. hostmaster.chezmoi.tld. (
                        2014110502      ;
                        86400           ; refresh
                        7200            ; retry
                        3600000         ; expire
                        172800 )        ; negative

@               IN NS       maitre.chezmoi.tld.
@               IN NS       secondaire.chezmoi.tld.
@               IN NS       autre.domaine.tld.   ; on a un autre ami 
                                                 ; qui nous aide !

maitre          IN A        192.0.2.2
                IN AAAA     2001:db8:1:1::2
                
secondaire      IN A        192.0.2.1

7.3.4.3. Sur le serveur secondaire

Il s'agit juste d'un peu de configuration:

# slave zone 
zone:
       name: "chezmoi.tld"
       zonefile: "slave/chezmoi.tld"
       allow-notify: 192.0.2.2 transfert
       request-xfr: 192.0.2.2 transfert

key:
        name: "transfert"
        algorithm: hmac-sha256
        secret: "H8D/Ka9RerEtmC0jN5hSQeATxNI="

Remarquez bien que les clés de transfert ont une configuration rigoureusement identique sur les deux serveurs.

Les fichiers de zones ne doivent pas être édités ou manipulés. Ils seront mis à jour tout seuls. Si vous voulez les faire changer de place dans le système de fichiers, éditez la configuration et relancez NSD. Ce dernier va re-télécharger la zone depuis le serveur maître et créer les nouveaux fichiers tout seul.

Vous pouvez tester la synchronisation des zones comme ceci :

$ dig -q @maitre.chezmoi.tld chezmoi.tld
$ 192.0.2.10
…
$ dig -q @secondaire.chezmoi.tld chezmoi.tld
$ 192.0.2.10

7.4. Vérifier que cela fonctionne

Vous pouvez utiliser les sites suivants pour vérifier que votre configuration fonctionne comme prévu :

8. Virtualisation

C'est de plus en plus facile de virtualiser un système dans OpenBSD grâce à vmd.

Euh, ok, mais ça veut dire quoi virtualiser ?

Pour faire fonctionner plusieurs systèmes d'exploitation, vous imaginez peut-être qu'il est nécessaire d'avoir plusieurs ordinateurs. Que nenni. Vous pouvez héberger des systèmes virtuels sur votre serveur.

Plus simplement, il vous est possible d'avoir plusieurs OpenBSD dans une OpenBSD (openbsdception 😁), comme s'il s'agissait de plusieurs machines indépendantes.

Cela présente de nombreux avantages :

Toutefois, cela consomme davantage de ressources.

Avant d'aller plus loin, afin de bien nous comprendre, il faut préciser à quoi fera référence le vocabulaire suivant :

OpenBSD nous propose trois outils pour virtualiser un système :

Avant d'aller plus loin, vérifiez si votre matériel prend en charge la virtualisation avec la commande suivante :

$ dmesg | egrep '(VMX/EPT|SVM/RVI)'

Si le résultat n'est pas vide, c'est tout bon 😁.

N'oubliez pas de mettre à jour les firmwares si besoin : # fw_update.

Activez vmd avant de passer à la suite :

# rcctl enable vmd
# rcctl start vmd

Pour ajouter une machine virtuelle, nous procéderons toujours dans l'ordre suivant :

  1. Installation d'un système dans une machine virtuelle ;
  2. Configuration de vmd pour qu'il gère cette machine.

8.1. Virtualisation d'OpenBSD

8.1.1. Installation d'une machine virtuelle

Nous allons créer en exemple une machine virtuelle avec OpenBSD dessus. Pour nous simplifier la vie, nous créons nos machines virtuelles dans le dossier /var/vm qu'il faut créer :

# mkdir /var/vm

Tout d'abord, créez une image disque de 50G par exemple :

# vmctl create /var/vm/obsdvm.qcow2 -s 50G
vmctl: qcow2 imagefile created

Vous pouvez voir qu'il y a un nouveau fichier obsdvm.qcow2 : c'est le disque de la machine virtuelle.

Maintenant, installez OpenBSD sur cete image. Deux possibilités :

Si vous avez téléchargé une image d'installation de tyle "installXX.iso":

# vmctl start openbsdvm -m 1G -L -i 1 -r installXX.iso -d /var/vm/obsdvm.qcow2

Voici la signification des diverses options :

  • vmctl start openbsdvm : on démarre la machine virtuelle en lui donnant le nom "openbsdvm" pour se repérer ensuite.
  • -m 1G : On attribue à la machine virtuelle 1G de mémoire vive ;
  • -L : Donner un accès réseau à la machine virtuelle par le biais de l'hôte ;
  • -i 1 : On configure une interface réseau ;
  • -r installXX.iso : Chemin vers l'image iso d'installation téléchargée ;
  • -d obsdvm.qcow2 : Chemin vers le disque de la machine virtuelle.

Si vous avez juste le fichier /bsd.rd :

# vmctl start openbsdvm -m 1G -L -i 1 -b /bsd.rd -d /var/vm/obsdvm.qcow2

Attention, ce type d'installation nécessite un accès à internet pour votre machine virtuelle. Configurez-le avant 😉.

Une fois votre machine virtuelle démarrée, récupérer la main sur sa console ainsi:

# vmctl console openbsdvm

L'installation d'OpenBSD se passe comme d'habitude.

Une fois l'installation terminée, choisissez "Halt" puis quittez la console de la machine virtuelle en appuyant successivement sur "~" et ".". Attention si vous utiliser une connexion SSH, il faudra alors entrer la séquence "~~." au risque de vous déconnecter de votre session SSH en même temps que la console de la machine virtuelle.

Arrêtez proprement la machine virtuelle ainsi :

# vmctl stop openbsdvm

Maintenant que l'installation est terminée, on va simplifier la gestion de la machine virtuelle.

8.1.2. Ajout de la machine virtuelle dans vmd

Laissons vmd gérer automatiquement la machine virtuelle désormais.

Éditez le fichier /etc/vm.conf qui sera lu par vmd afin de préciser quelques informations concernant la machine virtuelle :

vm "openbsdvm" {
    memory 1G
    enable
    disk /var/vm/obsdvm.qcow2
    local interface
    owner batman 
}

Veillez à bien adapter les options "disk" et "owner" selon la configuration souhaitée. "owner" permet de pouvoir gérer votre machine virtuelle en tant que simple utilisateur, sans avoir à devenir root, et ça c'est cool.

Relancez vmd pour profiter de cette configuration. Ce dernier va démarrer automatiquement la machine virtuelle. Vous pouvez toujours vous y connecter avec la commande :

vmctl console obsdvm

En somme, vmctl est toujours disponible. 😁

8.2. Accès au réseau pour une machine virtuelle

Par défaut, les machines virtuelles sont "enfermées" sur le serveur. Si vous souhaitez leur autoriser un accès à internet, quelques manipulations sont à réaliser.

Tout d'abord, ajoutez ceci dans la configuration du parefeu (/etc/pf.conf) pour autoriser le flux sortant des machines virtuelles:

match out on egress from 100.64.0.0/10 to any nat-to (egress)
# utilisation d'un resolveur DNS public
pass in quick proto { udp tcp } from 100.64.0.0/10 to any port domain \
    rdr-to 1.1.1.1 port domain

Ici, on utilise un résolveur DNS public pour les machines virtuelles. Vous voudrez sans doute modifier cette partie, notamment "1.1.1.1" par un résolveur qui vous convient davantage. Lisez la section suivante pour en savoir plus.

Si vous avez configuré votre parefeu de façon à ce qu'il bloque tout par défaut, vous devrez ajouter ceci afin d'autoriser l'interface servant à communiquer avec les machines virtuelles :

pass on tap0 from 127.0.0.1 to any
pass on tap0 from 100.64.0.0/10 to any

Si vous souhaitez que les machines virtuelles disposent de la même adresse IP publique que celle de l'hôte (votre serveur), il faut la faire suivre en indiquant dans le fichier /etc/sysctl.conf

net.inet.ip.forwarding=1
net.inet6.ip6.forwarding=1

Ainsi, les requêtes sont correctement redirigées vers (ou depuis) les machines virtuelles.

Après avoir pris en compte ces modifications, c'est tout bon 😁.

8.3. Résolveur DNS pour machine virtuelle

Dans la section précédente, on envoyait toutes les requêtes DNS des machines virtuelles vers un résolveur public. Ça fonctionnera bien, mais vous préférerez sans doute une solution "à la maison" avec unbound.

Bien sûr, vous pouvez installer et configurer unbound pour chaque machine virtuelle. Certains peuvent trouver ça contraignant (et poser quelques soucis lors d'une installation réseau qui nécessite de récupérer des fichiers distants).

On suppose par la suite que vous avez configuré unbound sur votre serveur pour qu'il résolve les noms de domaines localement.

Afin qu'unbound accepte de résoudre les noms de domaines pour les machines virtuelles, ajoutez cette petite ligne dans le fichier /var/unbound/etc/unbound.conf :

access-control: 100.64.0.0/10 allow

De cette façon, unbound voudra bien communiquer avec la plage d'IP attribuées aux machines virtuelles.

Désormais, modifier le fichier /etc/pf.conf pour indiquer de rediriger les requêtes des machines virtuelles vers unbound :

pass in quick proto { udp tcp } from 100.64.0.0/10 to any port domain \
    rdr-to 127.0.0.1 port domain

8.4. Dédier une machine virtuelle à une tâche

Vous voudrez certainement attribuer à chacune de vos machines virtuelles un rôle bien précis : l'une pour servir les sites web, une autre pour les mails… C'est bien entendu tout à fait possible, mais nécessite une configuration réseau différente de celle présentée jusqu'ici.

8.4.1. Ajout d'une interface virtuelle côté hôte

Sur votre serveur, créez une nouvelle interface de type "vether" (ethernet virtuel…)

# echo 'inet 10.0.0.1 255.255.255.0' > /etc/hostname.vether0
# sh /etc/netstart vether0

Ensuite, créez une interface de type bridge (qui fait le "pont" entre l'hôte et les machines virtuelles).

# echo 'add vether0' > /etc/hostname.bridge0
# sh /etc/netstart bridge0

Désormais, la redirection dans le parefeu se fait ainsi :

# match out on egress from 100.64.0.0/10 to any nat-to (egress) # ancienne ligne
match out on egress from vether0:network to any nat-to (egress)

# necessaire pour resolutions DNS
pass in quick proto { udp tcp } from vether0:network to any port domain \
    rdr-to 1.1.1.1 port domain

#pass on tap0 from 127.0.0.1 to any
#pass on tap0 from 100.64.0.0/10 to any
pass on vether0 from 127.0.0.1 to any
pass on vether0 from 10.0.0.0/24 to any
# ou pour ne pas s'embeter :
# pass on vether0

Afin de lancer une machine virtuelle, nous n'utiliserons plus l'option -L avec vmctl ni l'option local interface dans /etc/vm.conf. À la place, on configure une adresse bien précise pour chaque machine virtuelle dans le fichier /etc/vm.conf :

switch "my_switch" {
    interface bridge0
}

vm "openbsdvm" {
    memory 1G
    enable
    disk /var/vm/obsdvm.qcow2
    owner batman 
    interface { switch "my_switch" }
}

8.4.2. Configuration du réseau côté machine virtuelle

Sur la machine virtuelle, vous pouvez configurer une IP dans la plage 10.0.0.0/24 : c'est ce qu'on a mis dans le fichier /etc/hostname.vether0. Par exemple : "10.0.0.2", "10.0.0.3"…

La route par défaut à indiquer est 10.0.0.1. Cela donnera :

# cat /etc/hostname.vio0
inet 10.0.0.2 255.255.255.0 10.0.0.255
# cat /etc/mygate
10.0.0.1
# cat /etc/resolv.conf
nameserver 10.0.0.1

8.4.3. Redirection du trafic vers les machines virtuelles

Selon la nature de la demande, vous enverrez le flux sur la machine virtuelle concernée. Prenons l'exemple suivant :

  • La machine virtuelle dont l'adresse est 10.0.0.2 sert un site web (ports 80 et 443).
  • La machine virtuelle 10.0.0.3 doit être accessible en SSH (port 22).

Sur le serveur hôte, vous configurerez le parefeu de cette façon :

pass in on egress proto tcp from any to (egress) port { 80 443 } rdr-to 10.0.0.2
pass in on egress proto tcp from any to (egress) port 22 rdr-to 10.0.0.3

Remarquez que pour plusieurs sites web, vous voudrez plutôt utiliser relayd afin de répartir la charge.

8.5. Virtualisation de debian

La distribution GNU/Linux debian, malgré ses nombreuses qualités, ne peut malheureusement pas être installé via console série. Nous devons alors utiliser le port de qemu uniquement pour l'installation afin de simuler la présence d'un écran.

On installe donc qemu :

# pkg_add qemu

Ensuite, on télécharge debian puis on l'installe après avoir créé le disque :

$ ftp "https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-9.6.0-amd64-netinst.iso"
# vmctl create /var/vm/debian.qcow2 -s 50G
# qemu-system-x86_64 -hda /var/vm/debian.qcow2 -cdrom debian*.iso -boot d

Malheureusement, il ne semble pas exister de solution "pratique" pour réaliser l'installation de debian sans interface "graphique" (il y a bien quelques bidouilles…). Autant faire l'installation sur un ordinateur puis copier l'image "qcow2" sur votre serveur.

Il est impératif de modifier les options de démarrage de debian une fois l'installation terminée. Redémarrez sur le système puis éditer le fichier de configuration de grub (le gestionnaire de démarrage). Il s'agit du fichier /etc/default/grub où vous veillerez à avoir ces lignes :

GRUB_TIMEOUT=1
GRUB_CMDLINE_LINUX_DEFAULT=""
GRUB_CMDLINE_LINUX="console=tty1 console=ttyS0,115200"
GRUB_TERMINAL="console serial"
GRUB_SERIAL_COMMAND="serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1"

Ensuite, reconstruisez la configuration de grub :

# update-grub

Vous pouvez maintenant arrêter qemu avec la commande poweroff.

Transférez l'image debian.qcow2 sur votre serveur. Puisqu'elle est volumineuse, n'hésitez pas à la "gzipper" auparavant :

gzip debian.qcow2
scp debian.qcow2.gz batman@chezmoi.tld:~/
ssh batmanchezmoi.tld
gunzip debian.qcow2.gz
mv debian.qcow2 /var/vm/

On peut maintenant configurer la machine virtuelle sur le serveur dans /etc/vm.conf.

switch "my_switch" {
    interface bridge0
}

vm "debianvm" {
    memory 200M
    enable
    disk /var/vm/debian.qcow2
    interface { switch "my_switch" }
    owner batman
}

Et voilà, vous avez debian virtualisée par OpenBSD 😁.

8.6. Aller plus loin

  • FAQ officielle
  • openbsd.amsterdam propose des machines virtuelles et reverse une partie des gains à OpenBSD (1/6e tout de même ! 😁). Toute leur infrastructure est détaillée. Si vous le voulez, vous pouvez indiquer mon code référent (referral code) : OBSD-2609-VEXD.

9. Un VPN avec OpenIKED

OpenIKED est une implémentation libre du protocole IKEv2 qui permet de mettre en place des VPN de type IPSec. Ce protocole est très robuste et est à préférer aux plus courants PPTP ou L2TP. Pour illustrer, zhovner présente les choses ainsi 😁:

Ce protocole permet notamment de s'assurer des éléments de sécurité suivants :

Sous OpenBSD, le nom du démon qui gère les connexions IKEv2 s'appelle iked.

Dans le cadre d'un VPN, nous allons configurer un tunnel à partir de votre ordinateur (ou smartphone ou autre…) vers votre serveur. Le traffic sortira par votre serveur de manière à "cacher" l'origine des requêtes réalisées par votre ordinateur. Pour simplifier la suite, nous appelerons :

9.1. Configuration des paires de clés

Par défaut, iked utilise une identification par jeton de clés (publique/privée), un peu comme pour ssh. Vous pouvez les stocker dans des dossiers bien précis pour faciliter l'organisation (au format PEM), iked les prendra automatiquement en charge. Selon si les sources (srcid) et les destinations (dstid) sont écrites sous la forme d'adresses IP ou de noms de domaines, les clés publiques seront à enregistrer sous :

  • Identité IPv4 : /etc/iked/pubkeys/ipv4/A.B.C.D
  • Identité IPv6 : /etc/iked/pubkeys/ipv6/abcd:abcd::ab:bc
  • Identité en nom de domaine : /etc/iked/pubkeys/fqdn/foo.bar.org
  • Identité de type "adresse mail" : /etc/iked/pubkeys/ufqdn/user@foo.bar.org

Ce qui est génial, c'est qu'iked saura les retrouver comme un grand.

Dans le cadre de ce tutoriel, nous allons présenter la méthode la plus simple, à savoir se servir des clés publiques présentes par défaut sur une installation d'OpenBSD. Libre à vous de créer de nouvelles paires de clés avec la commande openssl si vous le souhaitez afin de changer l'algorithme de chiffrement. La partie privé des clés générées sera dans /etc/iked/private, mais vous l'auriez deviné tous seul 😉.

Pour l'exemple, nous allons copier les clés déjà prêtes. C'est facile de les trouver, il s'agit du fichier /etc/iked/local.pub.

  • Copiez ce fichier du client vers le serveur et placez-le à cet emplacement : /etc/iked/pubkeys/ufqdn/batman@cacahuete.tld (oui, vous pouvez mettre n'importe quelle adresse mail, du moment que vous utilisez la même dans la suite du tutoriel.
  • Ensuite, copiez le fichier local.pub qui est sur le serveur vers votre ordinateur pour le placer dans /etc/iked/pubkeys/fqdn/chezmoi.tld. Remplacez le nom de domaine, il doit correspondre à celui de votre serveur, identifié plus tard dans les configurations par srcid et dstid.

9.2. Configuration réseau

Sur le serveur et le client, activez l'interface enc0 :

# echo up > /etc/hostname.enc0
# sh /etc/netstart enc0

Ensuite, insérez dans le fichier /etc/sysctl.conf les lignes suivantes, toujours sur le serveur et le client.

net.inet.ip.forwarding=1
net.inet6.ip6.forwarding=1

Sur le serveur et le client, vous ajouterez :

net.inet.ipcomp.enable=1

Activez directement ces fonctionnalités sans avoir à redémarrer :

# for line in $(cat /etc/sysctl.conf); do sysctl $line; done

9.3. Configuration du pare-feu

Afin de pouvoir établir la liaison entre le client et le serveur, vous devez ouvrir et rediriger ports 500 (isakmp) et 4500 (ipsec-nat-t).

De plus, on redirige le traffic passant par le VPN en sortie pour qu'il apparaisse avec l'IP du serveur et non celle du client. Le fichier /etc/pf.conf du serveur ressemblera à ceci (lisez les commentaires) :

# On rassemble les paquets
set reassemble yes
# Petite precaution
antispoof quick for enc0

# Traffic VPN nat en sortie
pass out quick on egress inet received-on enc0 nat-to (egress)
# On laisse entrer le traffic IKE et IKE NAT-Traversal pour l'authentification
pass in on egress proto esp all
pass in on egress proto udp from any to any port {isakmp, ipsec-nat-t}
# On laisse passer le traffic encapsule
pass on enc0

9.4. Configuration d'IKED

Tous les fichiers iked.conf doivent avoir des droits bien choisis. Que ce soit sur le client ou le serveur, vous entrerez :

# touch /etc/iked.conf
# chmod 600 /etc/iked.conf

Avant d'aller plus loin, vous devez identifier à quoi ressemble l'IP privée du client. Par la suite, nous considérerons qu'elle est de la forme 192.168.0.n.

9.4.1. Sur le serveur

Voici le contenu du fichier /etc/iked.conf sur le serveur :

ikev2 "warrior" passive ipcomp esp \
from 0.0.0.0/0 to 192.168.0.0/16 \
peer any local <ip.publique.du.serveur> \
srcid "chezmoi.tld" 

Peut-être n'êtes-vous pas bien sûr de l'IP des clients. Vous avez la possibilité d'indiquer plusieurs plages d'IP dans le doute (si vous utilisez différents appareils aux IP différentes pour passer par le VPN) :

from 0.0.0.0/0 to 192.168.0.0/16 \
from 0.0.0.0/0 to 192.168.1.0/16 \
from 0.0.0.0/0 to 192.168.100.0/16 \

Pensez à bien modifier l'IP publique du serveur et le nom de domaine. Le paramètre srcid servira à identifier le certificat à utiliser pour l'authentification (ça peut donc aussi être une adresse IP selon ce que vous avez préféré dans l'introduction).

Tu crois t'en sortir comme ça ? Nous on veut savoir ce que ça veut dire ces trucs bizarres dans la configuration.

Et c'est parti pour un détail, ligne par ligne :

  • ikev2 "warrior" passive ipcomp esp : On définit une nouvelle politique qu'on appelle "warrior". Le serveur est passif : c'est lui qui reçoit les demandes, il ne les envoie pas. Ensuite, on active la compression du traffic (ipcomp) avec le protocole esp.
  • from 0.0.0.0/0 to 192.168.0.0/16 : Les paquets venant de n'importe où vers une interface dont l'adresse est dans la plage 192.168.0.0/16 seront encapsulés.
  • peer any local <ip.publique.du.serveur> : On précise l'IP de sortie du tunnel, pour n'importe quel pair.
  • srcid "chezmoi.tld" : très important, cela précise l'identifiant de la source : ici, c'est le nom du fichier de clé enregistré sur les clients.

9.4.2. Sur le client

La configuration est quasiment identique, mais inversée 😉

ikev2 "warrior" active ipcomp esp \
from 0.0.0.0/0 to 192.168.0.0/16 \
peer "<ip.publique.du.serveur>" \
srcid "batman@cacahuete.tld" \
dstid "chezmoi.tld"

Les paramètres auxquels vous devez être attentifs sont srcid et dstid :

  • srcid : Il s'agit du nom du fichier donné à la clé publique du client enregistré sur le serveur.
  • dstid : C'est le nom du fichier de la clé publique du serveur enregistré sur le client.

Si vous êtes perdus, retournez lire la partie sur les clés avec iked 😉.

9.5. Mise en route

C'est parti !

Sur le serveur, rechargez le parefeu et activez/démarrez iked :

# pfctl -f /etc/pf.conf
# rcctl enable iked
# rcctl start iked

Sur le client, lancez pour commencer iked sans le mettre en arrière-plan :

# iked -vvd

Vous allez voir un tas de choses s'afficher. Si vous voyez une ligne qui ressemble à la suivante, c'est tout bon 😉 :

sa_state: VALID -> ESTABLISHED from 46.23.92.147:4500 to 192.168.100.122:4500 policy 'warrior'

Par la suite, vous pourrez activer iked sur le client avec rcctl.

Pour vérifier que cela fonctionne, vous pouvez consulter un des sites permettant de connaître son IP publique. Si elle est différente de d'habitude, c'est réussi 😁. Vous pouvez plus simplement le vérifier avec la commande suivante :

# ipsecctl -sa
FLOWS:
flow esp in from 0.0.0.0/0 to 192.168.0.0/16 peer 46.23.92.147 srcid UFQDN/thuban@moria.lan dstid FQDN/reiva.xyz type use
flow esp out from 192.168.0.0/16 to 0.0.0.0/0 peer 46.23.92.147 srcid UFQDN/thuban@moria.lan dstid FQDN/reiva.xyz type require
flow esp out from ::/0 to ::/0 type deny

SAD:
esp tunnel from 46.23.92.147 to 192.168.100.122 spi 0x7958b1de auth hmac-sha2-256 enc aes-256
esp tunnel from 192.168.100.122 to 46.23.92.147 spi 0xe7d244a8 auth hmac-sha2-256 enc aes-256

En cas de problème, avant d'arrêter le processus iked, lancez la commande suivante pour fermer le tunnel :

# ikectl decouple

9.6. Utilisation avec des clients n'utilisant pas OpenBSD

Sous Linux ou avec un smartphone android, vous aurez besoin d'utiliser l'application "strongswan" pour configurer la connexion à votre VPN.

Sinon, MacOS et Windows peuvent le gérer nativement, mais il faudra demander à leurs experts.

9.7. Authentification avec certificats

Au lieu d'un jeu de clés, certaines applications nécessitent l'utilisation de certificats. C'est un peu plus compliqué, mais heureusement, les développeurs d'OpenBSD ont pensé à tout pour créer et gérer les certificats.

9.7.1. Création et partage des certificats

C'est parti !

On crée une autorité de certification qui servira à relier le client et le serveur. Pour s'y retrouver, on appellera le certificat "vpn". Changez cette valeur par ce qu'il vous plaît.

# ikectl ca vpn create

Attention, "Common Name" doit correspondre au nom de domaine du serveur. Heureusement, c'est normalement le cas par défaut si le nom de votre machine est correctement renseigné.

Un mot de passe vous est demandé. C'est normal, choisissez-en en approprié. Répondez aux autres questions sans trop vous inquiéter, ce certificat n'est que pour vous après tout.

Ensuite, ajoutez les machines qui sont censées utiliser ce certificat en créant une clé privée pour chacune. Voici la commande qui s'en charge :

# ikectl ca vpn certificate truc-a-changer create

Bien entendu, vous prendrez le temps de modifier "truc-a-changer" par soit :

  • Le nom de domaine du serveur ;
  • L'IP du serveur ;
  • L'IP du client ;
  • Votre adresse mail.

Vous pouvez lancer cette commande plusieurs fois afin d'ajouter au moins le client et le serveur :

# ikectl ca vpn certificate chezmoi.tld create # pour le serveur
# ikectl ca vpn certificate votremail@serveur.net create  # pour le client

Il est important de rester cohérent : si vous utilisez le nom de domaine, alors c'est ce dernier que vous aviez écrit dans le fichier /etc/iked.conf. Si vous y aviez indiqué des adresses IP, alors utilisez ces-dernières plutôt. En somme, il faut indiquer la même chose qu'après les mots-clés srcid et dstid précisé dans la configuration d'iked.

Notez que vous pouvez mettre un peu ce que vous voulez pour le client, même pas une "vraie" adresse mail. Pour ma part, j'ai plutôt renseigné le "hostname" de mon ordinateur, à savoir "moria.lan". C'est donc vraiment comme vous voulez, tant que ça vous permet de vous repérer (exemples : "pc.lan", "smartphone.lan", "portable.lan", …).

Ces commandes peuvent être lancées sur le serveur ou sur une autre machine utilisant OpenBSD. Si c'est lancé sur le serveur, vous pouvez directement installer ce certificat avec les commandes suivantes :

# ikectl ca vpn install
certificate for CA 'vpn' installed into /etc/iked/ca/ca.crt
CRL for CA 'vpn' installed to /etc/iked/crls/ca.crl
# ikectl ca vpn certificate chezmoi.tld install
writing RSA key

Sinon (et au moins pour le client), afin de copier ce certificat sur client et sur serveur, vous pouvez en créer une archive :

# ikectl ca vpn certificate votremail@serveur.net export 
Export passphrase:
Retype export passphrase:
writing RSA key
exported files in /home/thuban/votremail@serveur.net.tgz

Cela crée une archive votremail@serveur.net.tgz. Copiez cette archive sur client (avec scp par exemple) pour pouvoir les extraire dans le répertoire /etc/iked/ du client. :

# tar -C /etc/iked -xzpf votremail@serveur.net.tgz

Une fois les certificats installés, vous pouvez vous authentifier de la même façon qu'avec la paire de clés.

Si vous voulez savoir comment gérer plus finement ces certificats, listez le manuel d'ikectl afin de savoir comment supprimer ou révoquer un certificat par exemple.

9.7.2. Configuration d'iked

Si vous utilisez les certificats au lieu des paires de clés publiques/privées, vous devez légèrement modifier la configuration d'iked.

Tout d'abord, vous pouvez retirer toute mention de dstid de vos fichiers de configuration : ce n'est plus utile.

Ensuite, voici à quoi ressemblera la configuration côté serveur :

ikev2 "warrior" passive ipcomp esp \
from 0.0.0.0/0 to 192.168.0.0/16 \
peer any local <ip.publique.du.serveur> \
srcid "chezmoi.tld" \
psk "ceci_est_une_longue_phrase_de_pass"

Remarquez que l'on ajoute une "clé pré-partagée" (psk). Ce n'est pas obligatoire pour tous les clients, mais ça l'est pour relier deux systèmes OpenBSD entre eux.

Et pour un client utilisant lui-aussi OpenBSD :

ikev2 "warrior" active ipcomp esp \
from 0.0.0.0/0 to 192.168.0.0/16 \
peer "<ip.publique.du.serveur>" \
srcid "batman@cacahuete.tld" \
psk "ceci_est_une_longue_phrase_de_pass"

Et voilà 😉

9.8. Ressources

10. Services divers

10.1. Supervision

Il peut être intéressant de garder un œil sur la charge que le serveur subit afin d'être sûr qu'il dispose de suffisamment de ressources. Certains outils donnent un regard très précis sur votre serveur et peuvent même vous alerter automatiquement selon l'évènement détecté.

10.1.1. Avec vmstat

C'est très rapide et tout simple :

$ vmstat
 procs    memory       page                    disks    traps          cpu
 r   s   avm     fre  flt  re  pi  po  fr  sr sd0 sd1  int   sys   cs us sy id
 1 274 1500M   1253M  657   0   0   0   0   0   1   4  190 15482 1826  2  1 97

10.1.2. Avec systat

Systat est présent par défaut dans OpenBSD. Vous pouvez obtenir des informations sur le système en temps réel en saisissant la commande systat vm. Vous aurez alors des informations sur l'utilisation de la mémoire, des processeurs, des disques…

Pour avoir des informations sur le débit montant et descendant, tapez systat ifstat. Vous observerez en temps réel la quantité de données entrantes (IBYTES) et sortantes (OBYTES).

Pour des informations concernant la température du matériel (si vous craignez la surchauffe!), tapez systat sensors.

cpu0.temp0          51.00 degC
acpitz0.temp0       26.80 degC      zone temperature

À chaque fois, appuyez sur la touche q pour quitter.

10.1.3. Avec symon

Symon va vous permettre d'obtenir des statistiques sur les ressources utilisées par votre serveur et de les consulter sur une page web.

Commençons par installer le nécessaire :

# pkg_add symon symux syweb

On modifie ensuite la configuration de symon qui va surveiller le système. Pour cela, on modifie le fichier /etc/symon.conf et on garde les informations qui nous intéressent :

monitor { cpu(0),  mem,
          if(lo0),
          if(re0),
          pf,
          mbuf,
          sensor(cpu0.temp0),
          proc(httpd),
          io(wd0),
          io(wd1),
          df(sd1b)
} stream to 127.0.0.1 2100

  • cpu(0) : On surveille la charge du processeur,
  • mem : On surveille la mémoire,
  • if(re0) : On surveille l'interface web re0,
  • pf : On surveille le parefeu. Il faut mettre dans /etc/pf.conf la mention set loginterface re0,
  • mbuf : On surveille la mémoire cache,
  • sensor(cpu0.temp0) : On surveille la température du processeur,
  • proc(httpd) : On surveille l'activité du démon httpd,
  • io(wd0) : On regarde l'activité sur le disque wd0,
  • df(sd1b) : On surveille l'espace restant sur la partition sd1b.

De la même façon, on configure symux qui va analyser les données recueillies par symon. On édite le fichier /etc/symux.conf :

mux 127.0.0.1 2100

source 127.0.0.1 {
	accept { cpu(0),  mem,
		if(lo0),
		if(re0),
		pf,
		mbuf,
		sensor(cpu0.temp0),
		proc(httpd),
		io(wd0)
		io(wd1),
		df(sd1b)
	}

	datadir "/var/www/symon/rrds/localhost"
}

On ne fait que reproduire les mêmes éléments que dans /etc/symon.conf. Attention à bien indiquer le chemin vers les données datadir. On va d'ailleurs le créer dès maintenant :

# mkdir -p -m 0755 /var/www/symon/rrds/localhost

On crée maintenant les fichiers rrd :

# /usr/local/share/examples/symon/c_smrrds.sh all

Puisque le serveur web est dans un chroot, il faut lancer la commande suivante pour installer l'outil d'analyse des données (rddtool) :

# /usr/local/share/examples/rrdtool/rrdtool-chroot enable

Une fois ceci fait, il faut préciser dans la configuration de syweb où trouver l'outil rrdtool. Dans le fichier /var/www/htdocs/syweb/setup.inc, modifiez si nécessaire la ligne contenant $symon['rrdtool_path'] ainsi :

$symon['rrdtool_path']='/usr/local/bin/rrdtool';

Reste une dernière modification à apporter. Puisque le serveur web est en chroot, il faut lui donner accès au shell /bin/sh afin que PHP puisse lancer rrdtool qui génère les graphiques :

# mkdir -p /var/www/bin
# cp /bin/sh /var/www/bin

On recharge tous les nouveaux démons après les avoir activés :

# rcctl enable symon
# rcctl enable symux
# rcctl start symon
# rcctl start symux

On ajoute la configuration convenable pour le serveur http, dans le fichier /etc/httpd.conf :

server "statistiques.chezmoi.tld" {
        listen on * port 80  
        root "/htdocs/syweb"
        directory index index.php

        location "*.php*" {
                fastcgi socket "/run/php-fpm.sock"
        }
}

Reste à recharger ce dernier avec # rcctl reload httpd puis à aller sur le site définit pour voir les beaux graphiques.

10.1.4. Monit

Monit est un outil léger open source (licence AGPL) permettant de superviser un système Unix. Il est capable d’exécuter des actions en cas de détection de défaillance ou de dépassement de seuil. Une interface web permet de superviser en temps réel les différents services paramétrés.

10.1.4.1. Installation

Commençons par installer le nécessaire et activer le démon monit :

# pkg_add monit
# rcctl enable monit

10.1.4.2. Configuration

Ensuite, la configuration centrale de Monit se fait au sein du fichier monitrc localisé sous /etc/. Dans ce fichier, vous pouvez notamment modifier l’adresse email qui recevra les alertes.

Enfin, les configurations complémentaires sont dans le répertoire /etc/monit.d/.

Nous allons maintenant configurer le serveur d'administration sur un socket TCP local. Éditez le fichier /etc/monitrc puis décommentez tout en bas la ligne

include /etc/monit.d/*

Nous pouvons maintenant procéder à la configuration en ajoutant des fichiers dans le dossier /etc/monit.d qu'il faut créer :

# mkdir -p /etc/monit.d

Placez dans ce dossier un fichier que l'on appellera par exemple admin.conf.

set daemon  60 with start delay 240
set logfile syslog facility log_daemon
set mailserver localhost
set mail-format {
from: monit@$HOST
subject: Monit Alert -- $SERVICE $EVENT --
message:
Hostname:       $HOST
Service:        $SERVICE
Action:         $ACTION
Date/Time:      $DATE
Info:           $DESCRIPTION
}

set alert root@localhost

L'instruction set daemon permet de définir la durée d'un "cycle" monit. Un cycle correspond à l'intervalle (en secondes) entre deux vérifications. Dans cet exemple, il commence à analyser votre serveur toutes les minutes après un délai de 4 minutes.

Cette partie permet de préciser que monit devra enregistrer ses journaux dans les logs système. Ensuite, on configure l'apparence du mail que monit enverra à l'adresse root@localhost. Assurez-vous d'avoir fait en sorte de recevoir les mails que votre serveur est susceptible de vous envoyer.

Avant de lancer Monit, vérifiez bien que la syntaxe des fichiers de configuration est bonne avec la commande :

# monit -t

Vous devez obtenir une belle réponse « Control file syntax OK ».

En cas de dysfonctionnement, Monit vous enverra un mail d’alerte (attention à bien configurer votre mail et serveur dans le fichier monitrc).

10.1.4.3. Lancement de monit

Le démarrage de monit est simple :

# rcctl start monit

10.1.4.4. Utilisation

La commande suivante permet d'obtenir le status détaillé de votre serveur :

# monit status
Monit uptime: 0m
System 'openheb.fritz.box'
  status                       Running
  monitoring status            Monitored
  monitoring mode              active
  on reboot                    start
  load average                 [0.08] [0.11] [0.08]
  cpu                          0.1%us 0.1%sy
  memory usage                 81.1 MB [4.0%]
  swap usage                   0 B [0.0%]
  uptime                       2d 21h 30m
  boot time                    Tue, 14 Mar 2017 19:06:34
  data collected               Fri, 17 Mar 2017 16:37:25

Il est possible de consulter l'interface web de Monit sur votre serveur car il intègre un petit service http. Cependant, ce n'est pas très pratique car cela suppose que vous ouvrez les ports de votre serveur vers Monit…

À la place, je vous propose de passer par un tunnel SSH. Sur votre ordinateur de bureau, créez un tunnel qui va "relier" le port de Monit vers le port 9999 de votre ordinateur (le port d'écoute du serveur SSH est le 222 dans l'exemple) :

$ ssh -L 9999:127.0.0.1:2812 -p 222 toto@chezmoi.tld

Vous pouvez maintenant ouvrir dans un navigateur sur votre ordinateur la page http://127.0.0.1:9999 afin de consulter Monit.

10.1.4.5. Configuration avancée des alertes

Monit peut aussi envoyer des e-mails d'alerte en cas d'utilisation de ressources anormales, comme une mémoire vive faible ou un taux d'utilisation du CPU trop important.

Nous allons maintenant compléter notre configuration afin de surveiller la charge de notre serveur. Pour cela, nous allons ajouter les lignes suivantes à notre fichier de configuration:

check system localhost
    if loadavg (1min) > 4 then alert
    if loadavg (5min) > 2 then alert
    if memory usage > 75% then alert
    if swap usage > 25% then alert
    if cpu usage (user) > 70% then alert
    if cpu usage (system) > 30% then alert
    if cpu usage (wait) > 20% then alert

Puis, il faut recharger la configuration :

# rcctl reload monit

Ainsi, une alerte par courriel sera envoyée dès que le système utilisera plus de 30% des capacités du ou des processeurs.

Plus d'infos, sur le site de Monit. L'ensemble des applications de votre serveur peuvent être facilement monitorées. Regardez les exemples à la fin du document.

10.2. Synchronisation avec Syncthing

Syncthing permet de sauvegarder ses données et facilement les répartir sur plusieurs appareils. Il dispose de plusieurs clients (logiciels permettant de l'utiliser) pour Windows, Linux et même OpenBSD. Par défaut, tout est chiffré ce qui est tout de même rassurant.

Notez qu'il a été empaqueté pour OpenBSD, on peut donc l'installer en une simple commande :

# pkg_add syncthing

Nous allons le laisser tourner en arrière-plan sur notre serveur afin que vous puissiez à tout moment synchroniser vos documents et les sauvegarder. Pour cela, lancez ces commandes :

# rcctl enable syncthing
# rcctl start syncthing

Par défaut, syncthing va stocker sa configuration et les fichiers synchronisés dans /var/syncthing. Ce dossier contient :

  • Un dossier Sync qui contient tous les documents sauvegardés.
  • Un dossier .config qui contient la configuration.

Nous pourrions configurer syncthing en éditant ces fichiers, cependant, l'ajout d'autres appareils avec lesquels se synchroniser va vite devenir insupportable. Heureusement, il existe une interface d'administration pour syncthing. Elle n'est disponible qu'à partir du serveur, ce qui n'est pas pratique pour s'en servir car on a besoin d'un navigateur web pour y accéder. Cependant, SSH est là 😁.

En effet, nous allons créer un tunnel SSH qui va relier votre ordinateur au serveur. En passant par ce tunnel, nous pourrons accéder à l'interface d'administration de syncthing très facilement.

À partir de votre ordinateur, lancez la commande suivante :

ssh -N -L 9999:127.0.0.1:8384 -p 222 utilisateurssh@chezmoi.tld

Remplacez 222 par le port configuré dans la partie dédiée à ssh, tout comme l'utilisateur.

Tant que la session est ouverte, vous pouvez ouvrir un navigateur sur votre ordinateur et aller à l'adresse http://localhost:9999 afin d'administrer syncthing :

Vous pouvez maintenant ajouter des machines avec lesquelles le serveur restera synchronisé, comme si vous étiez sur le serveur.

Afin que tout fonctionne bien, vous devriez ouvrir les ports suivant dans le pare-feu :

  • Port 22000 en TCP ;
  • Port 21027 en UDP.

Je vous laisse visiter le site officiel pour éventuellement télécharger la toute dernière version du client OpenBSD et en savoir plus si vous le souhaitez.

10.2.1. Utilisation de syncthing

Partager des documents avec Syncthing est relativement simple. Pour commencer, sur l'ordinateur qui a les documents "sources", cliquez sur "Ajouter un partage" :

Choisissez ensuite un nom au partage afin de vous repérer. Laissez l'ID proposé puis précisez le chemin racine du partage. Ce chemin correspond à l'emplacement des données à sauvegarder, par exemple /home/jean-eudes/Documents. Si vous aviez déjà ajouté un appareil avec lequel partager, vous pouvez le cocher en bas :

Sinon, ajoutez l'appareil avec lequel partager vos documents. Pour cela, dans la partie "Autres appareil", cliquez sur "Ajouter un appareil" :

Il faut juste coller l'ID de l'appareil que vous pouvez trouver à l'emplacement indiqué.

L'appareil ajouté recevra une notification à accepter, et le partage peut alors commencer.

10.3. Gopher

J'en entends déjà rire en lisant ce titre. Non, le protocole gopher n'est pas mort. Bien que très peu utilisé, on y trouve encore quelques trésors. Gopher vous permettra de partager des textes et des documents tout simplement.

On dit aussi que ce protocole est très léger et permet le transfert de données même avec de minuscules bandes passantes.

Que ce soit par utilité ou par jeu, nous allons voir comment installer un serveur gopher sous OpenBSD.

Tout d'abord, on installe le serveur avec pkg_add :

# pkg_add gophernicus

Ensuite, on doit éditer le fichier /etc/inetd.conf pour y mettre la ligne suivante :

gopher stream tcp nowait _gophernicus /usr/local/libexec/in.gophernicus in.gophernicus -h chezmoi.tld

N'oubliez-pas de remplacer chezmoi.tld par votre nom de domaine puis activez et redémarrez ce service avec rcctl :

# rcctl enable inetd
# rcctl start inetd

À partir de ce moment là, il ne reste plus qu'à ouvrir et rediriger le port 70 (TCP).

Mettez vos fichiers textes, vos images, vos vidéos (…) dans le dossier /var/gopher, ils seront automatiquement disponibles à l'adresse gopher://chezmoi.tld .

Pour personnaliser un peu plus votre site, vous pouvez créer un fichier gophermap dans lequel vous déposez un message pour les visiteurs. Terminez ce fichier avec un * pour qu'il y ait une liste automatiquement générée des documents disponibles.

Par exemple :

 ____  _
| __ )(_) ___ _ ____   _____ _ __  _   _  ___
|  _ \| |/ _ \ '_ \ \ / / _ \ '_ \| | | |/ _ \
| |_) | |  __/ | | \ V /  __/ | | | |_| |  __/
|____/|_|\___|_| |_|\_/ \___|_| |_|\__,_|\___|
----------------------------------------------
                                  

*

Note : Pour accéder à un site hébergé avec le protocole gopher, vous pouvez utiliser l'extension Firefox OverbiteFF.

Un site peut alors ressembler à ça :

10.4. Seedbox

Ce chapitre décrit comment mettre en place une seedbox, afin de partager et télécharger des fichiers torrent.

10.4.1. Avec transmission

Transmission se montre très efficace et devrait convenir à la plupart de vos besoins. Il dispose d'interfaces graphiques ainsi que d'une interface dans un navigateur, ce qui le rend très facile à contrôler.

Nous configurerons transmission de façon à télécharger les torrents dans le dossier /mnt/transmission. Adaptez les chemins du tutoriel selon vos besoins.

La commande habituelle permet de l'installer :

# pkg_add transmission

On va ensuite activer le service. On le démarre puis l'arrête aussitôt afin de créer les fichiers de configurations dont on aura besoin :

# rcctl enable transmission_daemon
# rcctl start transmission_daemon
# rcctl stop transmission_daemon

Nous allons créer des dossiers spécifiques afin d'enregistrer les téléchargements effectués par transmission et stocker les fichiers .torrent :

# mkdir -p /mnt/transmission/{downloads,incomplete,torrents}

Modifiez les propriétaires de ces répertoires afin d'en autoriser l'accès à transmission :

# chown -R _transmission:_transmission /mnt/transmission

Si vous souhaitez que d'autres utilisateurs puissent consulter ces répertoires, modifiez les permissions sur ces derniers :

# chmod a+rX /mnt/transmission

Afin de configurer transmission, éditez le fichier suivant :

/var/transmission/.config/transmission-daemon/settings.json

À l'intérieur, vous pourrez adapter la configuration selon vos besoins. Voici les lignes que j'ai modifiées :

"download-dir": "/mnt/transmission/downloads",
"incomplete-dir": "/mnt/transmission/incomplete",
"incomplete-dir-enabled": true,
"peer-port-random-on-start": true,

Je vous propose d'ajouter les lignes suivantes afin que chaque fichier .torrent ajouté dans le dossier /mnt/transmission/torrents (par SFTP par exemple) soit automatiquement téléchargé par transmission.

"watch-dir": "/mnt/transmission/torrents",
"watch-dir-enabled": true

Afin de recevoir un mail lorsque le téléchargement d'un torrent est terminé, ajoutez ces lignes :

"script-torrent-done-enabled": true,
"script-torrent-done-filename": "/var/transmission/dl-done.sh",

Ce script situé à /var/transmission/dl-done.sh peut par exemple contenir ceci :

#!/bin/sh
echo "$(date) : $TR_TORRENT_NAME - Download completed." | mail -s "[transmission] - Download completed : $TR_TORRENT_NAME" toto@example.com

N'oubliez pas de rendre ce dernier exécutable :

# chmod +x /var/transmission/dl-done.sh

Une fois vos modifications terminées, rechargez la configuration de transmission avec la commande suivante :

# rcctl start transmission_daemon

Transmission dispose d'une interface web. Le plus simple afin d'y accéder est d'utiliser un tunnel SSH. À partir de l'ordinateur avec lequel vous souhaitez consulter transmission, lancez la commande suivante :

ssh -N -L 9999:127.0.0.1:9091 -p 22222 utilisateurssh@chezmoi.tld

Une fois identifié, vous pouvez ouvrir un navigateur à l'adresse http://localhost:9999/transmission/web afin d'accéder à transmission :

10.4.2. Avec rtorrent

rtorrent est un autre client efficace et très léger. Il dispose d'une interface en console pour le contrôler, que certains préfèrent à l'interface web de transmission. En effet, seul un accès SSH est nécessaire pour l'utiliser.

On commence par installer l'excellent rtorrent :

# pkg_add rtorrent

Ajoutez ensuite un utilisateur _rtorrent dont l'unique tâche sera de faire tourner rtorrent (ce n'est pas obligé, mais j'aime bien séparer les processus 😁 ).

Nous pouvons maintenant nous connecter en tant qu'utilisateur _rtorrent :

# su _rtorrent

Nous allons créer les dossiers qui serviront à télécharger les torrents, ainsi qu'un dossier dans lequel tous les fichiers .torrent ajoutés seront directement pris en charge par rtorrent :

$ mkdir -p Telechargements/{download,session,torrents}

On crée maintenant le fichier ~/.rtorrent.rc. Vous pouvez copier l'exemple fourni avec le paquet :

$ cp /usr/local/share/examples/rtorrent ~/.rtorrent.rc

On modifie la configuration selon nos besoins. Seules les lignes ne commençant pas par # sont prises en comptes. Les autres correspondent souvent aux valeurs par défaut.

# Global upload and download rate in KiB. "0" for unlimited.
download_rate = 0
upload_rate = 20

directory = ~/Telechargements/download 
session = ~/Telechargements/session

# Ajoute ou supprime les fichiers torrents present
schedule = watch_directory,5,5,load_start=~/Telechargements/torrents/*.torrent
schedule = untied_directory,5,5,stop_untied=~/Telechargements/torrents/*.torrent

# Pour utiliser les magnets, il est parfois necessaire d'ouvrir le port d'ecoute
# en tcp seulement
#port_range = 6890-6999
#port_random = no

check_hash = yes

use_udp_trackers = yes

# Ces options permettent l'utilisation des magnets
encryption = allow_incoming,try_outgoing,enable_retry

# Important pour ne pas necessiter le besoin de trackers
dht = auto

# dht_port = 6881
peer_exchange = yes

# Avertissement des chargements termines
system.method.set_key = event.download.finished,notify_me,"execute=~/.rtorrent_mail.sh,$d.get_name="

# Ajout de nœuds dht si besoin après un délai : 
schedule2 = dht_node_1, 5, 0, "dht.add_node=router.utorrent.com:6881"
schedule2 = dht_node_2, 5, 0, "dht.add_node=dht.transmissionbt.com:6881"
schedule2 = dht_node_3, 5, 0, "dht.add_node=router.bitcomet.com:6881"
schedule2 = dht_node_4, 5, 0, "dht.add_node=dht.aelitis.com:6881"

Afin d'être averti lorsqu'un téléchargement est terminé, on crée le script ~/.rtorrent_mail.sh :

#!/bin/sh
echo "$(date) : $1 - Download completed." | mail -s "[rtorrent] - Download completed : $1" root

Notez que tous les fichiers .torrents qui seront déposés dans le dossier watch seront directement téléchargés par rtorrent. Si vous voulez ajouter un fichier torrent à partir de votre ordinateur habituel, vous pouvez utiliser un client SFTP ou la commande scp :

$ scp -p <port_ssh> _rtorrent@chezmoi.tld:/home/_rtorrent/Telechargements/watch

Reste à lancer rtorrent en arrière-plan à chaque démarrage du serveur. Revenez sur le compte root (ctrl-D) puis ajoutez la commande suivante dans le fichier /etc/rc.local :

/usr/bin/su _rtorrent -c "/usr/bin/tmux new -s rtorrent -d /usr/local/bin/rtorrent"

On utilise tmux installé par défaut sur OpenBSD pour envoyer rtorrent en arrière-plan.

Si vous souhaitez administrer rtorrent par la suite, connectez-vous en SSH avec l'utilisateur _rtorrent, et affichez rtorrent avec la commande tmux a -t rtorrent. Appuyez successivement sur "ctrl-b" puis la touche d pour vous détacher de rtorrent.

Pour ajouter un lien magnet, vous pouvez appuyer sur "backspace" (effacer) puis coller le lien magnet. Il semble que certains ont besoin d'ouvrir le port d'écoute configuré dans rtorrent (en tcp) afin d'utiliser les magnets sans trackers. Avec la configuration en exemple ci-dessus, ça devrait fonctionner dans problèmes (en tout cas, chez moi ça marche bien 😁).

Si vous ne vous souvenez plus des touches permettant de contrôler rtorrent, saisissez cette commande :

$ rtorrent -h
Rakshasa's BitTorrent client version 0.9.6.

All value pairs (f.ex rate and queue size) will be in the UP/DOWN
order. Use the up/down/left/right arrow keys to move between screens.

Usage: rtorrent [OPTIONS]… [FILE]… [URL]…
  -h                Display this very helpful text
  -n                Don't try to load ~/.rtorrent.rc on startup
  -b <a.b.c.d>      Bind the listening socket to this IP
  -i <a.b.c.d>      Change the IP that is sent to the tracker
  -p <int>-<int>    Set port range for incoming connections
  -d <directory>    Save torrents to this directory by default
  -s <directory>    Set the session directory
  -o key=opt,…    Set options, see 'rtorrent.rc' file

Main view keys:
  backspace         Add a torrent url or path
  ^s                Start torrent
  ^d                Stop torrent or delete a stopped torrent
  ^r                Manually initiate hash checking
  ^q                Initiate shutdown or skip shutdown process
  a,s,d,z,x,c       Adjust upload throttle
  A,S,D,Z,X,C       Adjust download throttle
  I                 Toggle whether torrent ignores ratio settings
  right             View torrent

Download view keys:
  spacebar          Depends on the current view
  1,2               Adjust max uploads
  3,4,5,6           Adjust min/max connected peers
  t/T               Query tracker for more peers / Force query
  *                 Snub peer
  right             View files
  p                 View peer information
  o                 View trackers

Report bugs to <sundell.software@gmail.com>.

Notez que ^s correspond à Ctrl-s.

10.5. Serveur d'impression

Nous allons voir dans ce chapitre comment relier une imprimante au serveur et la rendre accessible afin de pouvoir imprimer de n'importe où depuis le réseau local. Ça peut être très pratique pour convertir une imprimante USB en imprimante sans-fil.

On commence par installer cups et des pilotes d'imprimante :

# pkg_add cups cups-filters gutenprint foomatic-db

Pensez à ouvrir dans le parefeu le port 631 (ipp). Pour un réseau local, inutile de le rediriger dans le routeur.

Maintenant, il faut autoriser l'accès à distance à l'interface d'administration de l'imprimante (à moins que vous ne réalisiez toute la configuration directement sur le serveur avec un navigateur en mode console comme w3m ou lynx). Pour cela, modifiez de cette façon le fichier /etc/cups/cupsd.conf :

Listen 0.0.0.0:631
Listen /var/run/cups/cups.sock

# Restrict access to the server…
<Location />
Order deny,allow
Deny From All
Allow From 192.168.1.*
Allow From 127.0.0.1
Allow From @LOCAL
</Location>

Quelques explications :

  • Deny From All : on interdit l'accès à tout le monde avant d'ajouter des exceptions.
  • Allow From 192.168.1.* permet à tous les ordinateurs locaux dont l'adresse IP est de ce type de se connecter au serveur. (* veut dire n'importe quel chiffre). Pour connaître cette IP, référez-vous au paragraphe qui explique ceci en détail.
  • Allow From 127.0.0.1 permet l'accès en local. En fait, cette adresse est la même chose que “localhost”.

On active ensuite cups, puis on le démarre :

# rcctl enable cupsd
# rcctl start cupsd

Maintenant, reliez votre imprimante sur le serveur. Ouvrez un navigateur à l'adresse suivante : http://localhost:631. Sur un serveur, cela peut être avec w3m, un navigateur en console. Sinon utilisez votre ordinateur de bureau, et indiquez l'adresse locale du serveur à la place de localhost. Cela donnerait quelque chose comme http://192.168.1.2:631.

Pour installer l'imprimante, allez dans “Administration, Ajouter une imprimante” puis suivez les indications. Si le modèle de votre imprimante n'est pas dans la liste, choisissez la version la plus proche.

Important : n'oubliez pas de cocher la case "Partager cette imprimante".

Finalement, vous pouvez ajouter cette imprimante sur les ordinateurs qui auront besoin d'y accéder. Ouvrez un navigateur sur votre ordinateur puis allez à l'adresse http://localhost:631/admin. Suivez la procédure d'installation d'imprimante, mais cette fois choisissez “Internet Printing Protocol (http)”. Vous devez entrer l'adresse de l'imprimante.

Pour la trouver, affichez l'interface de CUPS du serveur, puis cliquez en haut à droite sur “Imprimantes” et cliquez sur le nom de l'imprimante fraîchement installée. Notez l'adresse qui est du type http://192.168.1.2:631/printers/HL2130.

Vous devrez alors pour l'installer sur un ordinateur préciser une URL de ce type :

ipp://192.168.1.2:631/printers/Brother_HL-2130_series

Cliquez sur “Continuer” et terminez l'installation. Et voilà, votre serveur d'impression est prêt.

Pour plus d'information, notamment pour les services de découverte automatique, vous pouvez consulter la documentation sur le wiki obsd4a

10.5.1. Note à propos des imprimantes USB

La gestion des imprimantes USB sous OpenBSD est un peu particulière. Comme décrit dans /usr/local/share/doc/pkg-readme/cups*, il faut autoriser l'accès au port USB pour l'utilisateur cups. Tapez alors la commande usbdevs -v. Vous obtenez une sortie de ce type :

# usbdevs -v
Controller /dev/usb0:
addr 1: high speed, self powered, config 1, EHCI root hub(0x0000), Intel(0x8086), rev 1.00
  uhub0
 port 1 addr 2: high speed, self powered, config 1, Rate Matching Hub(0x0024), Intel(0x8087), rev 0.00
   uhub2
  port 1 powered
  port 2 addr 3: low speed, power 100 mA, config 1, USB Mouse(0x1205), Genesys Logic(0x05e3), rev 1.00
    uhidev0
  port 3 powered
  port 4 powered
  port 5 powered
  port 6 powered
 port 2 powered
Controller /dev/usb1:
addr 1: high speed, self powered, config 1, EHCI root hub(0x0000), Intel(0x8086), rev 1.00
  uhub1
 port 1 addr 2: high speed, self powered, config 1, Rate Matching Hub(0x0024), Intel(0x8087), rev 0.00
   uhub3
  port 1 addr 3: high speed, self powered, config 1, HL-2130 series(0x003f), Brother(0x04f9), rev 1.00, iSerialNumber E2N507126
    ugen0

On remarque que l'imprimante (Brother) est identifiée par ugen0 sur le contrôleur /dev/usb1. Pour permettre à cups d'accéder à l'imprimante on lance la commande suivante :

# chown _cups /dev/ugen0.* /dev/usb1

Afin que ces modifications soient automatiques à chaque fois que l'imprimante est reliée au serveur, installez le démon hotplugd puis activez-le :

# pkg_add hotplug-diskmount
# rcctl enable hotplugd
# rcctl start hotplugd

Créez maintenant le script /etc/hotplug/attach pour y mettre :

#!/bin/sh

DEVCLASS=$1
DEVNAME=$2

case $DEVCLASS in
0)
    if [ -n "$(echo $DEVNAME | grep -o "ugen[0-9]")" ]; then
        DEVDESCR=$(usbdevs -v | grep -B1 $DEVNAME | sed -Ee 's/ addr [0-9]+: (.+)$/\1/' -e 1q)
        if [ "${DEVDESCR}" == "HL-2130 series, Brother" ]; then
            chown _cups /dev/${DEVNAME}.* /dev/usb1
        fi
    fi
;;
2)
	# disk devices
	echo "Things for disks"
;;
esac

exit

Si votre imprimante n'était pas identifiée par quelque chose comme "ugen1" mais "ulpt", alors il faut modifier la configuration du noyau pour désactiver ce module. Cela se fait ainsi :

# config -fe /bsd                                   
OpenBSD 6.2-stable (GENERIC.MP) #1: Fri Sep  2 10:41:52 CEST 2016
    root@chezmoi.tld: /usr/src/sys/arch/amd64/compile/GENERIC.MP
Enter 'help' for information
ukc> disable ulpt
291 ulpt* disabled
ukc> quit
Saving modified kernel.

Un redémarrage du serveur est nécessaire pour prendre les changements en compte.

10.6. TOR

Tor est un logiciel libre permettant de renforcer la vie privée de ses utilisateurs et ainsi passer outre les surveillances subies lors de l'utilisation d'Internet. Lorsqu'on l'utilise, les communications sont réparties à travers une maille de serveurs, afin d'obtenir un onion router. En gros, ce que vous demandez sur le web circule entre une série de serveurs (les couches de l'oignon), ce qui rend très difficile de savoir d'où viennent les paquets, et donc de vous localiser!

10.6.1. Configurer un relais

Il vous est possible de participer à ce réseau en étant un serveur relais. Qui plus est, cela rendra d'autant plus difficile de déterminer vos propres activités, puisque vos centres d'intérêt seront noyés parmi le trafic sortant de votre connexion.

Tor peut avoir besoin d'ouvrir de nombreuses connexions. Réduire les limitations peut alors être une bonne idée. Ajoutez dans le fichier /etc/sysctl.conf

kern.maxfiles=20000

Installez et activez Tor ainsi :

# pkg_add tor
# rcctl enable tor

Assurez-vous d'ouvrir dans votre pare-feu, et de rediriger dans votre routeur le port 9001.

Ensuite, éditez le fichier /etc/tor/torrc , afin d'obtenir ces quelques lignes :

SOCKSPort 0
ORPort 9001
Nickname Surnom
RelayBandwidthRate 75 KB  
RelayBandwidthBurst 100 KB 
ContactInfo votrenom <adresse AT email dot fr>
ExitPolicy reject *:* # no exits allowed

Modifiez les valeurs pour RelayBandwidthRate et RelayBandwidthBurst selon votre accès à Internet. Il s'agit de la bande passante que vous laissez disponible pour Tor. C'est une bonne idée de préciser votre adresse mail aussi.

Enfin, démarrez Tor avec rcctl start tor et attendez de voir apparaître dans le fichier /var/log/messages :

May 12 12:20:41 chezmoi Tor[12059]: Bootstrapped 80%: Connecting to the Tor network
May 12 12:20:41 chezmoi Tor[12059]: Bootstrapped 85%: Finishing handshake with first hop
May 12 12:20:42 chezmoi Tor[12059]: Bootstrapped 90%: Establishing a Tor circuit
May 12 12:20:44 chezmoi Tor[12059]: Tor has successfully opened a circuit. Looks like client functionality is working.
May 12 12:20:44 chezmoi Tor[12059]: Bootstrapped 100%: Done
May 12 12:20:44 chezmoi Tor[12059]: Now checking whether ORPort 109.190.xxx.xxx:9001 is reachable… (this may
take up to 20 minutes -- look for log messages indicating success)
May 12 12:21:10 chezmoi Tor[12059]: Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
May 12 12:21:12 chezmoi Tor[12059]: Performing bandwidth self-test…done.

10.6.2. Configurer un service caché

Vous pouvez proposer votre site web (ou n'importe quel autre service) au travers du réseau Tor. Ceux qui voudront y accéder utiliseront une adresse se terminant par ".onion", comme "5rud2tr7sm3oskw5.onion".

Avant d'aller plus loin, notez qu'il est très fortement déconseillé d'héberger un relais et un service caché en même temps.

Ceci étant dit, vous pouvez activer votre site caché en éditant le fichier /etc/tor/torrc. Décommentez les lignes correspondantes ou ajoutez-les :

SOCKSPort 0
HiddenServiceDir /var/tor/hidden/
HiddenServicePort 80 127.0.0.1:80

Relancez Tor pour activer ce service caché : rcctl restart tor. Deux nouveaux fichiers vont apparaître dans le dossier /var/tor/hidden/ : "hostname" et "private_key". L'adresse de votre site en .onion se trouve dans le fichier hostname. Notez-la :

# cat /var/tor/hidden/hostname
5rud2tr7sm3oskw5.onion

Cependant, ne communiquez jamais le contenu de private_key.

Il ne nous reste plus qu'à configurer httpd pour lui dire de recevoir les connexions vers l'adresse en ".onion" et de les servir. Le fichier /etc/httpd.conf pourra alors contenir ceci :

server "5rud2tr7sm3oskw5.onion" {
        listen on 127.0.0.1 port 80
        # emplacement du site
        root "/htdocs/chezmoi.tld"     
        directory index index.html

        […]
}

Vous pouvez tester votre site (après un rcctl reload httpd bien sûr) avec le navigateur torbrowser.

Mais, ce n'est pas chiffré dans une adresse https! Est-ce vraiment sécurisé?

Bonne remarque. Le chiffrement TLS n'est pas nécessaire ici, puisque le tunnel ouvert par Tor pour accéder au site est entièrement chiffré. De plus, le navigateur devrait valider le certificat, or, ce dernier n'est pas enregistré pour un domaine en ".onion". Notez que si vous pouvez obtenir un certificat pour cette adresse, c'est alors possible de configurer un accès en https.

10.7. Serveur de stockage

Aussi appelé NAS, ces serveurs permettent de stocker et partager des fichiers dans un réseau domestique.

Pour mettre en place cette fonctionnalité, nous verrons deux solutions : l'une basée sur SSH et l'autre sur NFS.

10.7.1. Solution du fainéant : SSH

Si vous avez déjà configuré SSH, vous pouvez utiliser l'outil sshfs ( déjà évoqué plus haut) qui permet de monter dans un dossier les fichiers contenus sur le serveur, un peu comme avec une clé USB. Cette solution fonctionnera quel que soit l'endroit qui vous sert de point d'accès à Internet et restera sûr.

Admettons que vous souhaitez monter le dossier /mnt/partage du serveur dans votre dossier /home/toto/serveur. Vous utiliserez alors la commande suivante

sshfs utilisateur_ssh@chezmoi.tld:/mnt/partage /home/toto/serveur

On demandera le mot de passe de l'utilisateur connecté via SSH, ensuite vous pourrez voir les documents du serveur dans /home/toto/serveur comme s'ils étaient sur votre ordinateur.

Notez que ce n'est pas toujours pratique d'avoir à entrer le mot de passe, surtout lorsqu'on souhaite que le dossier du serveur soit monté automatiquement à chaque démarrage. Vous pouvez dans ce cas consulter l'authentification par clés.

10.7.2. Solution un peu plus compliquée : NFS

NFS veut dire "Network File System", autrement dit "Système de fichiers en réseau".

Cependant, nous n'allons pas ouvrir le partage NFS au monde entier comme on peut le faire pour d'autres services, car nous ne pouvons pas restreindre l'accès à certains utilisateurs. L'utilisation de NFS sera donc adaptée à un partage local, c'est à dire pour toutes les machines utilisant votre routeur pour se connecter.

Tout d'abord, nous devons activer sur le serveur les services nécessaires. On s'en occupe avec rcctl :

# rcctl enable portmap mountd nfsd

Afin que le partage NFS fonctionne comme prévu, nous allons configurer les options pour le lancer. Remplacez dans la commande ci-dessous le chiffre 4 par le nombre de connexions maximales vers le serveur que vous souhaitez :

# rcctl set nfsd flags -tun 4

Nous avons activé ici les protocoles TCP (-t), UDP (-u), ainsi que 4 connexions maximales vers le serveur NFS.

Maintenant, il faut préciser qui aura le droit d'accéder au NFS. Pour cela, il faut éditer le fichier /etc/exports pour préciser les adresses IP qui pourront s'y connecter. Éditez ce fichier pour y mettre par exemple :

/mnt/partage -alldirs -network=192.168.1 -mask=255.255.255.0 

Ici, nous souhaitons restreindre l'accès au réseau local, c'est à dire tous les appareils connectés à la même *box que votre serveur. La difficulté ici est de connaître l'ensemble des adresses IP que votre modem attribue aux appareils qui s'y connectent. Suivez les indications de ce paragraphe pour mieux comprendre comment trouver l'IP locale des machines connectées à votre *box.

Si vous souhaitez accéder à ce partage de n'importe où, retirez les options -network et -mask. Cependant, notez bien que cela donnera accès au NFS à tout le monde.

On peut maintenant démarrer les services avec :

# rcctl start portmap mountd nfsd

Dans le cas où vous modifiez le fichier /etc/exports, pensez à recharger la configuration avec :

# rcctl reload mountd

Pensez à ouvrir les ports 111 et 2049 en TCP et UDP dans le parefeu afin qu'une machine du réseau local puisse accéder au partage NFS. Pour voir la liste des ports utilisés, lancez # rpcinfo -p 127.0.0.1. Ces ports peuvent changer lors d'un redémarrage. Pour un partage local, vous pouvez ouvrir votre NAS à tout le réseau local avec cette ligne dans /etc/pf.conf :

pass in on egress from 192.168.1.0/24

Vous pourrez maintenant monter le partage NFS sur votre système. La démarche dépend du système d'exploitation, mais dans la plupart des cas, ajouter une entrée dans le fichier /etc/fstab de l'ordinateur qui doit monter le NFS suffit. Cette entrée ressemblera à :

192.168.1.2:/mnt/partage /mnt nfs rw,nodev,nosuid 0 0

Remplacez l'IP par celle du serveur bien sûr 😉 .

10.8. Radio Web

Dans cette partie, nous allons voir comment proposer une radio web sans prendre toutes les ressources du serveur.

L'idéal serait de pouvoir diffuser des émissions en direct. Lorsque personne ne parle sur la radio, de la musique sera automatiquement jouée à partir d'une liste de lecture.

Nous allons utiliser les outils icecast et mpd.

10.8.1. Configuration d'icecast et mpd

Commençons par les installer :

# pkg_add icecast mpd

On va copier l'exemple de configuration d'icecast avant de l'éditer :

# cp /usr/local/share/examples/icecast/icecast.xml.dist /var/icecast/icecast.xml

Configurez ce fichier à votre goût. Voici un exemple de ce que j'ai modifié :

<location>Sur Mars</location>

<authentication>
	<source-password>motdepasse</source-password>
	<relay-password>motdepasse</relay-password>

	<admin-user>admin</admin-user>
	<admin-password>adminpw</admin-password>
</authentication>

<hostname>chezmoi.tld</hostname>
<!-- You may have multiple <listener> elements -->
<listen-socket>
	<port>8000</port>
	<bind-address>0.0.0.0</bind-address>
</listen-socket>

<mount>
    <mount-name>/play.ogg</mount-name>
    <no-mount>1</no-mount>
</mount>
<mount>
    <mount-name>/live.ogg</mount-name>
    <fallback-mount>/play.ogg</fallback-mount>
    <fallback-override>1</fallback-override>
</mount>

On voit bien dans cette configuration que lorsqu'un "live" est en cours, il est diffusé, sinon ça bascule automatiquement sur la playlist.

On active icecast puis on le lance :

# rcctl enable icecast
# rcctl start icecast

Ensuite, nous allons configurer le lecteur de musique, qui sera ici mpd. Éditez le fichier /etc/mpd.conf de cette façon :

# Dossier contenant toute la musique
music_directory      "/mnt/bigstorage/Musique"

# Pour icecast. Pensez à modifier le mot de passe
audio_output {
    type        "shout"
    encoding    "ogg"
    name        "Ma super radio"
    host        "localhost"
    port        "8000"
    mount       "/play.ogg"
    password    "motdepasse"
    bitrate     "128"
    format      "44100:16:2"
}

Je n'ai listé ci-dessus seulement ce que j'ai eu besoin de modifier. Changez bien le mot de passe pour envoyer la musique à icecast.

Enfin, activez mpd et lancez-le :

# rcctl enable mpd
# rcctl start mpd

Vous pouvez lancer la lecture en utilisant un client mpd, comme mpc. Il s'installe tout simplement :

# pkg_add mpc

Voici quelques commandes bien pratiques :

  • Lecture : mpc play
  • Remplir la liste d lecture avec toutes les musiques : mpc ls | mpc add
  • Lecture aléatoire : mpc random on
  • Lecture en boucle : mpc repeat on
  • Fondu entre les pistes : mpc crossfade 3

Avant d'essayer d'écouter votre musique, ouvrez et redirigez le port 8000 dans votre pare-feu et routeur.

Pour tester votre radio, ouvrez l'adresse suivante avec un lecteur de musique (vlc par exemple) : http://chezmoi.tld:8000/live.ogg.

10.8.2. Diffuser une émission

Afin de diffuser une émission, il faudra utiliser n'importe quel logiciel capable de communiquer avec icecast. La seule différence sera que l'on diffusera sur "/live.ogg" directement et non plus sur "/play.ogg".

Si vous souhaitez faire des podcasts, je vous conseille l'excellent logiciel idjc.

En attendant, prenons pour exemple vlc qui va jouer ce que vous voulez pour l'envoyer sur le serveur.

Une fois vlc ouvert, cliquez sur "Media" > "Flux". Ajoutez un fichier puis cliquez sur diffuser.

Cliquez sur "Next", puis choisissez dans "Nouvelle destination" "IceCast". Cliquez sur "Ajouter".

Remplissez ensuite les différents champs :

  • Adresse : chezmoi.tld
  • Port utilisé : 8000 par défaut
  • Point de montage : /live.ogg
  • Utilisateur:mot de passe : source:votremotdepasse

    L'utilisateur ici est source, à moins d'avoir modifié le fichier de configuration sur ce point.

Vous pouvez activer le transcodage si vous le souhaitez. Audio Vorbis (OGG) fonctionne bien en général. Il vous reste à valider la suite.

10.8.3. Montrer en ligne ce qui est joué

Vous voudrez peut-être afficher sur votre site web ce que la radio est en train de jouer. Mettez alors ceci dans /var/icecast/web/all.xsl

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="xml"/>
<xsl:template match="*">
<xsl:copy-of select="."/>
</xsl:template>
</xsl:stylesheet>

Ensuite, dans un fichier /var/icecast/web/onair.xsl, mettez :

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="text"/>

<xsl:template match="/icestats">
<!-- only show the first source -->
<xsl:apply-templates select="source[1]"/>
</xsl:template>

<xsl:template match="source">
<xsl:choose>
<xsl:when test="title or artist">
<xsl:if test="artist"><xsl:value-of select="artist" /> - </xsl:if>
<xsl:value-of select="title" />
</xsl:when>
<xsl:otherwise>Unknown</xsl:otherwise>
</xsl:choose>
</xsl:template>

</xsl:stylesheet>

Les personnes allant sur http://chezmoi.tld:8000/onair.xsl pourront voir ce qui est joué. Dans votre code html, il suffirait alors de rajouter ceci pour l'afficher sur une page:

<h3>Now playing</h3>
<iframe id="icecast" src="http://chezmoi.tld:8000/onair.xsl">
</iframe>
<audio src="http://chezmoi.tld:8000/live.ogg" controls="controls"></audio>

10.9. Vidéosurveillance

Que ce soit pour diffuser en direct une vidéo, observer des animaux sans les déranger ou découvrir lequel de vos enfants se lève la nuit pour finir le pot de confiture, vous avez l'embarras du choix pour mettre en place de la "vidéosurveillance".

Ici, on va décrire quelques méthodes de façon non-exhaustive. Pour l'exemple, c'est une webcam USB qui est utilisée.

10.9.1. Captures régulières avec fswebcam

fswebcam est un logiciel capable de prendre des photos avec votre webcam. Simple mais efficace.

Pour l'installer, on lance comme d'habitude :

# pkg_add fswebcam

La commande suivante permet d'enregistrer une image toutes les minutes (60 secondes) :

while true; do fswebcam -r 1280x960 --save "/tmp/webcam-$(date +%Y-%m-%d-%H-%M-%S).jpg

Si vous vous placez dans un dossier accessible par httpd par exemple plutôt que dans /tmp, vous pourrez consulter ces images à distance. Sinon, récupérez-les avec filezilla.

Si la capture échoue, vérifiez les permissions pour /dev/video0 (ou l'équivalent pour votre webcam)

# chmod 666 /dev/video0

10.9.2. Détecteur de mouvements avec motion

Le paquet motion contient de quoi prendre en photo ce qui bouge devant votre webcam, sinon la garder éteinte. De plus, il diffuse sur une page web spéciale les images prises ce qui donne l'effet d'une vidéo.

Installez le paquet motion puis copiez l'exemple de configuration fourni après avoir créé le dossier de configuration :

# mkdir -p /etc/motion
# cp /usr/local/share/examples/motion/motion-dist.conf /etc/motion/motion.conf

Éditez ce nouveau fichier pour l'adapter à vos besoins. Pour ma part, je n'ai eu à modifier que les lignes suivantes :

width 1280
height 960
auto_brightness on

# sensibilite du detecteur avant de capturer
threshold 500

ffmpeg_video_codec mp4

target_dir /var/motion
ipv6_enabled true

stream_localhost off
stream_auth_method 2

# Changer les identifiants
stream_authentication utilisateur:motdepasse 

webcontrol_port 0

On crée un utilisateur _motion pour séparer les privilèges.

# useradd -s /sbin/nologin _motion

Vérifiez que le dossier qui servira à enregistrer les images existe bien et est accessible par l'utilisateur _motion:

# install -d -o _motion /var/motion/

Vous êtes maintenant en mesure de lancer motion :

# rcctl enable motion
# rcctl start motion

Par défaut, le flux est disponible à l'adresse : http://votreserveur:8081. Pensez à ouvrir le port 8081 avant d'y aller.

Notez que si vous ne souhaitez pas garder en mémoire les enregistrements, vous pouvez mettre ces options :

snapshot_filename lastname
picture_filename motioncapture

En cas d'erreur dans /var/log/messages, vérifiez les permissions sur la webcam qui doit être accessible en lecture et écriture :

# chmod 666 /dev/video0

10.9.3. Streaming avec ffmpeg

ffmpeg est un excellent outil. Il nécessite de bonnes performances matérielles mais donnera des vidéos de qualité.

Pour l'installer, vous connaissez la chanson :

# pkg_add ffmpeg

Tout d'abord, nous avons besoin d'en savoir un peu plus sur notre webcam. Après l'avoir branchée, tapez dmesg pour voir par exemple :

uvideo0 at uhub2 port 2 configuration 1 interface 0 "Logitech product 0x0825" rev 2.00/0.12 addr 3
video0 at uvideo0

Cela nous indique que la webcam est disponible via /dev/video0. Afin de pouvoir s'en servir sans être super-utilisateur, modifiez les permissions :

# chmod 666 /dev/video0

Une fois que ceci est connu, nous avons besoin de savoir quels formats propose notre webcam. Tapez alors ceci :

$ ffmpeg -f v4l2 -list_formats all -i /dev/video0

Vous obtiendrez un résultat comme :

[video4linux2,v4l2 @ 0x2d76dd93800] Raw       :     yuyv422 :                 YUYV : 640x480 160x120 176x144 320x176 320x240 352x288 432x240 544x288 640x360 752x416 800x448 800x600 864x480 960x544 960x720 1024x576 1184x656 1280x720 1280x960
[video4linux2,v4l2 @ 0x2d76dd93800] Compressed:       mjpeg :                MJPEG : 640x480 160x120 176x144 320x176 320x240 352x288 432x240 544x288 640x360 752x416 800x448 800x600 864x480 960x544 960x720 1024x576 1184x656 1280x720 1280x960

Cela nous indique la liste des résolutions possibles et les formats vidéos associés.

Maintenant, nous allons configurer le serveur qui va se charger de diffuser la vidéo.

Copions le fichier de configuration dans /etc/ffserver.conf :

# cp /usr/local/share/examples/ffmpeg/ffserver.conf /etc/ffserver.conf

Nous pouvons maintenant éditer ce fichier pour l'adapter à nos besoins. Je recopie ci-dessous le fichier sans les commentaires :

HTTPPort 8090
HTTPBindAddress 0.0.0.0
MaxHTTPConnections 2000
MaxClients 1000
MaxBandwidth 1000
CustomLog -

<Feed feed1.ffm>               
   File ./feed1.ffm           
   FileMaxSize 1G              
   ACL allow 127.0.0.1        # Acces seulement en local à ce fichier 
</Feed>

<Stream webcam.webm>       		
   Feed feed1.ffm              
   Format webm
   # Audio settings
   NoAudio
   # Video settings
   VideoCodec libvpx
   VideoSize 320x240           # Video resolution
   VideoFrameRate 25           # Video FPS
   AVOptionVideo flags +global_header  
   AVOptionVideo cpu-used 0
   AVOptionVideo qmin 5
   AVOptionVideo qmax 35
   AVOptionAudio flags +global_header
   PreRoll 15
   StartSendOnKey
</Stream>

<Stream status.html>     		# Server status URL
   Format status
   # Only allow local people to get the status
   ACL allow localhost
   ACL allow 192.168.0.0 192.168.255.255
</Stream>

<Redirect index.html>    # Just an URL redirect for index
   # Redirect index.html to the appropriate site
   URL http://www.ffmpeg.org/
</Redirect>

Notez que le serveur écoute par défaut sur le port 8090, il faudra donc penser à l'ouvrir dans le parefeu.

Afin de lancer la diffusion, saisissez la commande suivante :

ffmpeg -f v4l2 -video_size 320x240 -i /dev/video0 http://localhost:8090/feed1.ffm

Pour regarder votre flux, ouvrez un navigateur à l'adresse suivante :

http://chezmoi.tld:8090/webcam.webm

Pour obtenir des informations sur le flux, Vous pouvez aussi consulter la page http://chezmoi.tld:8090/status.html

11. Remarques complémentaires sur le système

11.1. Notes et astuces diverses

Ces informations sont à lire dans le désordre selon vos besoins.

N'hésitez pas à compléter cette lecture avec le wiki français d'obsd4a.net, notamment la traduction en français de la FAQ.

11.1.1. Comment on devient "root" ou "superutilisateur" ?

Entrez la commande su puis le mot de passe de l'utilisateur root.

11.1.2. Historique des commandes

Pour retrouver l'historique des commandes avec ctrl-R, c'est très rapide.

Vous pouvez l'activer en ajoutant export HISTFILE=~/.history dans le fichier ~/.profile :

$ echo "export HISTFILE=~/.history" >> ~/.profile

Au prochain login, l'historique sera actif.

11.1.3. Que faire en cas de problème?

Un service ne veut plus démarrer? Votre site web n'est plus accessible? Voici quelques astuces :

  • Un service ne démarre plus : vous pouvez lancer ce service manuellement et voir les messages d'erreurs qu'il retourne. Par exemple, avec httpd, vous pouvez saisir cette commande pour avoir plus d'informations : rcctl -d start httpd.
  • Aller voir dans le dossier /usr/local/share/doc/pkg-readmes s'il y a des précisions sur le programme posant problème.

  • Si c'est un paquet qui ne veut pas correctement s'installer, utilisez la commande pkg_check qui va nettoyer votre installation.
  • Consultez les journaux du système avec la commande tail :
    # tail -f /var/log/messages /var/log/daemon
    

    Pour un site web :
    # tail -f /var/www/logs/*
    

    Pour un problème d'identification :
    # tail -f /var/log/authlog
    

  • Lancez la commande dmesg qui peut vous donner une information sur un périphérique.
  • Si c'est le pare-feu qui pose problème, vous pouvez analyser le trafic avec tcpdump : tcpdump -n -e -ttt -i pflog0.
  • Bien sûr, lire le man de la commande problématique.
  • Demander de l'aide sur la liste de diffusion.
  • Demander de l'aide sur le forum OBSD4*.

11.1.4. Comment trouver mon interface réseau ?

Afin de trouver le nom de votre interface réseau (le câble ethernet par exemple), on saisit la commande ifconfig. Prenez le temps de lire le retour de cette commande, votre interface doit avoir une adresse attribuée que vous pouvez lire après le mot inet, et appartient certainement au groupe egress.

Par exemple :

$ ifconfig                                                   
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 32768
        priority: 0
        groups: lo
        inet 127.0.0.1 netmask 0xff000000
re0: flags=218843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,MPSAFE,AUTOCONF6> mtu 1500
        lladdr fc:aa:14:65:5f:86
        priority: 0
        groups: egress
        media: Ethernet autoselect (100baseTX full-duplex,rxpause,txpause)
        status: active
        inet 192.168.1.2 netmask 0xffffff00 broadcast 192.168.1.255
enc0: flags=0<>
        priority: 0
        groups: enc
        status: active
pflog0: flags=141<UP,RUNNING,PROMISC> mtu 33144
        priority: 0
        groups: pflog

Ici, lo0 ne nous intéresse pas. C'est l'interface dite "locale", utilisée par certains programmes pour communiquer entre eux au sein du serveur. enc0 et pflog0 ne nous intéressent pas non plus ici.

Reste re0 qui est notre interface réseau ethernet.

11.1.5. Comment créer un utilisateur ?

Créer des utilisateurs peut vous servir à plusieurs choses, notamment :

  • Créer un simple compte qui aura accès au serveur en SSH.
  • Créer une nouvelle adresse mail en utilisateur@chezmoi.tld.
  • Donner un rôle particulier à un utilisateur afin de séparer les permissions.

Selon les cas, vous ne configurerez pas l'utilisateur de la même façon. En résumé :

  • Laissez les choix par défaut pour un utilisateur classique qui aura un accès SSH, des mails, …
  • Vous pouvez ajouter un utilisateur à un groupe. Ainsi, les permissions données au groupe se répercutent à tous les utilisateurs dans ce dernier.
  • Si l'utilisateur ne doit pas avoir accès à la machine (SSH), alors il faut lui donner un faux "shell" afin qu'il ne puisse pas lancer de commandes. Ce shell est /sbin/nologin .

Pour ajouter un utilisateur, utilisez la commande adduser. Cette dernière est interactive et pose des questions petit à petit pour ne rien oublier au contraire d'useradd (oui, la différence est mince…).

Voici à quoi ressemblera la création d'un utilisateur, qui n'a pas le droit de lancer de commandes :

root@votreserveur[~] # adduser
Use option ``-silent'' if you don't want to see all warnings and questions.

Reading /etc/shells
Check /etc/master.passwd
Check /etc/group

Ok, let's go.
Don't worry about mistakes. There will be a chance later to correct any input.
Enter username []: toto
Enter full name []: Jean-Eudes
Enter shell csh ksh nologin sh [nologin]: nologin
Uid [1005]:
Login group toto [toto]:
Login group is ``toto''. Invite toto into other groups: guest no
[no]:
Login class authpf bgpd daemon default dovecot pbuild staff unbound
[default]:
Enter password []:
Enter password again []:

Name:        toto
Password:    ***************
Fullname:    Jean-Eudes
Uid:         1005
Gid:         1005 (toto)
Groups:      toto
Login Class: default
HOME:        /home/toto
Shell:       /sbin/nologin
OK? (y/n) [y]: y
Added user ``toto''
Add another user? (y/n) [y]: n
Goodbye!

Bien sûr, vous aurez choisi un mot de passe de qualité.

11.1.5.1. Supprimer un utilisateur

Pour supprimer un utilisateur, c'est très rapide :

# userdel toto
# groupdel toto

Et voilà!

11.1.6. Quelles permissions donner aux fichiers d'un site?

Une méthode simple et pourtant redoutable pour sécuriser son site web consiste à modifier les droits et le propriétaire des fichiers dudit site. Voici quelques explications succinctes sur le sujet.

Afin de connaître la situation des fichiers, vous pouvez utiliser la commande ls -l. Dans la suite, on utilisera l'exemple ci-dessous :

$ ls -l
total 120
-rw-r--r--   1 www  daemon  18092 May  5 17:09 COPYING
-rw-r--r--   1 www  daemon    306 May  5 17:09 README
-rw-r--r--   1 www  daemon     23 May  5 17:09 VERSION
drwxr-xr-x   2 www  daemon    512 May  5 17:10 bin
drwxr-xr-x   2 www  daemon   1024 May  5 17:10 conf
drwxr-xr-x  12 www  daemon    512 May  5 17:10 data
-rw-r--r--   1 www  daemon   3674 May  5 17:09 doku.php
-rw-r--r--   1 www  daemon  19372 May  5 17:09 feed.php
drwxr-xr-x   6 www  daemon   1536 May  5 17:10 inc
-rw-r--r--   1 www  daemon    182 May  5 17:09 index.php
drwxr-xr-x   8 www  daemon    512 May  5 17:10 lib
drwxr-xr-x   5 www  daemon    512 May  5 17:10 vendor

On observe une ligne par fichier/dossier. Chaque ligne est découpée de cette façon :

<permissions> <inode> <proprietaire> <groupe> <taille> <date dernier acces> <nom du ficher>

11.1.6.1. Propriétaire et groupe

Chaque fichier appartient à un propriétaire et fait partie d'un groupe. Cela nous permettra de donner certaines permissions aux propriétaires, qui ne seront pas forcément les mêmes que celles données au membre du groupe.

Pour modifier le propriétaire et le groupe, on utilise la commande chown (change owner).

# chown <proprietaire>:<groupe> nom_du_fichier

11.1.6.2. Les permissions

Les lettres en début de ligne décrivent les permissions accordées au fichier. Nous pouvons retenir deux choses :

  1. Si le premier caractère est un d, alors il s'agit d'un répertoire. Sinon, c'est un fichier (sauf exceptions).
  2. Les caractères restants se lisent 3 par 3. Chaque "trio" décrit respectivement les permissions pour le propriétaire, pour le groupe puis pour tous les autres.

    Par exemple, pour cette ligne :

    drwxr-xr-x   2 www  daemon    512 May  5 17:10 bin
    

    On voit qu'il s'agit d'un répertoire. Ensuite, on lit par groupe de 3 par 3 :
  • rwx : Le propriétaire www peut :
    • Le lire : r
    • Écrire à l'intérieur : w
    • L'exécuter (se déplacer dedans pour un répertoire) : x
  • r-x : Ceux appartenant au groupe daemon peuvent
    • Le lire : r
    • L'exécuter (se déplacer dedans) : x
  • r-x : Tous les autres peuvent :
    • Le lire : r
    • L'exécuter (se déplacer dedans) : x

En règle générale, il faut éviter autant que possible de donner les droits d'écriture et d'exécution à d'autres personnes que le serveur web. Parfois, on retire aussi les droits de lecture sur certains fichiers (mots de passe…).

Pour changer les droits, il existe plusieurs méthodes. Certains utilisent une série de chiffres, comme chmod 700. Je trouve cette façon peu explicite lorsqu'on n'a pas encore l'habitude. Quitte à devoir taper quelques commandes en plus, préférez utiliser chmod <personne>±<permission> où :

  • <personne> peut décrire l'utilisateur (u), le groupe (g), les autres (o) ou tous à la fois (a).
  • + ou - pour respectivement ajouter ou retirer les permissions à la personne choisie précédemment
  • <permission> qui peut être x,r ou w.

Vous prendrez bien quelques exemples?

  • chmod g+r fichier : accorde le droit de lecture aux membres du groupe.
  • chmod o-w fichier : retire aux personnes qui ne sont pas membres du groupe ni propriétaires le droit d'écrire dans le fichier.
  • chmod og-rwx fichier : retire aux membres du groupe et aux autres utilisateurs les droits de lecture, d'écriture et d'exécution sur le fichier.

Ces modifications peuvent être appliquées récursivement (à tous les sous-documents d'un dossier) avec l'option -R.

Astuce : pour autoriser à se déplacer dans les dossiers, sans rendre exécutables les fichiers, utilisez X au lieu de x.

11.1.7. Générer des mots de passe aléatoires

Faire des pieds et des mains pour sécuriser son système ne sert à rien si on choisit des mots de passe de 5 lettres. En effet, pour les mots de passe, il n'y a qu'une chose à retenir : "Plus c'est long, plus c'est bon!".

Ce n'est qu'une question de mathématique : un pirate va tenter toutes les combinaisons possibles de mots de passe. Pour l'exemple, imaginons qu'il y ait 26 caractères possibles (on simplifie en oubliant les chiffres, les majuscules et les caractères spéciaux).

  • Pour un mot de passe d'une lettre, ça fait 26 combinaisons à tenter.
  • Pour un mot de passe de deux lettres, ça en fait 26*26 soit 676.
  • Pour un mot de passe de 6 lettres, ça en fait 26*26*26*26*26*26 soit 308915776.

Jusque là, un ordinateur fini par trouver le bon mot de passe par essais successifs en quelques secondes voire quelques minutes. Mais si on allonge encore un peu le mot de passe :

  • 10 lettres : 141167095653376 possibilités
  • 13 lettres : 2481152873203736600 possibilités

Ça commence à faire beaucoup! Ajoutez les majuscules et les chiffres, on passe de 26 à 62 possibilités par caractères. Cela donne un peu plus de 800 000 000 000 000 000 combinaisons possibles pour un mot de passe de 10 caractères! Finalement, il faut tellement de temps pour tenter toutes les possibilités que cela n'arrive jamais. Et qui plus est, vous aurez certainement ajouté des règles anti-bruteforce dans votre parefeu.

Oubliez donc les histoires de symboles spéciaux à inclure absolument, ce n'est pas utile de torturer vos méninges.

Quelques idées :

  • Transformez une phrase en mot de passe. Par exemple, Respirer de la compote fait tousser devient Respirerdelacompotefaittousser.
  • Transformez quelques lettres d'une phrase. Par exemple Ceci est un long mot de passe devient : C3ci_est_un_long_mot_d3_pass3.

Ou alors, si vous aimez avoir mal à la tête, vous pouvez utiliser une des commandes suivantes pour générer des mots de passe aléatoires (Remplacez le "15" par le nombre de caractères souhaités):

$ openssl rand 15 -base64

ou plus classique et plus long :

$ dd if=/dev/urandom count=128 bs=1M 2>&1 | md5 | cut -b-15

Cette petite BD explique très bien cette partie avec humour 😁.

11.1.8. Découper et rassembler des fichiers

Peut-être aurez-vous besoin de découper de gros fichiers pour les transférer sur votre serveur. Voici comment faire :

$ gzip -c gros_fichier | split -b 100m - gros_fichier.gz

Cela vous donne plusieurs fichiers d'une taille maximale de 100m rangés par ordre alphabétique:

$ ls -l
-rw-r--r--  1 xavier  xavier  104857600 Dec 12 16:52 gros_fichier.gzaa
-rw-r--r--  1 xavier  xavier  104857600 Dec 12 16:52 gros_fichier.gzab
-rw-r--r--  1 xavier  xavier   88204071 Dec 12 16:52 gros_fichier.gzac

Afin de les rassembler, utilisez la commande suivante :

cat gros_fichier.gz_* | gunzip -c > gros_fichier

Avouez-le, c'est plutôt cool non? 😁

11.1.9. Vérifier une somme de contrôle

Lorsqu'un fichier est transféré, c'est plus prudent de s'assurer que tous les octets ont bien été copiés. De cette façon, les données sont bien authentiques et ça vous évite des tracas.

Le plus pratique est de vérifier la somme de contrôle du fichier d'origine puis du fichier copié. Pour cela, la commande sha256 est bien pratique. Il suffit de lui donner le fichier à "manger" :

$ sha256 debian-9.6.0-amd64.qcow2.gz
SHA256 (debian-9.6.0-amd64.qcow2.gz) = 91831ba15446f3ab418ae8a5c2a8ac0d852dc5d43bd595a70b88bd6ea4ded397

Reproduisez la même manipulation sur le fichier copié puis comparez cette série de chiffres et lettres : ils doivent être identiques. 😉

Notez que sous GNU/Linux, la commande sha256 n'existe pas. Son équivalent est sha256sum.

Si la somme de contrôle ne vous convainc pas, et si vos données sont particulièrement sensibles, vous pouvez pousser le vice plus loin avec l'outil signify dont le fonctionnement est décrit dans le wiki d'obsd4a

11.1.10. Tâches périodiques

Tout est prévu dans OpenBSD pour vous permettre d'exécuter des commandes régulièrement. Il vous suffit d'éditer un des fichiers suivant :

  • /etc/daily.local : Tâches quotidiennes.
  • /etc/weekly.local : Tâches hebdomadaires.
  • /etc/monthly.local : Tâches mensuelles.

Il faut seulement faire attention à mettre le chemin complet vers les commandes à exécuter à l'intérieur de ces fichiers. Par exemple, pour envoyer un message à l'administrateur, on ne notera pas :

echo "Tu es le plus beau" | mail -s "Coucou" root

mais

echo "Tu es le plus beau" | /usr/bin/mail -s "Coucou" root

Vous trouverez le chemin absolu de vos commandes en utilisant whereis commande.

Pour une configuration plus précise des périodes entre chaque lancement des commandes, il faut utiliser cron. Lancez crontab -e puis ajoutez par exemple pour toutes les heures :

0 * * * * /chemin/vers/la/commande

Pour en apprendre plus, lisez la page de manuel appropriée avec

man 5 crontab

11.1.11. Utiliser les portages de logiciels d'OpenBSD

Vous le savez déjà, OpenBSD dispose de nombreux paquets vérifiés avec soin. Cependant, c'est impossible pour les développeurs d'examiner tous les programmes pouvant être installés. Vous pourrez alors installer un programme ne figurant pas dans les paquets grâce au système de ports.

Il s'agit d'un arbre contenant toutes les instructions pour compiler et installer vous même les paquets. Pas de panique, vous aurez besoin uniquement de la commande make. En effet, le nécessaire pour compiler un paquet, les petites modifications au code source apportées par les développeurs d'OpenBSD et un tas d'autres détails sont précisés dans les ports, si bien que vous n'avez pas à vous en préoccuper.

Nous supposons par la suite que vous utilisez OpenBSD en branche -stable. Vous disposerez ainsi des correctifs de sécurité pour les programmes dans le cas d'une éventuelle faille.

Voici la marche à suivre :

  1. On récupère les ports. Pour cela, on se déplace dans le dossier /usr puis on lance la commande suivante :

    # cd /usr
    # cvs -qd anoncvs@anoncvs.fr.openbsd.org:/cvs get -rOPENBSD_6_5 -P ports
    

    On vous demande de valider ce serveur, acceptez avec yes en toutes lettres :

    The authenticity of host 'anoncvs.fr.openbsd.org (145.238.209.46)' can't be established.
    ECDSA key fingerprint is SHA256:WXN4m8Nxd4vcTqxxxxMMVenxxxgp8060nv39JIiCSss.
    Are you sure you want to continue connecting (yes/no)? yes
    Warning: Permanently added 'anoncvs.fr.openbsd.org,145.238.209.46' (ECDSA) to the list of known hosts.
    

Si vous aviez déjà récupéré les ports, vérifiez qu'il n'y a pas eu de changements avec la commande :

# cd /usr/ports && cvs -q up -rOPENBSD_6_5 -Pd
  1. Cherchez le paquet qui vous intéresse. Par exemple, pour compiler php7.0, je vais chercher où se trouve son port en utilisant la commande make search key=ma_recherche dans le dossier /usr/ports. Puisqu'il risque d'y avoir beaucoup de résultats, on filtre avec la commande grep pour ne voir que ce qui contient 7.0

    # cd /usr/ports
    # pkg_add portslist
    # make search key=php | grep 7.0
    
    On constate alors que le port se trouve dans le dossier (on le repère avec le mot Path) /usr/ports/lang/php/7.0.

  2. Afin de compiler et installer ce port, il ne reste plus qu'à taper make install dans ce dossier :

    # cd /usr/ports/lang/php/7.0
    # make install clean
    
    Toutes les dépendances sont alors récupérées et installées sous forme de paquets que vous pourrez modifier plus tard avec pkg_.

    Afin d'installer tous les "sous-paquets", c'est-à-dire les extensions de PHP (php-curl, php-gd…), on lance :
# make install-all

Pour installer les dépendances à partir des paquets déjà compilés s'ils sont disponibles, ajoutez dans le fichier /etc/mk.conf la ligne suivante :

FETCH_PACKAGES=yes

Ça peut faire gagner un peu de temps.

11.1.12. Équivalences de commandes avec debian

Voici quelques équivalences de commandes avec debian :

Debian OpenBSD
apt-get upgrade pkg_add -u
apt-get autoremove pkg_delete -a
apt-cache search pkg_info -Q
apt-cache show pkg_info

11.1.13. Gestion des services sous OpenBSD

Afin d'activer/désactiver des services (qu'on appelle "démons" car ils tournent en arrière-plan), la commande rcctl est prévue à cet effet. Tous les services disponibles sont dans le dossier /etc/rc.d. Voici quelques rappels :

  • Activer un service au démarrage de la machine : rcctl enable service
  • Démarrer un service : rcctl start service
  • Arrêter un service : rcctl stop service
  • Relancer un service : rcctl restart service
  • Recharger un service : rcctl reload service
  • Modifier les options d'un service : rcctl set service flags "-v -autre_option"

Si vous préférez la méthode manuelle, alors il vous est possible d'éditer directement le fichier /etc/rc.conf.local qui gère les services lancés au démarrage.

11.1.14. Comment changer le mot de passe?

Vous pouvez changer le mot de passe de n'importe quel utilisateur avec la commande passwd. Exemple :

# passwd toto

Pour changer le mot de passe du superutilisateur, c'est un peu plus difficile. On pourrait se contenter d'un passwd root, mais veillez à ce que le message indique bien que le changement est pour l'utilisateur root, ce n'est pas forcément le cas selon la façon dont vous êtes passés superutilisateur.

Sinon, il faut redémarrer la machine, et lorsque vous voyez le terminal de démarrage (prompt boot), démarrez en mode "single user" :

boot> boot -s

Vous verrez un message comme :

Enter pathname of shell or RETURN for sh:

Appuyez sur ENTREE, puis les commandes suivantes afin de monter le système de fichiers

# mount -uw /
# mount /usr

Enfin, changez le mot de passe puis redémarrez normalement :

# passwd
# reboot

11.1.15. Le serveur smtp ne fonctionne pas comme prévu

Si votre serveur mail rencontre des problèmes pour envoyer ou recevoir des messages, vous pouvez utiliser la commande smtpctl pour voir en détail ce qu'il se passe.

  • Par exemple, pour obtenir des informations générales :

    # smtpctl show stats
    control.session=1
    mda.envelope=0
    mda.pending=0
    mda.running=0
    mda.user=0
    mta.connector=1
    mta.domain=1
    mta.envelope=1
    mta.host=2
    mta.relay=1
    mta.route=1
    mta.session=1
    mta.source=1
    mta.task=1
    mta.task.running=0
    queue.evpcache.load.hit=1665
    queue.evpcache.size=2
    queue.evpcache.update.hit=6
    scheduler.delivery.ok=826
    scheduler.delivery.tempfail=6
    scheduler.envelope=2
    scheduler.envelope.incoming=0
    scheduler.envelope.inflight=1
    scheduler.ramqueue.envelope=2
    scheduler.ramqueue.message=2
    scheduler.ramqueue.update=0
    smtp.session=0
    smtp.session.inet4=787
    smtp.session.local=31
    smtp.tls=0
    uptime=777861
    uptime.human=9d4m21s
    

  • Pour voir les messages en attente :

    # smtpctl show queue
    1101f6e60c169eac|inet4|mta||0100015b3a046476-f7d7955a-5842-49af-927c-4fa677f311c6-000000@bounces.duolingo.com|deux@domaine.eu|deux@domaine.eu|1491327053|1491672653|0|5|pending|3154|Network error on destination MXs
    1a2123e1c2b3e462|inet4|mta||gitlab@framasoft.org|deux+framagit@domaine.eu|deux+framagit@domaine.eu|1491333449|1491679049|1491333849|1|inflight|50|Network error
    on destination MXs
    

  • Pour suivre en temps réel ce qu'il se passe :

    # smtpctl monitor
    

Bien sûr, davantage d'explications sont disponibles dans la page man.

11.1.16. Les journaux (Logs)

Votre serveur garde des enregistrements de son activité. Le tout est rassemblé dans des fichiers texte appelés journaux ou plus souvent "logs". On les trouve dans le dossier /var/log pour les journaux système et dans /var/www/logs pour tout ce qui concerne la partie serveur web.

On regardera notamment :

  • /var/log/authlog : Ce fichier contient toutes les tentatives de connexion au serveur, par SSH par exemple.
  • /var/log/daemon : On trouve dans ce journal tous les messages des démons, ces outils lancés en arrière-plan. Il est indispensable pour repérer le dysfonctionnement de l'un deux.
  • /var/log/maillog : C'est le fichier qui enregistre toute l'activité du serveur mail.
  • /var/log/messages : Ici ce sont les messages système, c'est un bon complément à daemon.

Je vous conseille de les consulter de temps en temps afin de vérifier que tout fonctionne comme prévu. Vous pouvez les afficher avec la commande

tail -f /var/journal.log

Vous remarquerez bien vite l'apparition de fichiers se terminant par .0.gz, .1.gz. Ce sont les archives des journaux. Afin d'éviter qu'ils ne prennent trop de place, OpenBSD se charge chaque jour de lancer la commande newsyslog. Cet outil compresse les archives si besoin.

Pour le configurer, jetez un œil au fichier /etc/newsyslog.conf. C'est dans ce dernier que vous devrez ajouter des lignes si une de vos applications crée ses journaux dans un fichier qui n'est pas listé ci-dessus. Il se décompose ainsi :

…
/var/log/messages                       644  5     300  *     Z
/var/log/authlog        root:wheel      640  7     *    168   Z
…

Avec dans l'ordre :

  • Le chemin complet vers le journal.
  • Le propriétaire et le groupe de l'archive qui sera créée (facultatif).
  • Le mode de l'archive.
  • Le nombre d'archive que l'on conserve.
  • La taille maximale du journal avant qu'il soit compressé et renouvelé.
  • Le moment où sera archivé le journal. Un "*" indique que ça peut être n'importe quand, "$D0" indique chaque jour à minuit…
  • Un drapeau pour configurer la façon dont le journal est compressé. Z indique qu'on la souhaite au format .gz, cela conviendra dans la plupart des cas.

On peut préciser ensuite si besoin :

  • Le fichier contenant le numéro du processus (pid).
  • Le signal à envoyer au processus, ex : SIGUSR1.
  • La commande à lancer pour faire tourner les journaux.

Pour d'autres informations, regardez la page man de newsyslog et newsyslog.conf.

$ man newsyslog.conf

11.2. Les certificats SSL

Vous avez peut-être déjà lu la solution utilisant letsencrypt avec acme-client. Ce paragraphe propose quelques autres informations sur les certificats SSL.

11.2.1. Générer un certificat SSL auto-signé

Nous allons ici auto-signer le certificat. Les visiteurs de votre site risquent juste d'avoir un avertissement de ce type :

Sachez qu'il est possible d'acheter une autorité de certification. Mais dépenser votre argent n'est pas nécessaire n'est-ce pas? De plus un certificat auto-signé ne retire en rien la protection du chiffrement SSL.

Pour créer un certificat et le signer, il faut lancer la commande suivante. Bien sûr, remplacez le nom du fichier certificat à votre convenance :

# openssl req -x509 -sha512 -nodes -days 365 -newkey rsa:4096 \
	-keyout /etc/ssl/certificat.key \
	-out /etc/ssl/private/certificat.pem

Quelques questions vous seront posées. Vous n'êtes pas obligé de remplir tous les champs.

Finalement, il faut protéger ce certificat. Lancez ces deux dernières commandes afin d'en restreindre les permissions :

# chown root:wheel /etc/ssl/private/certificat.key
# chmod 600 /etc/ssl/private/certificat.pem

Retenez bien le chemin vers ce certificat. Il faudra le préciser dans la configuration de votre serveur web (http).

11.2.2. Tester la sécurité SSL

Les plus intéressés pourront tester la sécurité de leur serveur sur le site sslabs, qui fourni d'excellents conseils pour l'améliorer.

11.3. Installation chiffrée

Si un jour votre serveur est volé par un méchant cambrioleur, vos données peuvent rester tranquilles si vous chiffrez l'ensemble de votre système. Tout est bien pensé par OpenBSD qui a décrit la procédure dans sa FAQ. Notez que vous devrez être en mesure d'entrer la phrase de déchiffrement du disque à chaque démarrage et redémarrage du serveur, ce qui peut être une contrainte pour certains.

En résumé, juste avant l'installation, vous verrez le message suivant :

Welcome to the OpenBSD/amd64 X.X installation program.
(I)nstall, (U)pgrade, (A)utoinstall or (S)hell? s

Choisissez l'invite de commandes avec "S".

À partir de ce moment-là, on remplit le disque de zeros pour écraser toutes les données pré-existantes (sd0 correspond à votre disque dur ici):

dd if=/dev/urandom of=/dev/rsd0c bs=1m

Ça peut être long selon le matériel (taille et vitesse d'écriture).

Ensuite, on crée une partition softraid qui sera chiffrée :

  • Si vous démarrez via MBR (défaut) : # fdisk -iy sd0
  • Si vous démarrer avec GPT ou UEFI : # fdisk -iy -g -b 960 sd0

    Créez la table de partition sur sd0 avec un type RAID:

    disklabel -E sd0
    Label editor (enter '?' for help at any prompt)
    > a a			
    offset: [64]
    size: [39825135] *
    FS type: [4.2BSD] RAID
    > w
    > q
    No label changes.
    

Ensuite, on peut créer le périphérique chiffré avec une bonne phrase de passe :

# bioctl -c C -l sd0a softraid0
New passphrase:
Re-type passphrase:
sd1 at scsibus2 targ 1 lun 0: <OPENBSD, SR CRYPTO, 005> SCSI2 0/direct fixed
sd1: 19445MB, 512 bytes/sector, 39824607 sectors
softraid0: CRYPTO volume attached as sd1

Cela crée un pseudo-périphérique sd1. Pour être sûr que l'installateur le prenne en compte, lancez :

# cd /dev && sh MAKEDEV sd1

On écrase les premières données du pseudo-périphérique :

# dd if=/dev/zero of=/dev/rsd1c bs=1m count=1

Enfin, entrez exit pour retrouver l'installateur, et procédez à l'installation sur ce pseudo-périphérique sd1 tout naturellement.

11.4. Suggestions d'améliorations avec lynis

Lynis est un outil qui va analyser votre système pour y détecter d'éventuelles erreurs de configuration pouvant entacher la sécurité de votre serveur. De plus, il peut vous proposer des idées d'amélioration.

Afin de l'utiliser, installez-le puis lancez le premier scan :

# pkg_add lynis
# lynis --checkall

Vous pourrez voir de nombreux messages apparaître. Consultez le fichier /var/log/lynis-report.dat afin de lire le rapport calmement :

# less /var/log/lynis-report.dat

On pourra lire par exemple comme suggestions :

suggestion[]=SSH-7408|Consider hardening SSH configuration|AllowTcpForwarding (YES --> NO)|-|
suggestion[]=SSH-7408|Consider hardening SSH configuration|ClientAliveCountMax (3 --> 2)|-|
suggestion[]=SSH-7408|Consider hardening SSH configuration|Compression (YES --> NO)|-|

Pour voir uniquement les suggestions, utilisez :

# grep suggestion /var/log/lynis-report.dat

12. Annexes

12.1. FAQ : Foire aux questions

12.1.1. Comment lire et chercher dans du texte ?

Pour seulement consulter un fichier, utilisez la commande less.

Ensuite, vous pouvez chercher n'importe quelle chaîne de caractères en appuyant sur / puis en écrivant votre recherche. Appuyez sur n pour aller à l'occurrence suivante, ou bien N pour revenir en arrière.

Pour quitter less, appuyez sur q.

Si vous voulez chercher dans le contenu des logs, ça peut être pratique 😉.

12.1.2. Comment modifier un fichier?

Il existe une ribambelle d’éditeurs de texte (vim, nano…). L'éditeur par défaut sur OpenBSD est vi. Il est peut être étonnant à utiliser au premier abord, si bien que certains voudront peut-être installer un autre éditeur à la place. Cependant, vi est très pratique une fois qu'on l'a pris un peu en main. Si au contraire vous êtes déjà habitué à l'éditeur emacs, vous trouverez votre bonheur avec l'éditeur mg présent lui aussi par défaut (voir le manuel pour plus de détails).

Voici quelques conseils pour utiliser vi au travers d'un exemple. Pour éditer le fichier /etc/iloverocknroll, vous saisirez ceci :

$ vi /etc/iloverocknroll

Apparaîtra alors le contenu de ce fichier dans le terminal :

En général, vous procéderez seulement ainsi :

  1. Appui sur la touche "i" pour pouvoir écrire.
  2. Appui sur "echap" pour quitter le mode insertion.
  3. Enregistrement et fermeture de vi en saisissant :wq.

Vous êtes toujours là ? 😁

Allons donc un peu plus loin (mais pas trop, promis 😁). Comprenez tout de suite qu'il existe trois modes :

  • Le mode "visualisation" : vous pouvez vous déplacer dans le fichier avec les touches "h","j","k","l".
  • Le mode "insertion" : vous pouvez écrire du texte. On entre dans ce mode avec la touche "i". Pour en sortir, on appuie sur "echap".
  • Le mode "édition" : ce dernier est moins utile lorsqu'on débute. On peut faire des modifications rapides, par exemple remplacer du texte ou supprimer plusieurs lignes d'un coup.

Pour enregistrer les modifications, appuyez sur : puis sur w. Validez avec entrée. On peut maintenant quitter en écrivant :q. Notez que vous pouvez aller plus vite en saisissant directement :wq.

Afin de chercher un texte, ce qui est bien utile dans les gros fichiers, appuyez sur la touche / puis écrivez votre recherche.

Si vous souhaitez quitter sans enregistrer vos modifications, saisissez alors :q!.

Deux autres astuces bien pratiques :

  • cw : permet de changer un mot (change word)
  • c$ : permet de changer du curseur jusqu'à la fin de la ligne
  • 3G : permet d'aller à la ligne numéro 3
  • ma : place une marque 'a' à l'emplacement du curseur. Pour y revenir rapidement ensuite, vous entrerez 'a.
  • dd : supprime la ligne.
  • yy : copie la ligne.
  • p : colle ce qui a été copié ou supprimé avant.
  • x : supprime un caractère sous le curseur
  • u : (undo) annule l'action précédente.
  • . : répète l'action précédente. Pour annuler plusieurs fois, vous ferez donc u…. (ici, 5 fois en tout).

Dernière astuce pour coller du texte. Entrez en mode "édition" en appuyant sur i. Sélectionner avec la souris le texte à coller. Dans vi, appuyez sur Shift-Insert : le texte est collé.

Inutile de tout retenir, ça rentrera petit à petit.

Cela devrait être amplement suffisant dans un premier temps. Si le fonctionnement de vi vous intéresse, vous pouvez consulter cette documentation.

12.1.3. Le modem de mon fournisseur suffit ?

Est-ce qu’une « bête » *Box (Freebox) suffit pour assurer convenablement un tel service sur la durée ?

Oui ! Si vous préférez, vous pouvez bien entendu utiliser votre propre routeur.

12.1.4. C'est quoi un sous-domaine?

Réponse rapide : un domaine c'est chezmoi.tld. Un sous-domaine c'est sousdomaine.chezmoi.tld.

Réponse longue : Le domaine principal est enregistré chez votre registre par un champ A pointant vers l'adresse IP de votre serveur. Ensuite, vous pouvez ajouter autant de sous-domaines que vous voulez en créant dans la zone des champs de type CNAME, qui renvoient vers le champ A précédent. En gros, les visiteurs sont toujours dirigés vers votre serveur, mais selon le domaine/sous-domaine entré dans la barre d'adresse, votre serveur leur fourni un contenu différent.

Un champ CNAME se présente donc sous cette forme :

sousdomaine    IN CNAME  domaine.net.

Le point final est important !

Tout est bien expliqué dans cette partie.

12.1.5. Quelle taille pour le disque dur?

Il paraît que pour un serveur, on peut utiliser un vieux PC. Mais quelle taille de disque dur est nécessaire au minimum?

Ça dépend. La réponse ne sera pas la même selon ce que vous voulez faire du serveur. Pour un petit site web, quelques Go suffiront amplement.

Si c'est un site contenant images et vidéos à gogo, alors il faudra un espace plus conséquent.

Si votre serveur fait office de seedbox ou de mediacenter, alors il faut compter encore plus.

Dans la majorité des cas, 10G à 20G seront suffisants.

12.1.6. Quelle puissance pour le processeur?

Là aussi, ça dépend. Pour un simple site avec quelques visites par jour, peu de puissance est nécessaire.

S'il y a du PHP, il faut alors une puissance un peu plus élevée.

Enfin, si le serveur propose de la messagerie instantanée, un site avec PHP, des mails… Vous l'aurez compris, il faudra encore une puissance plus grande.

Il en va de même pour la mémoire vive d'ailleurs.

Dans la majeure partie des cas, un vieux pc récupéré à la configuration modeste sera suffisant, vous investirez si des ralentissements apparaissent.

12.1.7. Je n'ai pas d'IP fixe

Mon fournisseur d'accès ne me donne pas une adresse IP fixe.

C'est effectivement embêtant. Car dans ce cas, l'adresse IP associée à votre domaine "chezmoi.tld" doit régulièrement être mise à jour.

Sachez qu'il existe pour ça DynDNS. C'est un service qui permet de réaliser cette opération, et la plupart des *box ont une option pour le configurer.

Cela peut toutefois être fastidieux, et vous préférerez peut-être changer de fournisseur d'accès. FDN par exemple?

12.1.8. Où trouver des applications pour mon serveur?

Le site WAAH, Wiki des Applications Auto-Hébergées recense de nombreuses applications que l'on peut héberger sur son serveur. Il en existe sûrement d'autres, mais celui-ci est particulièrement complet.

Il existe aussi alternative.to qui recense quelques projets.

En anglais, on peut évoquer ce dépôt github qui recense de nombreuses applications à auto-héberger.

12.1.9. Où vont mes mails si mon serveur est éteint ?

Quand on héberge ses mails, que se passe-t-il quand le serveur de mail est, pour une raison quelconque, inaccessible ?

Voilà une question qu'on se pose forcément à un moment donné. Lorsque le serveur est inaccessible, il se passe à peu près la même chose que lorsque le facteur doit délivrer un recommandé : le serveur expéditeur essaie une première fois et échoue. Il va repasser une fois suivante un peu plus tard. En cas de second échec, il réessaie à nouveau plus tard.

Bien évidemment, après plusieurs échecs, il abandonne.

Vous devez vous demander combien d'essais et quels intervalles entre chaque essai? À cela je n'ai pas de réponse précise, car ça dépend de la configuration du serveur expéditeur. On peut toutefois raisonnablement considérer que les essais peuvent se poursuivre pendant une dizaine de jours.

12.1.10. Que faire contre les coupures de courant ?

Plusieurs astuces sont possibles :

  • Solution facile : utiliser un onduleur. C'est une sorte de batterie de secours en cas de coupure de courant. On y branche dessus le routeur qui donne accès à Internet et le serveur. Mais bon, puisque les mails sont ré-envoyés en cas de pépin, ce n'est peut-être pas utile.
  • Avoir un copain qui héberge un enregistrement MX de secours correspondant à celui de son serveur. Il "stockera" les mails en attendant que votre serveur soit accessible. À nouveau, ça reste inutile pour des courtes coupures de courant.

Dans le cas où l'interruption du serveur est due à un bug quelconque, sachez que tous les jours, OpenBSD génère un rapport de sécurité qui peut dire : "ce service devrait être en route mais ne l'est pas". Ainsi, vous pouvez aller vérifier assez rapidement quel est le problème.

En somme, pas de quoi s'alarmer outre mesure.

12.1.11. Comment connaître l'utilisation et les vitesses réseau ?

Vous pouvez installer les ports iftop ou bwm-ng.

Sinon, présent de base sur OpenBSD, il y a la commande systat :

# systat states

12.2. Merci!

Merci particuler à PengouinBSD qui gère comme un chef notre plateforme francophone autour d'OpenBSD, qui a relu et vérifié mes moindres écarts quand je voulais faire trop simple ou me trompais dans ce document. Il est, entre autre choses, à l'origine des astuces pour découper des fichiers et vérifier leur somme de contrôle.

Je tiens aussi à remercier Stéphane qui m'a beaucoup aidé dans ma découverte d'OpenBSD et a partagé sans retenue ses talents de pédagogue. Sa contribution sur la partie DNS est épatante.

Merci Péhä pour tes encouragements, tes conseils et tes magnifiques illustrations (sous licence CC-BY-SA).

Coucou à Fred Galusik et kuniyoshi qui m'ont accompagné et m'accompagnent encore dans l'aventure d' obsd4*.

Merci à Bastien Traverse, PengouinBSD et kuniyoshi pour la relecture.

Un coucou tout spécial à mon ami JB que j'aime malgré son OS.

Et puisque j'aime garder le meilleur pour la fin, un merci rien que pour ma super geekette qui reboote le serveur quand il est down en mon absence et fait semblant de s'intéresser à ce que raconte ce manuel.

12.3. Exemples et fichiers

Voici quelques exemples de fichiers de configuration. Ces derniers sont, autant que possible, commentés pour faciliter leur compréhension.

12.3.1. /etc/pf.conf

# See pf.conf(5) and /etc/examples/pf.conf
## Configuration générale ##
http_ports = "{ www https }            # ports http(s)
mail_ports = "{ submission imaps }"    # ports mails 
tcp_pass = "{ domain }"                # ports tcp ouverts
udp_pass = "{ domain }"                # ports udp ouverts
set block-policy drop                  # bloque silencieusement
set skip on lo                         # Pas de filtre en local
set limit table-entries 400000   
set limit states 100000

## tables pour les vilains bruteforceurs
table <bruteforce> persist
table <vilain_bruteforce> persist

# antispam avec greylisting
table <nospamd> persist file "/etc/mail/nospamd"
table <spamd-white> persist
table <bgp-spamd-bypass> persist

# table blockzone
table <t_badips> persist file "/var/blockzones/badips_ipv4"
table <t_badips6> persist file "/var/blockzones/badips_ipv6"
table <t_bogons> persist file "/var/blockzones/bogons_ipv4"
table <t_bogons6> persist file "/var/blockzones/bogons_ipv6"

## Traitement des paquets ##
# Paquets partiels
match all scrub (max-mss 1440 no-df random-id reassemble tcp)
antispoof quick for egress         # Protection vol d'ip
antispoof quick for lo0            # Protection vol d'ip


# Pour relayd
anchor "relayd/*"

## Les règles pour pf ##
# on bloque tout par défaut 
# puis on continue de lire la suite
block 

# on bloque les ip blacklistées	pour de bon (quick)
# on ajoute un label pour se repérer dans les [logs #logs]
block log quick from <bruteforce> label "brutes"
block log quick from <vilain_bruteforce>  label "vilain"

# blocage des blockzones
block log quick from { <t_bogons>, <t_bogons6> } label "bogons" 
block log quick from { <t_badips>, <t_badips6>} label "badips"

# NFS local
pass in quick on egress from 192.168.1.0/24

## Anti bruteforce
### SSH
#### Limit 15 connexions par IP source
#### Limit 15 tentatives de connexion toutes les 5 minutes
pass in on egress proto tcp to port ssh modulate state \
	(max-src-conn 15, max-src-conn-rate 15/5, overload <bruteforce> flush global)

# web, avec redirection vers relayd
pass in on egress proto tcp to port www modulate state \
    (max-src-conn 100, max-src-conn-rate 25/5, overload <bruteforce> flush global) \
    divert-to 127.0.0.1 port 8080
pass in on egress proto tcp to port https modulate state \
    (max-src-conn 100, max-src-conn-rate 25/5, overload <bruteforce> flush global) \
    divert-to 127.0.0.1 port 8443

# mails
## antispam
pass in on egress proto tcp to port $mail_ports modulate state \
	(max-src-conn-rate 10/5, overload <bruteforce> flush global) \
	divert-to 127.0.0.1 port spamd
pass in on egress proto tcp from <nospamd> to any port smtp
pass in log on egress proto tcp from <spamd-white> to any port smtp
pass in quick on egress proto tcp from <bgp-spamd-bypass> to port smtp
pass out log on egress proto tcp to any port smtp

# on autorise le ping
pass quick inet6 proto ipv6-icmp all 
pass quick inet proto icmp all 

# on ouvre les autres ports
pass in quick on egress proto tcp to port $tcp_pass modulate state
pass in quick on egress proto udp to port $udp_pass 

# tout ouvert en sortie
pass out on egress proto { tcp udp icmp icmp6 } all modulate state 

12.3.2. /etc/httpd.conf

types { include "/usr/share/misc/mime.types" }
default type text/plain

server "default" {
    listen on * port 80 
    root "/htdocs/chezmoi.tld" 
} 


server "chezmoi.tld" {
    listen on * port 80
    block return 301 "https://$SERVER_NAME$REQUEST_URI"
}

server "chezmoi.tld" { 
    alias "www.chezmoi.tld"
    listen on * tls port 443 
    root "/htdocs/chezmoi.tld" 
    directory index index.html
    log style combined

    hsts preload
    tls {
        certificate "/etc/ssl/chezmoi.tld-fullchain.pem"
        key "/etc/ssl/private/chezmoi.tld.key"
    }

    location "/.well-known/acme-challenge/*" {
        root "/acme"
        request strip 2
    }

    location "/Blog/" {
        directory index index.php
    }

    location "*.php*" {
        fastcgi socket "/run/php-fpm.sock"
    }

    location "/DL/PDF/" {
        directory auto index
    }

    location "/private/" {
        authenticate "education" with "/htdocs/private.htpw"
        directory auto index
    }
}

server "site2.chezmoi.tld" { 
    alias "www.site2.chezmoi.tld"
    listen on * port 80 
    listen on * tls port 443 
    root "/htdocs/site2" 
    directory index index.html
    log access "site2.log"

    hsts 
    tls {
        certificate "/etc/ssl/chezmoi.tld-fullchain.pem"
        key "/etc/ssl/private/chezmoi.tld.key"
    }

    location "/.well-known/acme-challenge/*" {
        root "/acme"
        request strip 2
    }

    location "*.php*" {
        fastcgi socket "/run/php-fpm.sock"
    }
    location "/downloads/" {
        directory index index.php
    }
} 

12.3.3. /etc/mail/smtpd.conf

12.3.3.1. /etc/mail/smtpd.conf

# Configuration generale
## Tables 
table aliases file:/etc/mail/aliases
table passwd passwd:/etc/mail/passwd
table virtuals file:/etc/mail/virtuals
table domains file:/etc/mail/domains

## Certificats
pki chezmoi.tld key "/etc/ssl/private/chezmoi.tld.key"
pki chezmoi.tld cert "/etc/ssl/chezmoi.tld-fullchain.pem"

## options sur la file d'attente
queue compression
queue encryption 7dbecabecabeca45bce4aebc

### Ecoute pour messages signes avec dkimproxy
listen on lo0 port 10028 tag DKIM   
### Messages verifies par spamassassin
listen on lo0 port 10026 tag SPAMASSASSIN
### Messages locaux
listen on lo0 

### Reception
listen on egress tls pki chezmoi.tld 
### Envoi avec client de messagerie
### "all" pour utiliser un webmail heberge sur ce serveur
listen on all port submission tls-require pki chezmoi.tld auth <passwd> 


# ACTIONS
action "envoi" relay 
action dkimproxy relay host smtp://127.0.0.1:10027 
action spamassassin relay host smtp://127.0.0.1:10025 

action local_mbox mbox alias <aliases>

action relaybackup relay backup helo "chezmoi.tld"

action virtual_maildir maildir "/var/vmail/%{dest.domain}/%{dest.user}/Maildir" junk virtual <virtuals>

# Correspondances
## Reception
### Message pour les utilisateurs locaux
match for local action local_mbox
### Message pour les utilisateurs virtuels
match tag SPAMASSASSIN from any for domain <domains> action virtual_maildir
### Messages a faire verifier par spamassassin
match from any for domain <domains> action spamassassin

## Envoi
### Mail sortant portant une signature DKIM
match tag DKIM for any action "envoi"
match auth tag DKIM from any for any action "envoi"

### backup pour les copains
match from any for domain copain.eu action relaybackup
match from any for domain copain.dk action relaybackup

### Mail en envoi pas encore signe avec DKIM
match auth from any for any action dkimproxy
match for any action dkimproxy

12.3.3.2. /etc/mail/domains

Indiquez ici tous vos champs MX.

chezmoi.tld 
domaine2.net 
autredomaine.xyz 

12.3.4. /etc/relayd.conf

Fichier /etc/relayd.conf

http protocol "http" {
    tcp { nodelay, sack, socket buffer 65536, backlog 100 }
    include "/etc/relayd.proxy.conf"
    pass
}

http protocol "https" {
    tcp { nodelay, sack, socket buffer 65536, backlog 100 }
    tls { \
        no tlsv1.0\
        ciphers "HIGH"\
    }
    include "/etc/relayd.proxy.conf"
    pass

}
relay "www" {
    listen on 127.0.0.1 port 8080
    protocol "http"
    forward to destination
}

relay "wwwtls" {
    listen on 127.0.0.1 port 8443 tls
    protocol "https"
    forward with tls to destination
}

##
# put certificate in /etc/ssl/private/127.0.0.1.key
# put certificate in /etc/ssl/127.0.0.1.crt
# ln -s /etc/ssl/private/chezmoi.tld.key /etc/ssl/private/127.0.0.1.key
# ln -s /etc/ssl/chezmoi.tld-fullchain.pem /etc/ssl/127.0.0.1.crt
# required in pf.conf : 
#pass in quick on egress proto tcp to port www divert-to 127.0.0.1 port 8080 flags S/SA modulate state
#pass in quick on egress proto tcp to port https divert-to 127.0.0.1 port 8443 flags S/SA modulate state

Fichier /etc/relayd.proxy.conf inclus dans le fichier précédent.

return error
# Pour garder l'IP source
match header set "X-Forwarded-For" value "$REMOTE_ADDR"
match header set "X-Forwarded-By" value "$SERVER_ADDR:$SERVER_PORT"
# Pour https
match header set "Keep-Alive" value "$TIMEOUT"
match query hash "sessid"

# Securite
match request header remove "Proxy"
match response header set "X-Xss-Protection" value "1; mode=block"
match response header set "Frame-Options" value "SAMEORIGIN"
match response header set "X-Frame-Options" value "SAMEORIGIN"
match response header set "X-Robots-Tag" value "index,nofollow"
match response header set "X-Permitted-Cross-Domain-Policies" value "none"
match response header set "X-Download-Options" value "noopen"
match response header set "X-Content-Type-Options" value "nosniff"

# fun
match response header set "X-Powered-By" value "Powered with electricity on OpenBSD"

# etiquette pour utf-8 et gain de temps
match request path "/*.html" tag "HTML"

# etiquettes pour gestion du cache
match request path "/*.css" tag "CACHE"
match request path "/*.js" tag "CACHE"
match request path "/*.atom" tag "CACHE"
match request path "/*.rss" tag "CACHE"
match request path "/*.xml" tag "CACHE"
match request path "/*.jpg" tag "CACHE"
match request path "/*.png" tag "CACHE"
match request path "/*.svg" tag "CACHE"
match request path "/*.gif" tag "CACHE"
match request path "/*.ico" tag "CACHE"

match response tagged "CACHE" header set "Cache-Control" value "max-age=1814400"
match response tagged "HTML" header set "Content-Type" value "text/html; charset=UTF-8"

# anti robots sur wordpress que je n'ai pas
block quick path "/wp-*" label '<em>Stop scanning for wordpress</em>.'

# exemple de redirection
block quick path "/Blog*" label '<p>Le blog est maintenant par ici : <em><a href="/Journal">/Journal</a></em>.</p><p>Abonnez-vous au <a href="/feed.atom">flux atom</a></p>'

# apparence de l'erreur
return error style "body { background: silver; color: black; text-align:center } hr {border:0;
background-color:silver; color:silver; height:1px; width:30%; margin-top:50px;}"


12.3.5. /etc/monitrc

# Vérifie qu'un site est accessible
check host chezmoi.tld with address chezmoi.tld
      if failed port 80 protocol http for 2 cycles then alert
      if failed port 443 protocol https for 2 cycles then alert
	  # alerte si le certificat SSL arrive à expiration
      if failed
         port 443
         with protocol https
         and certificate valid > 30 days
         use ssl options {verify: enable}
      then alert


# Disponibilité du serveur mail
check host chezmoi.tld with address chezmoi.tld
      if failed port 25 with protocol smtp for 2 cycles then alert


# ressources utilisées
check system localhost
	if cpu > 75% for 2 cycles then alert
	if memory usage > 75% then alert
	if swap usage > 30% then alert
	if disk read > 10 MB/s for 2 cycles then alert

check filesystem rootfs with path /
              if space usage > 90% then alert
check filesystem var with path /var
              if space usage > 90% then alert


12.3.6. /var/nsd/etc/nsd.conf


server:
        hide-version: yes
        verbosity: 2
        database: "" # disable database
        zonesdir: "/var/nsd/zones/"
        ip-address: 46.23.92.148
        ip-address: 2a03:6000:9137::148 


remote-control:
        control-enable: yes

key:
        name: "secretkey"
        algorithm: hmac-sha256
        secret: "i8f4FgDsldD11pHAqo9Ko="

zone:
        name: "reiva.xyz"
        zonefile: "signed/reiva.xyz"
        provide-xfr: 109.190.128.23 secretkey
        notify: 109.190.128.23 secretkey

		# GANDI
        provide-xfr: 217.70.177.40 NOKEY
        notify: 217.70.177.40 NOKEY


# slaves
zone:
        name: "ybad.name"
        zonefile: "slave/ybad.name"
        allow-notify: 109.190.128.23 secretkey
        request-xfr:  109.190.128.23 secretkey

zone:
        name: "ouaf.xyz"
        zonefile: "slave/ouaf.xyz"
        allow-notify: 109.190.128.23 secretkey
        request-xfr:  109.190.128.23 secretkey

zone:
        name: "3hg.fr"
        zonefile: "slave/3hg.fr"
        allow-notify: 109.190.128.23 secretkey
        request-xfr:  109.190.128.23 secretkey

12.3.7. /etc/mail/spamd.conf

all:\
        :nixspam:bgp-spamd:bsdlyblack:whitelist:

# Nixspam recent sources list.
# Mirrored from http://www.heise.de/ix/nixspam
nixspam:\
        :black:\
        :msg="Your address %A is in the nixspam list\n\
        See http://www.heise.de/ix/nixspam/dnsbl_en/ for details":\
        :method=http:\
        :file=www.openbsd.org/spamd/nixspam.gz

bsdlyblack:\
        :black:\
        :msg="Your address %A is in the bsdly.net list":\
        :method=http:\
        :file=www.bsdly.net/~peter/bsdly.net.traplist

bgp-spamd:\
         :black:\
         :msg="Your address %A has sent mail to a spamtrap\n\
          within the last 24 hours":\
         :method=file:\
         :file=/var/spamd.black

whitelist:\
        :white:\
        :method=file:\
        :file=/etc/mail/whitelist.txt

12.3.8. /etc/dovecot/local.conf

# listen both ipv4 and ipv6
listen = *, [::]

# imap c'est mieux que pop
protocols = imap 

# securisation via ssl
ssl = yes
ssl_cert = </etc/ssl/chezmoi.tld-fullchain.pem
ssl_key = </etc/ssl/private/chezmoi.tld.key
# pas de plaintext
disable_plaintext_auth = yes

# Modification des permissions pour limiter la lecture du fichier des mots de passe
# au groupe _maildaemons
service auth {
  user = $default_internal_user
  group = _maildaemons
}

# Identification par fichier
passdb {
    args = scheme=blf-crypt /etc/mail/passwd
    driver = passwd-file
}

userdb {
    driver = static
    args = uid=_vmail gid=_vmail home=/mnt/bigstorage/_vmail/%d/%n/ 
}

# Plugins
mail_plugins = $mail_plugins quota zlib
# Activation des plugins : 
# - Support des quotas
# - zlib limite la bande passante par compression
# - sieve pour filtres personalises. **Il faut le paquet dovecot-pigeonhole**
protocol imap {
    mail_plugins = $mail_plugins imap_quota imap_zlib imap_sieve
}


# Configuration des plugins
plugin {
        #plugin quota
	quota = maildir:User quota
	quota_rule = *:storage=1G
	quota_rule2 = Trash:storage=+100M
	quota_grace = 50%%
	quota_status_success = DUNNO
	quota_status_nouser = DUNNO
	quota_status_overquota = "552 5.2.2 Mailbox is full"

	# Compression maxi
	zlib_save_level = 9 # 1..9; default is 6
	zlib_save = gz # or bz2, xz or lz4

        # Sieve
        # -----
	sieve_plugins = sieve_imapsieve sieve_extprograms
        
        # Script sieve execute par defaut (antispam)
        sieve_default = /usr/local/lib/dovecot/sieve/default.sieve

	# Scripte pour enregistrer comme spam quand mails deplace dans dossier Junk
	imapsieve_mailbox1_name = Junk
	imapsieve_mailbox1_causes = COPY
	imapsieve_mailbox1_before = file:/usr/local/lib/dovecot/sieve/report-spam.sieve

	# Enregistrer mail comme pas-spam si retire du dossier Junk
	imapsieve_mailbox2_name = *
	imapsieve_mailbox2_from = Junk
	imapsieve_mailbox2_causes = COPY
	imapsieve_mailbox2_before = file:/usr/local/lib/dovecot/sieve/report-ham.sieve

	sieve_pipe_bin_dir = /usr/local/lib/dovecot/sieve

	sieve_global_extensions = +vnd.dovecot.pipe +vnd.dovecot.environment
}

12.3.9. /etc/webalizer.conf

LogFile        /var/www/logs/access.log
OutputDir      /var/www/htdocs/chezmoi.tld/stats
ReportTitle    Statistiques pour 
HostName	chezmoi.tld
GeoDB no
GeoIP		yes
GeoIPDatabase	/var/db/GeoIP/GeoIP.dat
HTMLPre <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
HTMLHead <style type="text/css"> body { background: 
HTMLHead }
HTMLHead tr:nth-child(even) {background: #333}
HTMLHEAD tr:nth-child(odd) {background: #222}
HTMLHead </style>
LinkReferrer	yes
TopSites        75
TopURLs         50
TopReferrers    100
AllSites	yes
AllURLs	yes
AllReferrers	yes
AllSearchStr	yes
AllErrors      yes
HideSite	*chezmoi.tld
HideReferrer	chezmoi.tld
HideURL		*.gif
HideURL		*.GIF
HideURL		*.jpg
HideURL		*.JPG
HideURL		*.png
HideURL		*.PNG
HideURL		*.ra
HideURL		*.css
HideURL		*.woff
GroupReferrer google. Google Intl
HideReferrer google.
IgnoreURL	/favicon.ico
IgnoreURL	/robots.txt
ColorBackground        	ECEDEE
ColorText              eeeeee
ColorLink              28952D
ColorVLink             336699
ColorALink             28952D
ColorHeadline          444444
ColorCounter           555555
ColorHit	        172C39
ColorFile	        072F63
ColorSite	        50504A
ColorKbyte	        BCB2A0
ColorPage	        7B717D
ColorVisit	        DCB647
ColorMisc              95B8D4
ChartBackgroundColor   333333
ChartLegendColor       eeeeee
ChartShadowColor1      333333
ChartShadowColor2      333333
TableBorder     0
ChartBorder    0