Ce document est écrit pour vous aider à héberger chez vous certains services malheureusement trop souvent confiés à des tiers.

À la fin de la lecture, vous saurez :

Notez que les procédures détaillées ici peuvent aussi être déployées sur des serveurs dédiés.

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

Pour obtenir une version papier de cet ouvrage, vous pouvez l'acheter ici :

Acheter

Vous pouvez aussi demander à un professionnel de vous imprimer le fichier PDF disponible sur demande.

Notez que le code CSS de cette page a été optimisé pour l'impression. Utilisez un navigateur récent comme Firefox pour en profiter.

Un ouvrage complémentaire vous propose au format numérique (EPUB, PDF, MOBI) des fiches résumées sur chaque chapitre.

Acheter

Acheter Acheter le livre


Ou faire un don ♥

Cet ouvrage est publié sous licence CC-BY-SA à l'aide de txt2tags.

Sommaire >
  1. Introduction
  2. Gérer son serveur
  3. Héberger un site web
  4. Héberger son courrier électronique
  5. Serveur de noms
  6. Services divers
  7. Aller plus loin
  8. Remarques complémentaires sur le système
  9. Annexes

1. Introduction

1.1. Avant-propos

Vous êtes sur le point de plonger dans l'univers de l'auto-hébergement. Cet ouvrage a pour objectif de vous guider pour découvrir ces notions de façon cohérente. 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.

La méthode d'installation d'un serveur proposée dans ce document devrait convenir à la plupart des lecteurs. L'objectif principal est de vulgariser l'auto-hébergement, ce qui entraîne des compromis. Les plus pointilleux chercheront certainement à approfondir les notions évoquées ici. C'est pourquoi le document est conçu pour être lu dans l'ordre que vous souhaitez, selon vos besoins, quitte à faire quelques rappels parfois. Le sommaire est là pour vous repérer.

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 l'Internet 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…

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 :

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

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

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 :

Certains points sont abordés par la suite, n'hésitez donc pas à feuilleter plus loin pour en apprendre plus.

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 pour parler 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 lourd 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 :

Cliquez pour afficher l'image.

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

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

Pour connaître votre IP publique, il existe de nombreux services en ligne, par exemple sur mon-ip.com, lehollandaivolant.net, who.is , ipecho 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.

Si quelqu'un veut visiter votre site web, il ne connaît que votre IP publique. Or, l'IP 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, tout comme votre ordinateur actuellement, sera certainement 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.

Cliquez pour afficher l'image.

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, 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.) :

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

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 avez le cœur aventurier, vous voudrez peut-être penser à 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 :

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. 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.3. Une liste de miroirs est disponible en ligne.

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 media (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.

Notez que 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. On n'en a pas besoin, on appuie donc juste sur "Entrée" :

>> OpenBSD/amd64 CDBOOT 3.28
boot> 

On lance l'installation en entrant "I" :

Welcome to the OpenBSD/amd64 6.2 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 choisi 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 choisi 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. Toutefois, un serveur déconnecté, c'est presque antinomique.

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 cela dit.

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 le 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]
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]

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 permet de supprimer la partition 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 :

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 :

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.

Pour ajouter un set, saisissez simplement son nom, par exemple game63.tgz. Pour retirer un set, saisissez son nom précédé du signe moins : -game63.tgz. En cas de doute, laissez coché le set proposé.

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] base62.tgz  [X] game62.tgz    [X] xfont62.tgz
  [X] bsd.rd  [X] comp62.tgz  [X] xbase62.tgz   [X] xserv62.tgz
  [ ] bsd.mp  [X] man62.tgz   [X] xshare62.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. Donc si vous avez un pc mono processeur, vous prenez bsd. Si vous avez un pc multi processeur, ou multi cœur (multi core), vous prenez bsd.mp. Si vous ne savez pas, vous installez les deux. Dans tous les cas, ensuite, quand OpenBSD va finaliser l'installation, il va choisir celui qui lui faut, en fonction de votre machine, et faire l'assemblage du "noyau unique", avec le bon "bsd", ou "bsd.mp".

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 base62.tgz    100% |**************************| 52181 KB
…
…
Installing xserv62.tgz    100% |**************************| 22686 KB
Location of sets? (cd0 disk http or 'done' [done]

Le fuseau horaire peut être modifié :

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

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!
To boot the new system, enter 'reboot' at the command prompt.
When you login to your new system the first time, please read your 
mail using the 'mail' command.

#

Et voilà, l'installation est terminée, on peut redémarrer avec la commande reboot.

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 :

https://ftp.fr.openbsd.org/pub/OpenBSD

ou :

ftp://ftp2.fr.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. 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 :

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

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 ne voyez pas arriver les mails de vos tentatives d'envoi, vérifiez s'ils ne sont pas bloqués, en utilisant la commande :

smtpctl show stats

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

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 }"

Ensuite, on autorise les visiteurs éventuels à accéder à votre serveur. Ce seront des connexions dites "entrantes", on utilisera donc le mot clé "in". Ces derniers entreront par l'interface réseau "re0" qui correspond à un câble ethernet dans l'exemple. Si vous ne connaissez pas cette interface, lisez le paragraphe qui explique comment la trouver.

pass in quick on re0 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 re0 (on re0) 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 re0 

Cela nous donne au final :

tcp_pass = "{ 80 443 }"
block log

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

Facile, non ?

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

pass out on re0 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 service internes (comme 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 re0 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…

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

2.3. SSH : administrer à distance

2.3.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.

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 -p 222 toto@votredomaine.com

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

2.3.2. Connexion sans mot de passe

Il y a des situations où c'est tout de même plus pratique de pouvoir se connecter au serveur sans avoir à entrer le mot de passe, par exemple dans certains scripts ou juste par fainéantise. C'est heureusement possible grâce à un jeu de clés. Voici la marche à suivre :

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

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 rsa -b 4096 -f ~/.ssh/votreserveur -o -a 64

On se sert du chiffrement RSA avec les bonnes options pour une sécurité/facilité optimale. Sachez qu'il en existe d'autres, vous pouvez lire la partie sur ssh avancé pour en apprendre un peu plus. 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/votreserveur

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/votreserveur.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/votreserveur.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?

2.4. SFTP : Envoyer des fichiers sur le serveur

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 codes d'identification habituels.

Pour copier des fichiers, vous pouvez utiliser la commande scp qui s'utilise ainsi :

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

On peut aussi plus simplement utiliser un client graphique comme décrit plus bas.

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 peu plus compliquée.

2.4.1. Transferts avec Firefox

C'est la solution sans doute la plus simple pour ceux qui utilisent déjà ce navigateur. On va ajouter un module à Firefox qui s'appelle Fireftp.

Après installation de l'addon, entrez dans la barre d'adresse de Firefox ceci :

sftp://utilisateur@chezmoi.tld:222

Remplacez 222 par le port ssh du serveur (22 par défaut). Bien sûr, "utilisateur" est aussi à remplacer (par exemple jean_eudes ou toto).

Un mot de passe vous est demandé, il suffit de le taper.

Cliquez pour afficher l'image.

Reste à utiliser les flèches centrales pour envoyer ou récupérer des documents.

2.4.2. Transferts avec Filezilla

On peut aussi utiliser le logiciel Filezilla qui permettra de se connecter au serveur.

Vous pouvez le télécharger ou l'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 pour afficher l'image.

Cliquez sur "Nouveau Site", puis remplissez les champs ainsi :

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.

2.5. 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 et éventuellement les ports de programmes 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.5.1. Mettre les paquets à jour

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

# pkg_add -u

Oui, c'est tout.

Cela ne sera pas nécessaire la plupart du temps sauf lors d'un changement de version. En effet, les failles importantes de sécurité sont corrigées dans le système (voir paragraphe suivant). Si la faille concerne un paquet, il faut alors passer par les ports pour le mettre à jour. Vous pouvez aussi utiliser le service M:Tier décrit un peu plus loin.

2.5.2. Mettre le système à jour

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

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 architecture 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 rapidement par la suite.

2.5.2.1. Mise à jour automatique avec openup

M:tier met à disposition un script qui automatise et facilite la mise à jour du système OpenBSD et des paquets. Ce dernier n'est pas développé par OpenBSD, son utilisation n'engage que vous. Pour l'utiliser :

Simple, non?

En somme, ça tient en une ligne :

# ftp -o- https://stable.mtier.org/openup | sh

2.5.2.2. 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_3 -P src
# cvs -qd anoncvs@anoncvs.fr.openbsd.org:/cvs get -rOPENBSD_6_3 -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_3 -Pd
# cd /usr/ports
# cvs -q up -rOPENBSD_6_3 -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_3:

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

cvs diff -u -rOPENBSD_6_3

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
# 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

Voilà, rien de plus qu'une série de petites commandes.

2.5.3. Être averti des mises à jour

Pour savoir si des mises à jour doivent être appliquées, vous pouvez recevoir un mail de la part de l'équipe OpenBSD.

Inscrivez-vous à quelques listes de diffusion en envoyant un mail à majordomo@OpenBSD.org. 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 avec dedans :

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

La page errata contient la liste des patchs de sécurité disponibles.

2.5.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.1 à la 6.2.

2.6. 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 :

2.6.1. 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.

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.

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

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

2.6.2. Sauvegarde 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, tapez ceci :

boot > machine diskinfo

2.6.3. Sauvegarde de vos données personnelles

Nous allons utiliser la seconde partition du disque externe pour y sauvegarder nos données. 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, tapez mount -a.

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

Pour un exemple d'utilisation, installez rsync sur le serveur et sur un ordinateur qui devra être sauvegardé.

À 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. 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 présente un minimum de fonctionnalités, mais sa légèreté le rend d'autant plus simple à configurer. 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.

3.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/exemples) 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 :

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".

3.2. PHP

3.2.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.0.23

Pour lister toutes les versions de PHP disponibles, tapez :

# pkg_info -Q php

Ensuite, on active PHP et on le démarre :

# rcctl enable php70_fpm
# rcctl start php70_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.

3.2.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é.

3.2.2.1. Modifier la configuration de PHP

On peut souhaiter modifier la configuration de PHP. Il faut pour cela éditer le fichier /etc/php-7.0.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

3.2.2.2. 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.0.sample. Afin de les activer, il faut les relier dans le dossier /etc/php-7.0. On peut le faire en deux commandes :

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

Ainsi, toutes les extensions à PHP sont activées. Pensez-y si vous en installer 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):

3.2.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. 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. Cela permettra à PHP d'être capable de résoudre les noms de domaines, vérifier les certificats SSL, être à l'heure… Ce n'est pas obligatoire, mais ça vous simplifiera grandement la vie.

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
# cp /etc/ssl/cert.pem etc/ssl/cert.pem

Ces fichiers ne doivent qu'être lisibles :

chmod -R 444 /var/www/etc/

Les fichiers copiés servent notamment à :

Vous aurez peut-être besoin d'être capable d'envoyer des mails à partir de vos sites. 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 php70_fpm.

3.2.3. PHP et W^X

OpenBSD active par défaut la protection mémoire W^X. Cette précaution peut empêcher certains programmes de fonctionner correctement, comme PHP.

Normalement, à partir d'OpenBSD en version 6.0, tout est prévu et vous n'avez rien à modifier. Sinon, vérifiez dans le fichier /etc/fstab qu'il y a l'option wxallowed sur /usr/local :

e0ca6b318b796701.f /usr/local ffs rw,nodev,wxallowed 1 2

3.2.4. PHP et la compression gzip

Vous pouvez compresser à la volée les données afin de réduire l'utilisation de la bande passante, au prix d'une consommation processeur plus importante. Dans le fichier de configuration de php; modifiez les lignes correspondant à zlib

zlib.output_compression = On

; http://php.net/zlib.output-compression-level
zlib.output_compression_level = -1

Attention toutefois, activer cette option peut entrer en conflit avec certaines pages PHP si ces dernières appellent leur propre méthode de compression.

3.3. HTTPS

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

Procurez-vous tout d'abord un certificat SSL (lisez le paragraphe concerné si besoin).

Ensuite, on va préciser dans la configuration d'un site le chemin vers le certificat et vers la clé privée.

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

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

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"
}

3.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.

3.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 :

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 :

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.

3.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 :

ext_ip = 192.168.1.2

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

  return error
  pass
}

relay "www" {
  listen on $ext_ip port 80
  protocol "http"
  forward to 127.0.0.1 port 8080 
}

Voici ce que ces lignes signifient :

Puisque relayd est relié à httpd par le port 8080, il faut modifier la configuration de ce dernier pour lui dire d'écouter en local sur le bon port. Dans le fichier /etc/httpd.conf, nous aurons alors :

listen on 127.0.0.1 port 8080

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

# rcctl enable relayd
# rcctl restart httpd
# rcctl start relayd

Désormais, lorsque vous accéderez à votre site, vous passerez par relayd (port 80) qui fera l'intermédiaire avec httpd (port 8080).

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.

3.6.1. 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 met 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 :

ext_ip = 192.168.1.2

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

relay "www" {
    listen on $ext_ip port 80
    protocol "http"
    forward to 127.0.0.1 port 8080 
}

3.6.2. 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 qui renvoie tout ce qui arrive sur le port 443 vers le port 8443 en local avec support tls :

ext_ip = 192.168.1.2

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

  return error
  pass
  tls { no client-renegotiation, cipher-server-preference }
}

relay "tlsforward" {
  listen on $ext_ip port 443 tls
  protocol "https"
  forward to 127.0.0.1 port 8443 check tcp
}

Désormais, dans la configuration de httpd, il n'y a plus de directives relatives à tls, c'est relayd qui s'en charge. La configuration dans httpd.conf contiendra donc :

listen on localhost port 8443
hsts

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:port.key pour la clé et dans /etc/ssl/adresse:port.crt pour le certificat. Ici, "adresse" est l'IP locale de votre serveur 192.168.1.2. Dans le cas où vous auriez récupéré un certificat avec acme-client, vous pouvez alors faire des liens symboliques ainsi :

# ln -s key "/etc/ssl/acme/private/chezmoi.tld-privkey.pem" /etc/ssl/private/192.168.1.2:443.key
# ln -s certificate "/etc/ssl/acme/chezmoi.tld-fullchain.pem" /etc/ssl/192.168.1.2:443.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 😉

Si vous êtes en IPv6, la configuration se fait de la même façon. Veillez toutefois à indiquer l'IPv6 complète (sans "::") dans la configuration de relayd

ext_ipv6 =  2001:41d0:fe3c:6a00:0:0:0:1bad

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

3.7. Les bases de données

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

Par exemple, si on prend le cas d'un blog, alors 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.

3.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.

3.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 le paquet php-mysqli-7.0.* 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.

3.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 :

3.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.0.*. 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 -E UTF8 -A md5 -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' 

Ce dossier doit d'ailleurs être modifié ainsi :

# chmod a+rw /var/www/tmp

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.

3.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.

3.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 rsync, pas besoin de vous compliquer pas la vie.

3.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.

3.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.

3.8. Exemples de services WEB

Cette section propose des exemples de services que vous pouvez auto-héberger. Il conviendra de ne pas reproduire tête baissée les procédures indiquées, et de vérifier que la démarche est à jour avec la version du service que vous souhaitez installer. Après l'installation, il est vivement conseillé de mettre à jour vos applications 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 avec
    # 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.

3.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. Il sera instructif de regarder comment le mainteneur du paquet de nextcloud a organisé ce service.

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

# mkdir /var/www/htdocs/nextcloud

Ensuite, sans surprise, on le télécharge.

# cd /var/www/htdocs/nextcloud
# ftp "https://download.nextcloud.com/server/releases/nextcloud-12.0.3.tar.bz2"

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-12.0.3.tar.bz2.sha256"

Et on vérifie l'archive :

# sha256 -C nextcloud-12*.sha256 nextcloud*.tar.bz2
(SHA256) nextcloud-12.0.3.tar.bz2: OK

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

# tar xvjf nextcloud-12*.tar.bz2
# chown -R www:daemon 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/nextcloud" 
        directory index index.php
        hsts
        tls {
            certificate "/etc/ssl/acme/chezmoi.tld-fullchain.pem"
            key "/etc/ssl/acme/private/chezmoi.tld-privkey.pem"
        }

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

        # First deny access to the specified files
        location "/db_structure.xml" { block }
        location "/.ht*"             { block }
        location "/README"           { block }
        location "/data*"            { block }
        location "/config*"          { block }

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

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-intl php-mcrypt php-zip php-ldap php-pear

On active ces extensions :

# cd /etc/php-7.0.sample
# for i in *; do ln -sf ../php-7.0.sample/$i ../php-7.0/; done

Note : Parmi ces extensions, je vous propose l'utilisation de redis qui mettra en cache votre cloud pour de meilleurs performances. Cependant, il n'est pour l'instant disponible que pour php-5.6. Si vous utilisez php-7.0 ou supérieur, vous pouvez passer cette étape Nous l'installons puis le lançons.

# pkg_add redis pecl-redis
# rcctl enable redis
# rcctl start redis

Puis reprenez les deux lignes permettant d'activer les extensions PHP au-dessus.

Enfin, on recharge httpd et PHP avec :

# rcctl reload httpd
# rcctl restart php70_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 :

Cliquez pour afficher l'image.

Cliquez pour afficher l'image.

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.0.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.

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.

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/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.

3.8.2. Un espace de stockage avec BoZoN

BoZoN est ce qu'on peut appeler un cloud simplifié. Il vous permettra de stocker vos documents sur votre serveur et de les partager facilement. Il n'a pas besoin de base de données pour fonctionner et remplacera dropbox dans la plupart des cas.

Tout ce dont vous aurez besoin pour Bozon, c'est du serveur httpd et de PHP.

On télécharge Bozon avec l'archive présente sur github . Avec l'outil ftp, on le fait ainsi :

# ftp -o /tmp/bozon.zip "https://github.com/broncowdd/BoZoN/archive/master.zip"

On décompresse l'archive dans /var/www/htdocs, puis on renomme le dossier créé avant d'en changer les droits pour le serveur web (http) :

# cd /var/www/htdocs
# unzip /tmp/bozon.zip
# mv BoZoN-master bozon
# chown -R www:daemon /var/www/htdocs/bozon

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

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

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

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

        # Protect some files
        location "/uploads*"           { block }
        location "/private*"           { block }
        location "/thumbs*"            { block }
        location "/core/"              { block }
        location "/core/*.js"          { pass }
        location "/private/temp/*.zip" { pass }
}

On recharge httpd avec rcctl reload httpd puis on se dirige à l'adresse https://bozon.chezmoi.tld/ pour finir l'installation.

Vous pouvez alors utiliser BoZon. Cliquez sur "Se connecter" pour créer un compte administrateur.

Pour augmenter la restriction en taille des fichiers que vous aurez à envoyer, vous devez modifier le fichier /etc/php-7.0.ini afin de changer les valeurs dans les variables suivantes :

post_max_size = 500M
upload_max_filesize = 500M

3.8.3. Un Webmail

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

3.8.3.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
        hsts
        tls {
            certificate "/etc/ssl/acme/chezmoi.tld-fullchain.pem"
            key "/etc/ssl/acme/private/chezmoi.tld-privkey.pem"
        }
        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.

3.8.3.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".

Cliquez pour afficher l'image.

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. Toutefois, puisque vos mails sont sur votre serveur, vous pouvez vous contenter de préciser localhost.

Cliquez pour afficher l'image.

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

Cliquez pour afficher l'image.

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

Cliquez pour afficher l'image.

3.8.3.2. Roundcubemail

Nous allons ici installer le très connu roundcube. Cette application est complète, toutefois relativement complexe à installer.

Installons tout d'abord quelques dépendances :

# pkg_add sqlite3
# pkg_add php-pspell-7.0.23 php-zip-7.0.23 php-mcrypt-7.0.23 
# pkg_add php-intl-7.0.23 pear php-ldap-7.0.23

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

[suhosin]
suhosin.session.encrypt = 0

Une fois cette modification effectuée, relancez PHP :

# rcctl enable php70_fpm
# rcctl restart php70_fpm

On va mettre roundcube dans le dossier /var/www/htdocs/roundcube, dossier que l'on doit créer :

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

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

# cd /var/www/htdocs/roundcube
# ftp -o roundcube.tgz https://github.com/roundcube/roundcubemail/releases/download/1.3.1/roundcubemail-1.3.1-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/roundcube/db

La commande suivante crée la base :

# cd /var/www/htdocs/roundcube
# sqlite3 -init roundcube/SQL/sqlite.initial.sql roundcube/db/sqlite.db
-- Loading resources from SQL/sqlite.initial.sql

SQLite version 3.9.2 OpenBSD
Enter ".help" for usage hints.

(Tapez .exit pour quitter sqlite3)

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

# cd /var/www/htdocs/roundcube
# 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/acme/chezmoi.tld-fullchain.pem"
            key "/etc/ssl/acme/private/chezmoi.tld-privkey.pem"
        }
        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 :

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/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/roundcube/installer

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

Cliquez pour afficher l'image.

3.8.4. Héberger son blog

3.8.4.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'aggré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://github.com/BlogoText/blogotext/archive/3.7.6.tar.gz"

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-3.7.6 blogotext

Maintenant, on modifie les droits 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 1537919488
    hsts
    tls {
        certificate "/etc/ssl/acme/chezmoi.tld-fullchain.pem"
        key "/etc/ssl/acme/private/chezmoi.tld-privkey.pem"
    }

    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/.

Cliquez pour afficher l'image.

Cliquez pour afficher l'image.

Cliquez pour afficher l'image.

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.

3.8.4.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 1537919488
        hsts
        tls {
            certificate "/etc/ssl/acme/chezmoi.tld-fullchain.pem"
            key "/etc/ssl/acme/private/chezmoi.tld-privkey.pem"
        }

        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 

3.8.5. Gestionnaires de contenus (CMS)

3.8.5.1. Wordpress

Wordpress est un moteur très 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.0.10 mariadb-server
# cd /etc/php-7.0.sample
# for i in *; do ln -sf ../php-7.0.sample/$i ../php-7.0/; done
# rcctl restart php70_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 droits 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/acme/chezmoi.tld-fullchain.pem"
            key "/etc/ssl/acme/private/chezmoi.tld-privkey.pem"
        }
        # Set max upload size to 513M (in bytes)
        connection max request body 537919488

        # 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.

Cliquez pour afficher l'image.

Cliquez pour afficher l'image.

Cliquez pour afficher l'image.

Cliquez pour afficher l'image.

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.

3.8.5.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/acme/chezmoi.tld-fullchain.pem"
        key "/etc/ssl/acme/private/chezmoi.tld-privkey.pem"
    }

    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 :

Cliquez pour afficher l'image.

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.

3.8.5.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é et configuré PHP. Vous pouvez utiliser n'importe quelle basse 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 https://ftp.drupal.org/files/projects/drupal-8.4.0.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*.tar.gz
# 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 537919488
        hsts
        tls {
            certificate "/etc/ssl/acme/chezmoi.tld-fullchain.pem"
            key "/etc/ssl/acme/private/chezmoi.tld-privkey.pem"
        }

        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.

Cliquez pour afficher l'image.

Cliquez pour afficher l'image.

Cliquez pour afficher l'image.

Cliquez pour afficher l'image.

Cliquez pour afficher l'image.

Cliquez pour afficher l'image.

Cliquez pour afficher l'image.

Cliquez pour afficher l'image.

Et voilà, vous êtes prêts à fabriquer votre site.

3.8.5.4. Spip

Spip est un gestionnaire de contenu simplifié, qui permet notamment de déployer facilement son site web.

Spip nécessite l'installation de PHP avec l'activation des modules.

3.8.5.4.1. Choix d'une base de données

Selon ce que vous préférez, vous pouvez choisir votre base de données : MySQL ou SQLite. MySQL est complet et conviendra pour un site conséquent, mais est plus difficile à mettre en place. SQLite est extrêmement simple, tout en restant performant. Pour de l'auto-hébergement, SQLite me semble le choix le plus approprié.

Avec SQLite, installez le paquet sqlite3 : pkg_add sqlite3. Et c'est tout! Vous pouvez passer à la partie suivante.

Pour MySQL, suivez les indications détaillées dans la partie qui lui est dédié afin de créer une nouvelle base. Pensez à installer le paquet php-mysqli-7.0.*.

3.8.5.4.2. Préparation de Spip

On va créer le dossier qui recevra spip :

mkdir -p /var/www/htdocs/spip

On télécharge l'installateur de spip dans ce dossier avec la commande suivante :

ftp -o /var/www/htdocs/spip/spip_loader.php "http://www.spip.net/spip-dev/INSTALL/spip_loader.php"

On modifie les droits pour le serveur web :

chown -R www:daemon /var/www/htdocs/spip
3.8.5.4.3. Configuration du serveur web (http) pour spip

On édite le ficher /etc/httpd.conf pour y indiquer ceci :

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

server "chezmoi.tld" {
        listen on * tls port 443
        root "/htdocs/spip"
        directory index index.php
        hsts
        tls {
            certificate "/etc/ssl/acme/chezmoi.tld-fullchain.pem"
            key "/etc/ssl/acme/private/chezmoi.tld-privkey.pem"
        }
        log access "spip.log"
        log error "spip-error.log"

        # Set max upload size to 513M (in bytes)
        connection max request body 537919488

        # Interdiction d'accès
        location "/tmp*" { block }
        location "/config*"             { block }
        location "/local*"           { block }

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

Remplacez chezmoi.tld par votre nom de domaine, et hop, le tour est joué! Relancez httpd avec cette commande : rcctl reload httpd.

Dirigez-vous maintenant à l'adresse https://chezmoi.tld/spip_loader.php pour terminer l'installation.

Cliquez pour afficher l'image.

Cliquez pour afficher l'image.

Cliquez pour afficher l'image.

Cliquez pour afficher l'image.

Cliquez pour afficher l'image.

Cliquez pour afficher l'image.

Cliquez pour afficher l'image.

Une fois l'installation terminée, supprimez le fichier spip_loader.php :

rm /var/www/htdocs/spip/spip_loader.php

3.8.6. Wallabag

Wallabag permet de sauvegarder des pages web pour les lire plus tard. On le décrit comme une application de "read-it-later". Voici comment l'installer.

On récupère wallabag dans le dossier /tmp :

$ cd /tmp
$ ftp https://wllbg.org/latest-v2-package && tar xvzf latest-v2-package

On installe wallabag dans /var/www/htdocs :

# mv /tmp/release* /var/www/htdocs/wallabag
# chown -R www:daemon /var/www/htdocs/wallabag

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

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

server "bag.chezmoi.tld" {
    listen on * tls port 443
    root "/htdocs/wallabag/web" 
    directory index app.php
    hsts
    tls {
        certificate "/etc/ssl/acme/chezmoi.tld-fullchain.pem"
        key "/etc/ssl/acme/private/chezmoi.tld-privkey.pem"
    }

# on bloque tous les scripts php sauf celui utile
    location "/*.php"          { block }

# on reformate l'URL si besoin
    location match "^/[^(app.php)]/(.*)$" {
        block return 301 "https://$SERVER_NAME/app.php/%1"
    }
    location "/" {
        block return 301 "https://$SERVER_NAME/app.php/"
    }

# On sert les pages
    location "/app.php/*" {
        fastcgi socket "/run/php-fpm.sock"
    }
}

Il ne vous reste plus qu'à relancer httpd puis à aller sur votre site. Les identifiants par défaut sont wallabag/wallabag. Créez un nouveau compte ou modifiez ce dernier pour terminer l'installation.

3.8.7. 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/acme/chezmoi.tld-fullchain.pem"
        key "/etc/ssl/acme/private/chezmoi.tld-privkey.pem"
    }

    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.

Cliquez pour afficher l'image.

Cliquez pour afficher l'image.

Cliquez pour afficher l'image.

3.8.7.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 Thunderbid à partir du menu des modules accessible dans le menu de Thunderbird remarquable par ses 3 traits horizontaux en haut à droite.

Cliquez pour afficher l'image.

Il faudra cliquer sur le petit engrenage pour choisir d'installer à la main l'extension précédemment téléchargée :

Cliquez pour afficher l'image.

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.

Cliquez pour afficher l'image.

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/ :

Cliquez pour afficher l'image.

Pour un carnet d'adresses, l'URL à renseigner est la suivante :

https://dav.chezmoi.tld/card.php/addressbooks/UTILISATEUR/CARNET/

3.8.7.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" :

Cliquez pour afficher l'image.

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/

Cliquez pour afficher l'image.

Cliquez pour afficher l'image.

3.8.8. 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
    connection max request body 537919488
    hsts
    tls {
        certificate "/etc/ssl/acme/chezmoi.tld-fullchain.pem"
        key "/etc/ssl/acme/private/chezmoi.tld-privkey.pem"
    }

    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.

Cliquez pour afficher l'image.

Une fois l'installation terminée, supprimez le fichier install.php

# rm /var/www/htdocs/wiki/install.php

3.8.9. 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.

3.8.9.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).

Profitez 😉

Cliquez pour afficher l'image.

3.8.9.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/acme/chezmoi.tld-fullchain.pem"
        key "/etc/ssl/acme/private/chezmoi.tld-privkey.pem"
    }

    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 pour afficher l'image.

Cliquez pour afficher l'image.

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

Cliquez pour afficher l'image.

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.0 /var/www/htdocs/ttrss/update.php --feeds --quiet

3.8.10. Statistiques des visites sur vos sites

3.8.10.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 :

D'autres outils similaires existent, en particulier piwik. 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 piwik.

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 :

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/acme/chezmoi.tld-fullchain.pem"
        key "/etc/ssl/acme/private/chezmoi.tld-privkey.pem"
    }
}

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.

3.8.10.2. Avec Piwik

Piwik 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 piwik:

# mysql -u root -p
mysql> CREATE DATABASE piwik_db_name_here;
mysql> CREATE USER 'piwik'@'localhost' IDENTIFIED BY 'password';
mysql> GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES ON piwik_db_name_here.* TO 'piwik'@'localhost';

Ensuite, on télécharge piwik dans le dossier /var/www/htdocs/piwik :

# mkdir -p /var/www/htdocs/piwik
# cd /var/www/htdocs/piwik
# ftp -o /tmp/piwik.zip "http://builds.piwik.org/piwik.zip" && unzip /tmp/piwik.zip

Configurez maintenant un nouveau site dans le fichier /etc/httpd.conf :

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

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

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

Modifiez les droits sur ce dossier :

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

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 piwik.

N'oubliez pas d'ajouter à vos pages web le code d'intégration donné.

4. 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.

Notez que certains fournisseurs d'accès à internet bloquent les mails sortant (port 25). Renseignez-vous avant d'avoir une mauvaise surprise.

La configuration proposée correspond à une gestion d'un nombre d'utilisateur raisonnable. Si vous souhaitez des centaines de comptes, l'utilisation d' utilisateurs virtuels est décrite plus loin.

4.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 :

Si vous disposez d'une IPv6, la configuration est identique, il suffit seulement d'enregistrer un champ AAAA à la place du champ A.

Certains spécifient un champ A différent du domaine principal afin de gérer des backups 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.

4.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.

4.3. 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).

Pour configurer opensmtpd, on édite /etc/mail/smtpd.conf.

4.3.1. Serveur mail avec un nombre moyen d'utilisateurs

table aliases file:/etc/mail/aliases

pki chezmoi.tld key "/etc/ssl/acme/private/chezmoi.tld-privkey.pem"
pki chezmoi.tld certificate "/etc/ssl/acme/chezmoi.tld-fullchain.pem"
ca chezmoi.tld certificate "/etc/ssl/acme/chezmoi.tld-fullchain.pem"


# Deliver
listen on lo0
listen on re0 port smtp hostname chezmoi.tld tls pki chezmoi.tld
listen on re0 port submission hostname chezmoi.tld tls-require pki chezmoi.tld auth

accept from local for local  alias <aliases> deliver to maildir "~/Maildir"
accept from any for domain "chezmoi.tld" deliver to maildir "~/Maildir"

# Relay
accept from local for any relay 

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. Vous avez certainement déjà remarqué que la syntaxe ressemble beaucoup à celle du parefeu.

Les lignes suivantes servent à l'envoi du courrier :

Les lignes suivantes concernent la réception du courrier :

Et enfin on envoie le courrier destiné aux autres serveurs :

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:

chezmoi.tld

Nous pouvons maintenant activer et relancer le serveur smtpd :

# rcctl enable smtpd
# rcctl restart smtpd

Voilà pour opensmtpd.

4.3.2. 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 = *, [::]

# On stocke en Maildir
mail_location = maildir:~/Maildir

# imap > pop
protocols = imap

# Securisation. Editez ces lignes
ssl = yes
ssl_cert = </etc/ssl/acme/chezmoi.tld-fullchain.pem
ssl_key = </etc/ssl/acme/private/chezmoi.tld-privkey.pem
disable_plaintext_auth = yes

# methodes d'authentification
passdb {
        driver = bsdauth
}

userdb {
        driver = passwd
}

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.

4.3.3. Ajouter un nouveau compte mail

Un compte mail est en fait un simple compte d'utilisateur. Vous pouvez donc en créer un nouveau avec la commande adduser détaillée plus loin. Il faudra juste veiller à donner à l'utilisateur le shell /sbin/nologin par mesure de sécurité. Ainsi, il ne pourra pas exécuter de commandes sur le serveur.

4.4. 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/aliases, puis d'y ajouter une ligne comme celle-ci :

bibi: jean-eudes@ouaf.xyz

Vous pouvez aussi faire des redirections internes au serveur, très utile pour l'adminstration système:

root: jean
hostmaster: root
postmaster: root
webmaster:  arthur

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 les commandes suivantes :

# newaliases
# rcctl restart smtpd

C'est tout! Je vous l'avais dit que c'était simple.

4.5. 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 :

Vous souhaiterez peut-être plutôt utiliser un webmail, afin d'accéder à votre messagerie à partir d'un navigateur web.

4.6. 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.

4.6.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).

4.6.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"

4.6.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 qui permettra au destinataire de vérifier que le mail reçu provient bien de votre serveur avec la signature.

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

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 600 private.key
    

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 :

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.

accept tagged DKIM for any relay

Enfin, les messages pas encore signés sont envoyés à dkimproxy :

accept from local for any relay via smtp://127.0.0.1:10027

Le fichier /etc/mail/smtpd.conf ressemble désormais à ça :

table aliases file:/etc/mail/aliases

pki chezmoi.tld key "/etc/ssl/acme/private/chezmoi.tld-privkey.pem"
pki chezmoi.tld certificate "/etc/ssl/acme/chezmoi.tld-fullchain.pem"
ca chezmoi.tld certificate "/etc/ssl/acme/chezmoi.tld-fullchain.pem"

# Deliver
listen on lo0
listen on lo0 port 10028 tag DKIM
listen on re0 port 25 hostname chezmoi.tld tls pki chezmoi.tld
listen on re0 port 587 hostname chezmoi.tld tls-require pki chezmoi.tld auth

accept from local for local  alias <aliases> deliver to maildir "~/Maildir"
accept from any for domain "chezmoi.tld" deliver to maildir "~/Maildir"

# Relay
# dkim tagged can be sent
accept tagged DKIM for any relay
# if not dkim tagged, send it to dkimproxy
accept from local for any relay via smtp://127.0.0.1:10027

Ça va? Vous suivez toujours? Je vois à votre regard pétillant que vous attendez la fin avec impatience!

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 :

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

Pour vérifier que vous n'êtes pas en 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 :

Cliquez pour afficher l'image.

Cliquez pour afficher l'image.

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…).

4.7. Installer un antispam

Votre serveur n'est actuellement pas à l'abri des spams. Nous allons donc voir une méthode simple avec spamassassin pour s'en protéger.

Notez qu'il existe des techniques plus efficaces mais nettement 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 😁.

4.7.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 "NOSPAM", 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 NOSPAM

# Message venant du système
accept from local for local alias <aliases> deliver to maildir "~/Maildir"
# Message NOSPAM
accept tagged NOSPAM for domain "chezmoi.tld" deliver to maildir "~/Maildir"
# Message venant d'ailleurs, on scanne avec spamassassin
accept from any for domain "chezmoi.tld" relay via smtp://127.0.0.1:10025

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.

À ce point du document, le serveur smtp fonctionne ainsi :

Cliquez pour afficher l'image.

4.7.2. Antispams 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.

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
}

Afin que les dossiers que nous allons utiliser pour classer les mails soient automatiquement créés, on ajoute aussi ces quelques lignes :

namespace inbox {
  mailbox Drafts {
    special_use = \Drafts
	auto = subscribe
  }
  mailbox Junk {
    special_use = \Junk
	auto = subscribe
  }
  mailbox Trash {
    special_use = \Trash
	auto = subscribe
  }
  mailbox Sent {
    special_use = \Sent
	auto = subscribe
  }
}

Enfin, toujours dans le même fichier, on configure ce plugin :

plugin {
  sieve_plugins = sieve_imapsieve sieve_extprograms

  # From elsewhere to Spam folder
  imapsieve_mailbox1_name = Spam
  imapsieve_mailbox1_causes = COPY
  imapsieve_mailbox1_before = file:/usr/local/lib/dovecot/sieve/report-spam.sieve

  # From Spam folder to elsewhere
  imapsieve_mailbox2_name = *
  imapsieve_mailbox2_from = Spam
  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/.

On fait maintenant en sorte que sieve tienne compte de ces fichiers avec les commandes suivantes :

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.

4.7.2.1. Scripts 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
	exec /usr/local/bin/sa-learn -u ${1} --spam
fi
exit 0

Et ensuite le contenu du fichier sa-learn-ham.sh

#!/bin/sh
if [ $# -eq 1 ]; then
	exec /usr/local/bin/sa-learn -u ${1} --ham
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.

4.7.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.

4.7.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. 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 spamdb régulièrement.

4.7.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:4242"
# 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".

# rcctl enable spamlogd
# rcctl start spamlogd

On va maintenant éditer la configuration du parefeu et filtre de paquets (packet filter). 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 from any 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 :

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 ajoutez la ligne suivante :

*/10  *  *  *  *  /usr/libexec/spamd-setup

Pour l'édition, référez-vous aux rappels sur l'utilisation de vi.

Nous lançons ici spamd-setup toutes les 10 minutes. Ce temps doit être inférieur au temps que doit attendre un expéditeur pour tenter de renvoyer son message définit dans l'appel de spamd. Nous avions mis 25 minutes.

4.7.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>

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.

4.7.3.4. Utiliser des listes noires 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. À l'intérieur, nous mettrons :

all:\
        :nixspam:bsdlyblack

# 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

Il faut penser à ajouter après le all les deux listes utilisées par la suite, qui sont celles de nixspam et de bsdly.net. Pour plus d'information, voir :

4.7.3.5. 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 :

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"

4.7.3.6. 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.

4.7.3.6.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.

Voici un script qui se charge d'enregistrer ces adresses dans le fichier /etc/mail/whitelist.txt :

#!/bin/sh
# Auteur :      thuban <thuban@yeuxdelibad.net>
# licence :     MIT

# add to spamd some ip to whitelis from domain list
# to /etc/mail/whitelist.txt

# insert this to /etc/mail/spamd.conf (whitelist must be last)


#all:\
#						:nixspam:whitelist:


#whitelist:\
#				:white:\
#				:method=file:\
#				:file=/etc/mail/whitelist.txt:

TMP=$(mktemp)

WHITELIST=/etc/mail/whitelist.txt

DOMAINS='outlook.com
gmail.com
hotmail.com
gog.com
yahoo.com
google.com
live.fr
mail-out.ovh.net
mxb.ovh.net
gandi.net
'

for d in $DOMAINS; do
	echo "$d" | smtpctl spf walk >> "$TMP" 
done
mv "$TMP" "$WHITELIST"
exit 0


libre à vous d'ajouter ou retirer des noms de domaines dans la liste DOMAINS. Je vous invite à appeler ce script via /etc/weekly.local afin de régulièrement mettre à jour la liste des IP.

Pour terminer la configuration, éditez le fichier /etc/mail/spamd.conf pour qu'il tienne compte de cette liste. Mettez tout ce qui concerne la liste blanche en dernier afin qu'elle écrase les éventuels blacklists précédents. Voici à quoi cela ressemble :

all:\
        :nixspam:bgp-spamd: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


whitelist:\
        :white:\
        :method=file:\
        :file=/etc/mail/whitelist.txt:
4.7.3.6.2. Solution communautaire

Vous pouvez déjà commencer par enregistrer une liste pré-remplie d' IP connues comme légitimes (merci à Peter N.M. Hansteen) :

# ftp -o /etc/mail/nospamd http://www.bsdly.net/~peter/nospamd

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

group "spamd-bgp" {
	remote-as $spamdAS
	multihop 64
	announce none	# Do not send Route Server any information

	# 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
}

# 'match' is required, to remove entries when routes are withdrawn
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 | 
	sed -e '1,4d' -e 's/\/.*$//' -e 's/[ \*\>]*//' > /var/mail/spamd.black

/usr/libexec/spamd-setup

/usr/bin/logger -p mail.info -t spamd-update "spamd black list updated; bgp-spamd-bypass: $(/sbin/pfctl -t bgp-spamd-bypass -T show | /usr/bin/wc -l)"

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/mail/spamd.black:
4.7.3.6.3. Liste blanche personnelle

Nous allons créer un script qui va régulièrement vérifier si un de vos contacts n'est pas mis sur liste grise. C'est un complément simple à ce qui est fait ci-dessus sur la base du fichier /etc/mail/nospamd qui contient déjà des IP légitimes.

Enregistrons ce script dans /usr/local/bin/grey-to-white-spamd :

#!/bin/sh
# Auteur :      thuban <thuban@yeuxdelibad.net>
# licence :     MIT

# Fill /etc/mail/allow_in_spamd with regular expression of
# lines shown by spamdb.
# Each matching line will be used to add the corresponding IP
# to /etc/mail/nospamd the spamdb whitelist

WHITE=/etc/mail/allow_in_spamd
SPAMD_WHITE=/etc/mail/nospamd

if [ ! -f $WHITE ]; then
	exit
fi

	while read line; do
		/usr/sbin/spamdb | grep "GREY|" | grep -E "$line" | cut -d'|' -f2 >> $SPAMD_WHITE
	done < $WHITE

# keep uniq
sort -u $SPAMD_WHITE -o $SPAMD_WHITE

# reload pf
/sbin/pfctl -f /etc/pf.conf
exit 0

Pensez à le rendre exécutable :

# chmod +x /usr/local/bin/grey-to-white-spamd

Maintenant, remplissez le fichier /etc/mail/allow_in_spamd avec les adresses mail que vous voulez laisser passer car vous les savez légitimes.

Notez que vous pouvez aussi mettre seulement les domaines autorisés ou un bout de l'address mail. Par exemple :

copain.org
monboss@travail.net

Enfin, afin que le script soit lancé régulièrement, vous pouvez :

4.8. Serveur mail avec beaucoup d'utilisateurs (utilisateurs virtuels)

Si vous gérez de très nombreux comptes, il sera peut-être préférable de gérer des utilisateurs virtuels. 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.

Ce tutoriel est très largement inspiré de celui de la documentation officielle

Vous voudrez peut-être jeter un œil à l'exemple plus complet en fin d'ouvrage permettant une gestion d'utilisateurs virtuels décrite ci-dessous avec aussi plusieurs domaines.

4.8.1. Un utilisateur responsable des mails : vmail

Au lieu de créer plusieurs comptes, on ne va en créer qu'un seul en charge de tous les mails :

# useradd -m -g =uid -c "Virtual Mail" -d /var/vmail -s /sbin/nologin vmail

Cet utilisateur ne peut pas avoir accès à un shell 😁

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 dans par exemple :

/var/vmail/batman/Maildir
/var/vmail/utilisateur/Maildir
/var/vmail/ninja/Maildir
…

4.8.2. smtpd pour des utilisateurs virtuels

Au début du fichier de configuation /etc/mail/smtpd.conf, nous allons définir des "tables" supplémentaires. Ce sont des fichiers textes, tout bêtement.

table aliases file:/etc/mail/aliases   # les alias, comme au chapitre précédent
table passwd passwd:/etc/mail/passwd   # Les mots de passe
table virtuals file:/etc/mail/virtuals # la liste des utilisateurs

Vérifiez bien que opensmtpd-extras est installé.

La suite de la configuration d'smtpd ne change quasiment pas.

Pour la réception de messages :

accept from any virtual <virtuals> deliver to maildir \
	"/var/vmail/%{rcpt.user}/Maildir"

On ne fait qu'accepter les messages pour ceux précisés dans la table <virtuals> et les enregistrer dans le bon dossier selon le nom du destinataire ${rcpt.user.

Pour l'envoi de messages, il faut tenir compte du mot de passe :

listen on re0 port submission hostname chezmoi.tld tls-require pki chezmoi.tld auth <passwd>

Et c'est tout 😁

Il faut maintenant remplir les différents fichiers évoqués plus haut et configurer dovecot.

4.8.2.1. /etc/mail/virtuals

Ce fichier contient la liste des utilisateurs, un par ligne. Il ressemble beaucoup au 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.

4.8.2.2. /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 : :

Afin de chiffrer le mot de passe, utilisez la commande encrypt ainsi :

encrypt -p

Ça vous demander 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.

4.8.2.3. /etc/dovecot/local.conf

Dovecot a lui aussi besoin d'être configuré pour accéder à la liste des mots de passe :

mail_location = maildir:~/Maildir

passdb {
    args = scheme=blf-crypt /etc/mail/passwd
    driver = passwd-file
}

userdb {
    args = uid=vmail gid=vmail home=/var/vmail/%d/%n/
    driver = static
}

4.9. 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 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 :

Vous en trouverez d'autres sur cette page.

5. Serveur de noms

5.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.

Cliquez pour afficher l'image.

(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.

5.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.

5.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 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

	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 au résolveur local 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 3hg.fr
[…]
;; 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*.

5.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 du 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"

5.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

5.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: "chezmoi.tld"

Ici NSD suit cette organisation : chaque zone correspond à un fichier situé dans le dossier /var/nsd/zones portant le nom du domaine. Par exemple /var/nsd/zones/chezmoi.tld. Vous pouvez bien sûr vous organiser différemment. Plus loin lors de la mise en place de DNSSEC, nous utiliserons un autre dossier pour contenir les zones signées.

N'oubliez pas de modifier cet exemple avec l'adresse IP locale du seveur.

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.

5.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 😁

5.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 champs) :

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 :

5.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.

5.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. (Un peu comme l'entropie). 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.

5.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

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.

5.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…).

5.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" :

Cliquez pour afficher l'image.

Choisissez ensuite votre domaine :

Cliquez pour afficher l'image.

Sur la gauche, vous pouvez voir une entrée "Glue Records" :

Cliquez pour afficher l'image.

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.

Cliquez pour afficher l'image.

Entrez maintenant le nom de domaine de votre serveur autoritaire maitre puis l'adresse IP correspondante :

Cliquez pour afficher l'image.

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".

Cliquez pour afficher l'image.

Dans ce nouvel écran, ajoutez en premier (DNS1) l'enregistrement glue défini précédemment. Vous pouvez aussi ajouter des serveurs secondaires, comme par exemple celui de gandi ns6.gandi.net.

Cliquez pour afficher l'image.

On prend ensuite pour exemple l'interface web du registre danois (dk-hostmaster).

Cliquez pour afficher l'image.

(On doit fournir un nom d'hôte complet, ainsi qu'une adresse IP.)

Cliquez pour afficher l'image.

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).

Cliquez pour afficher l'image.

(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.

5.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 :

@     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.

5.3.3. Signer son domaine avec DNSSEC

5.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).

5.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 ZKT (peu maintenu), 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 dans un dossier /var/ldnscripts à partir de l'archive que l'on décompresse :

cd /var
ftp https://framagit.org/22decembre/ldnscripts/repository/master/archive.tar.gz
tar xvzf archive.tar.gz
mv ldnscripts-master* ldnscripts
doas chown $USER ldnscripts
5.3.3.2.1. Configuration

La configuration se déroule en éditant le fichier /var/ldnscripts/conf qui ressemble à ça :

# repository where to find unsigned zone file and specific conf
NS_REP=/etc/ns

# serial : unixtime
# Cannot make it other currently. I could make it YYYYMMDDnn,but how?
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 :

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.

C'est tout pour la configuration 😁

5.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/zone/chezmoi.tld/ est créé, il contient les clés ZSK et KSK.

Le fichier de zone signé est présent dans /var/nsd/signed/chezmoi.tld. Adaptez donc la configuration de nsd pour l'utiliser :

## 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 zones/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.

5.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 :

Ce script s'occupe aussi de supprimer les clés qui ne sont plus utilisées. Il faudra le lancer tous les mois.

Concrètement, voici ce que vous allez faire. Éditez le fichier /etc/monthly.local pour y ajouter :

/var/ldnscripts/ldnscript rollover chezmoi.tld

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 :

/var/ldnscripts/ldnscript signing chezmoi.tld

Enfin, tous les ans, vous créerez une nouvelle KSK ainsi :

/var/ldnscripts/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.

5.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.

5.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 :

Cliquez pour afficher l'image.

(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.)

Cliquez pour afficher l'image.

(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.

Cliquez pour afficher l'image.

À 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.

5.3.3.3.2. Registre danois

On présente ici la méthode du registre danois:

Cliquez pour afficher l'image.

(On doit copier l'empreinte DS dans le champ Digest. Les autres champs doivent bien entendu correspondre.)

Cliquez pour afficher l'image.

(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é.

5.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é 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 bon procédé.

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…).

5.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'occurence 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, voir 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 soit, c'est juste pour se repérer.

Vous pouvez supprimer les fichiers de clé situés dans /tmp sans problème désormais.

5.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

5.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

5.4. Vérifier que cela fonctionne

Vous pouvez utiliser les sites suivants pour vérifier que votre configuration fonctionne comme prévu :

6. Services divers

6.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é.

6.1.1. 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.

6.1.2. 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

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 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.

Cliquez pour afficher l'image.

6.1.3. 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.

6.1.3.1. Installation

Commençons par installer le nécessaire et activer le démon monit :

# pkg_add monit
# rcctl enable monit

6.1.3.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).

6.1.3.3. Lancement de monit

Le démarrage de monit est simple :

# rcctl start monit

6.1.3.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 :

$ 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.

6.1.3.5. Configuration avancée des alertes

Monit peut aussi envoyer des emails 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.

6.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 :

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 22222 utilisateurssh@chezmoi.tld

Remplacez 22222 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 :

Cliquez pour afficher l'image.

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 :

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.

6.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" :

Cliquez pour afficher l'image.

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 :

Cliquez pour afficher l'image.

Sinon, ajoutez l'appareil avec lequel partager vos documents. Pour cela, dans la partie "Autres appareil", cliquez sur "Ajouter un appareil" :

Cliquez pour afficher l'image.

Cliquez pour afficher l'image.

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.

6.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 :

Cliquez pour afficher l'image.

6.4. Seedbox

Ce chapitre décrit comment mettre en place une seedbox, afin de partager et télécharger des fichiers torrent.

6.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 :

Cliquez pour afficher l'image.

6.4.2. Avec rtorrent

rtorrent est un autre client efficace et léger. Il dispose d'une interface en console pour le contrôler, que certains préfèrent à l'interface web de transmission.

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. 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.

# Maximum and minimum number of peers to connect to per torrent.
#min_peers = 40
#max_peers = 100

# Same as above but for seeding completed torrents (-1 = same as downloading)
#min_peers_seed = 10
#max_peers_seed = 50

# Maximum number of simultanious uploads per torrent.
#max_uploads = 15

# Global upload and download rate in KiB. "0" for unlimited.
#download_rate = 0
upload_rate = 20

# Default directory to save the downloaded torrents.
directory = ~/Telechargements/download 

# Default session directory. Make sure you don't run multiple instance
# of rtorrent using the same session directory. Perhaps using a
# relative path?
session = ~/Telechargements/session

# Watch a directory for new torrents, and stop those that have been
# deleted.
schedule = watch_directory,5,5,load_start=~/Telechargements/torrents/*.torrent
schedule = untied_directory,5,5,stop_untied=

# Close torrents when diskspace is low.
#schedule = low_diskspace,5,60,close_low_diskspace=100M

# The ip address reported to the tracker.
#ip = 127.0.0.1
#ip = rakshasa.no

# The ip address the listening socket and outgoing connections is
# bound to.
#bind = 127.0.0.1
#bind = rakshasa.no

# Port range to use for listening.
#port_range = 6890-6999

# Start opening ports at a random position within the port range.
#port_random = no

# Check hash for finished torrents. Might be usefull until the bug is
# fixed that causes lack of diskspace not to be properly reported.
#check_hash = no

# Set whether the client should try to connect to UDP trackers.
#use_udp_trackers = yes

# Alternative calls to bind and ip that should handle dynamic ip's.
#schedule = ip_tick,0,1800,ip=rakshasa
#schedule = bind_tick,0,1800,bind=rakshasa

# Encryption options, set to none (default) or any combination of the following:
# allow_incoming, try_outgoing, require, require_RC4, enable_retry, prefer_plaintext
#
# The example value allows incoming encrypted connections, starts unencrypted
# outgoing connections but retries with encryption if they fail, preferring
# plaintext to RC4 encryption after the encrypted handshake
#
encryption = allow_incoming,require,require_rc4,enable_retry

# Enable DHT support for trackerless torrents or when all trackers are down.
# May be set to "disable" (completely disable DHT), "off" (do not start DHT),
# "auto" (start and stop DHT as needed), or "on" (start DHT immediately).
# The default is "off". For DHT to work, a session directory must be defined.
# 
dht = auto

# UDP port to use for DHT. 
# 
# dht_port = 6881

# Enable peer exchange (for torrents not marked private)
#
# peer_exchange = yes

system.method.set_key = event.download.finished,notify_me,"execute=~/.rtorrent_mail.sh,$d.get_name="

#scgi_port = 127.0.0.1:5000

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 l'excellent 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.

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.

6.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 :

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

6.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 -vd. Vous obtenez une sortie de ce type :

# usbdevs -vd
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 -d | 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.

6.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!

6.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.

6.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.

6.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.

6.7.1. Solution du fainéant : SSH

Si vous avez déjà configuré SSH, vous pouvez utiliser l'outil sshfs 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.

6.7.2. Solution un poil 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 $ext_if 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 😉 .

6.8. Proxy VPN (OpenVPN)

Un VPN veut dire "Réseau privé virtuel". Cela permet de disposer d'un tunnel chiffré à partir de n'importe quel ordinateur pour que tout le trafic sorte par votre serveur. Et dans ce cas, le mot "tunnel" est une image tout à fait adaptée car un VPN présente plusieurs intérêts, notamment :

Convaincu de l'utilité d'un VPN?

La mise en place va se passer en deux temps :

  1. Sur le serveur, nous allons générer des certificats et installer OpenVPN.
  2. Sur les machines qui voudront passer par le tunnel VPN, il faudra faire passer le trafic par notre serveur. Afin de s'identifier, des certificats sont souvent utilisés, mais nous utiliserons plutôt des identifiants et mots de passe.

Cette démarche n'est pas forcément facile. Prenez le temps de lire et relire cette partie et suivez pas à pas les étapes proposées.

Notez aussi que des choix ont été faits afin de simplifier la procédure. Le résultat est donc un compromis entre sécurité et facilité d'utilisation pour l'administrateur et l'utilisateur. On pourra par exemple remarquer que :

Les plus aguerris voudront certainement lire la page suivante pour aller plus loin.

6.8.1. Préparation de la configuration

On commence par installer OpenVPN :

# pkg_add openvpn openvpn_bsdauth

Vous voudrez peut-être lire la documentation fournie avec le paquet :

less /usr/local/share/doc/pkg-readmes/openvpn-2.4.4

Pour l'instant, nous allons créer les dossiers nécessaires à openvpn. Ces derniers contiendront la configuration, les certificats, et on termine par le dossier qui contiendra les journaux d'openvpn :

# install -m 700 -d /etc/openvpn/private
# install -m 755 -d /etc/openvpn/certs
# install -m 755 -d /var/log/openvpn

La commande install est très pratique pour créer des dossiers avec les permissions adéquates.

C'est tout pour l'instant, on y va doucement mais sûrement.

6.8.2. Création des certificats

On va maintenant créer les certificats et autres fichiers servant à l'authentification du serveur. Par simplicité, nous allons utiliser l'outil easy-rsa :

# pkg_add easy-rsa

Afin de créer les fichiers dont on aura besoin, on se place dans un dossier temporaire /tmp/openvpn dans lequel on copie les éléments nécessaires à easy-rsa :

# mkdir -p /tmp/openvpn
# cd /tmp/openvpn
# cp -r /usr/local/share/easy-rsa/* .

On va maintenant configurer easy-rsa en éditant un fichier dont le petit nom est vars. On copie tout d'abord l'exemple donné :

# cp vars.example vars

Éditez ce fichier. Vous devriez changer au moins les variables suivantes selon votre cas:

set_var EASYRSA_REQ_COUNTRY     "FR"
set_var EASYRSA_REQ_PROVINCE    "France"
set_var EASYRSA_REQ_CITY        "Nantes"
set_var EASYRSA_REQ_ORG         "PuffyCorp"
set_var EASYRSA_REQ_EMAIL       "me@chezmoi.tld"
set_var EASYRSA_REQ_OU          "PuffyCorpUnit"

set_var EASYRSA_KEY_SIZE        4096

Ensuite, on va générer les certificats en lançant les commandes suivantes :

# ./easyrsa init-pki
# ./easyrsa build-ca nopass
# ./easyrsa build-server-full server nopass
# ./easyrsa gen-dh

C'est long, il y a des ., des + qui apparaissent, c'est normal.

On en profite pour générer au passage le certificat de révocation, qui vous sera peut-être utile un jour :

# ./easyrsa gen-crl

Une fois terminé, on va changer les permissions sur les fichiers générés :

chown -R _openvpn:wheel pki/*
chmod -R 600 pki/*

On retourne dans le dossier d'openvpn, dans lequel on copie les fichiers créés précédemment :

# cd /etc/openvpn
# cp -p /tmp/openvpn/pki/ca.crt certs/ca.crt
# cp -p /tmp/openvpn/pki/issued/server.crt certs/server.crt
# cp -p /tmp/openvpn/pki/private/server.key private/server.key
# cp -p /tmp/openvpn/pki/dh.pem dh.pem
# cp -p /tmp/openvpn/pki/crl.pem crl.pem

Pensez à supprimer le dossier /tmp/openvpn :

# rm -rf /tmp/openvpn

6.8.3. Configuration d'OpenVPN

Afin de configurer OpenVPN, on va définir un mot de passe pour restreindre l'administration. Mettez ce bon mot de passe dans le fichier /etc/openvpn/private/mgmt.pwd. Modifier les permissions sur ce fichier pour en restreindre l'accès :

# chown root:wheel /etc/openvpn/private/mgmt.pwd
# chmod 600 /etc/openvpn/private/mgmt.pwd

Nous pouvons maintenant configurer openvpn en créant le fichier /etc/openvpn/server.conf. Afin qu'il soit pré-rempli, on va copier l'exemple fourni avec la commande :

# cp /usr/local/share/examples/openvpn/sample-config-files/server.conf /etc/openvpn/server.conf

Éditez maintenant ce fichier. Vous devrez au moins changer ces lignes :

# configuration reseau
dev tun0
server 10.8.0.0 255.255.255.0
push "redirect-gateway def1"
# On propose le resolveur de FDN
# https://www.fdn.fr/actions/dns/
push "dhcp-option DNS 80.67.169.12"
# Si le serveur a son propre resolveur
push "dhcp-option DNS 10.8.0.1"

# les certificats
ca /etc/openvpn/certs/ca.crt
cert /etc/openvpn/certs/server.crt
key /etc/openvpn/private/server.key
dh /etc/openvpn/dh.pem
crl-verify /etc/openvpn/crl.pem

# options diverses
comp-lzo
daemon openvpn
float
group _openvpn
user _openvpn
ifconfig-pool-persist /var/openvpn/ipp.txt
keepalive 10 120
management 127.0.0.1 1195 /etc/openvpn/private/mgmt.pwd
max-clients 100
persist-key
persist-tun
port 1194
proto udp

# authentification
client-cert-not-required
username-as-common-name
script-security 3 system
auth-user-pass-verify /usr/local/libexec/openvpn_bsdauth via-env
auth-nocache

# journaux
log-append  /var/log/openvpn/openvpn.log
status /var/log/openvpn/openvpn-status.log
verb 3

On modifie les permissions vers ce fichier :

# chown root:_openvpn /etc/openvpn/server.conf
# chmod 640 /etc/openvpn/server.conf

Ça sera tout pour la configuration du serveur.

6.8.4. Configuration réseau pour OpenVPN

Nous devons modifier la configuration du parefeu afin de rediriger le trafic provenant du VPN. Dans le fichier /etc/pf.conf, vous aurez alors cette ligne en plus :

pass out on $ext_if from 10.8.0.0/24 to any nat-to ($ext_if)

Il faut aussi autoriser le trafic à travers le tunnel VPN :

pass in quick on $tun_if keep state

N'oubliez pas au passage d'ouvrir et de rediriger le port 1194 en UDP.

On peut maintenant relancer le pare-feu avec pfctl -d && pfctl -ef /etc/pf.conf.

Il faut autoriser le transfert d'IP (ou "l'IP packet forwarding") en éditant le fichier /etc/sysctl.conf pour y mettre :

net.inet.ip.forwarding=1

Pour ne pas avoir à redémarrer le serveur, vous pouvez activer cette option avec la commande :

# sysctl net.inet.ip.forwarding=1

Si vous avez la chance de disposer d'une IPv6, n'oubliez pas l'équivalent :

# sysctl net.inet6.ip6.forwarding=1
# echo 'net.inet6.ip6.forwarding=1' >> /etc/sysctl.conf

6.8.5. Création des utilisateurs du VPN

C'est presque fini! Courage!

Seuls quelques utilisateurs auront le droit d'utiliser le VPN. Les élus autorisés seront ceux appartenant au groupe _openvpnusers. Pour créer ces utilisateurs en les mettant dans le bon groupe directement, utilisez la commande suivante :

# useradd -G _openvpnusers utilisateur

Profitez-en pour attribuer un mot de passe robuste pour ce dernier :

# passwd utilisateur

6.8.6. Démarrage du VPN

Afin de lancer le VPN automatiquement à chaque fois que le serveur démarre, une interface de type "tunnel" doit être créée. Tout ceci peut être réalisé automatiquement par OpenBSD en ajoutant un fichier /etc/hostname.tun0 pour mettre dedans :

up
!/usr/local/sbin/openvpn --config /etc/openvpn/server.conf

Afin de le lancer manuellement, tapez :

# sh /etc/netstart

Vous pouvez alors vérifier que openvpn est bien en cours de fonctionnement en regardant les journaux :

# tail -f /var/log/openvpn/*

Afin d'arrêter openvpn pour une raison ou une autre, vous pouvez tuer son processus avec la commande pkill -9 openvpn.

6.8.7. Configuration client

Il existe des outils graphiques permettant de faciliter la configuration d'une connexion avec openvpn. Libre à vous d'en installer un sur votre ordinateur ou smartphone.

Le plus souvent, vous devrez fournir le certificat du serveur afin que le client puisse se connecter. Envoyez-le par mail ou tout autre moyen. Il s'agit du fichier /etc/openvpn/certs/ca.crt. Vous pouvez afficher son contenu avec la commande cat :

# cat /etc/openvpn/certs/ca.crt

-----BEGIN CERTIFICATE-----

MIIGNTCCAh2gAwIBAgIJALxL5Rt5/p1TMA0GCSqGSIb3D
BAMMC3lldXhkZWxpYmFkMB4XDTE2MTAyMzA5MTk0NloXD
FjE9MBIGA1UEAwwLeWV1eGRlbGliYWQwggEiMA0GCSqGS
0NRT4WgYexgM6Dh+S/tMq8JciQMUEgMwLZZrFZn7mDBt1
…
…
jqudepBh87dbZUBSbmr9QuOV1sdPA6TUp+yn8Ytyfd0M2
nyPoapWcItouatMe42gzo0f3NPkHSIhi/dXv9BGNa1jxG
OTIdoOdFmQw3BlD+TCyYDMgKpWKaFi6t9Jyji7WJst68+
u2WyqiFXS/FrWqxoTs4WWGuAM/LPzMvhhNZ5eiP/l0aIR

-----END CERTIFICATE-----

Ensuite, reste à copier ce contenu dans un fichier pour l'envoyer au client.

Avec la configuration proposée ci-dessus, l'utilisateur devra se connecter avec les identifiants créés rien que pour lui.

Selon le logiciel vous permettant de vous connecter à votre VPN, la configuration générée ressemblera à ceci pour les clients :

client
dev tun0
proto udp
remote chezmoi.tld 1194
ca ca.crt
auth-user-pass
comp-lzo
auth-nocache

Remarquez qu'on retrouve les mêmes options que celles définies pour le serveur. Le fichier ca.crt correspond au certificat du serveur récupéré plus tôt, qu'il faudra enregistrer sur le client.

Une fois vos identifiants entrés, vos communications passent par votre VPN. Vous pouvez le vérifier en utilisant un service web qui vous donne votre adresse IP. Ce dernier doit afficher l'IP du serveur et non l'IP de votre ordinateur.

6.9. 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.

6.9.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 :

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.

6.9.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 pour afficher l'image.

Cliquez sur "Next", puis choisissez dans "Nouvelle destination" "IceCast". Cliquez sur "Ajouter".

Cliquez pour afficher l'image.

Remplissez ensuite les différents champs :

Vous pouvez activer le transcodage si vous le souhaitez. Audio Vorbis (OGG) fonctionne bien en général. Il vous reste à valider la suite.

6.9.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>

6.10. 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.

6.10.1. Captures régulières avec fswebcam

fswebcam est un 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.

6.10.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

6.10.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

6.11. OpenNTPD

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.

6.11.1. Installation

OpenNTPD développé par la team OpenBSD est déjà présent sur votre machine. Nous devons juste préciser à notre serveur de lancer OpenNTPD au démarrage. Pour cela, nous devons modifier notre fichier /etc/rc.conf.local en ajoutant cette ligne :

ntpd_flags="-s"

6.11.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

# Ecoute en local
listen on 127.0.0.1

## 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à 😁

7. Aller plus loin

7.1. 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 :

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.

7.2. Adresses réseau

7.2.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.

7.2.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.

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.

7.2.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.

7.2.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 documentation 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

7.2.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 connections à une machine qui n'est pas dans sa table DHCP).

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

7.2.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 grace à la (célèbre) commande ping.

Tout d'abord "pinger" votre passerelle :

ping 192.168.0.1

Puis "pinger" le serveur de Wikipedia :

ping 91.198.174.192

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

7.2.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.

Sachez qu'il existe un client dhcp pour ipv6, disponible dans les paquetages OpenBSD sous le nom wide-dhcpv6.

L'écoute des annonces des routeurs permet de connaître leur adresse, ce qui est, on vous le rapelle, 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: votre serveur est directement connecté à internet. Soyez donc prudent et vérifiez bien le pare-feu de votre serveur (PF).

7.3. Aller plus loin avec pf

7.3.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.

7.3.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.

7.3.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 $ext_if 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 connections 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 $ext_if 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)

7.3.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 faîtes 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/Thuban/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 actuellement 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

7.3.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/pfconf.

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.

7.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.

7.5. 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 /mnt/sauvegarde.

Éditez le fichier /etc/ssh/sshd_config puis ajoutez les lignes suivantes :

Subsystem       sftp    internal-sftp
Match Group sftpusers
    ChrootDirectory /mnt/sauvegarde/sftp/%u
    ForceCommand internal-sftp 

Pensez à bien modifier la ligne déjà existante qui contient Subsystem.

Ensuite, relancez SSH : rcctl reload sshd

Créez maintenant un dossier /sftp dans le dossier /mnt/sauvegarde pour que les utilisateurs y soient automatiquement placés à leur connexion.

# mkdir -p /mnt/sauvegarde/sftp

Modifiez les droits pour assurer une sécurité supplémentaire :

# chown root:wheel /mnt/sauvegarde/sftp
# chmod 700 /mnt/sauvegarde/sftp

Dans /mnt/sauvegarde/sftp, il y aura les dossiers portant le nom des utilisateurs. En fait, on fait comme si le répertoire

/mnt/sauvegarde/sftp/utilisateur

était la nouvelle racine / pour les utilisateurs.

Chaque utilisateur du groupe sftpusers sera placé dans ce dossier dès qu'il se connectera au serveur.

7.5.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 :

Voici la marche à suivre :

L'utilisateur peut maintenant utiliser le protocole SFTP. Il sera enfermé dans son dossier précédemment créé.

7.6. 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

8. Remarques complémentaires sur le système

8.1. Obtenir un certificat SSL

8.1.1. Obtenir un certificat avec letsencrypt

Le site lestencrypt.org fourni un client permettant d'obtenir un certificat qui sera automatiquement considéré comme "de confiance" par tous les navigateurs. C'est un service absolument génial tout à fait adapté à l'auto-hébergement.

De base est inclus dans OpenBSD l'outil acme-client qui vous permettra d'obtenir un certificat avec letsencrypt.

Attention : vérifiez bien que le port 80 est bien ouvert sur votre firewall (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 ira donc chercher un fichier dans .well-known/acme-challenge. Or, ils sont créés dans le dossier /var/www/acme puis supprimés juste après. Il faut donc rendre disponible ce dossier via http (le port 80 dans un premier temps). Ajoutez ces quelques lignes dans votre fichier httpd.conf comme indiqué dans le chapitre correspondant.

server "chezmoi.tld" {
    root "/empty"
    listen on * port 80
    location "/.well-known/acme-challenge/*" {
        root { "/acme/" , strip 2 }
    }
}

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.

Avant d'utiliser cet outil, 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 key "/etc/ssl/acme/private/chezmoi.tld-privkey.pem"
    domain certificate "/etc/ssl/acme/chezmoi.tld-cert.pem"
    domain chain certificate "/etc/ssl/acme/chezmoi.tld-chain.pem"
    domain full chain certificate "/etc/ssl/acme/chezmoi.tld-fullchain.pem"
    sign with letsencrypt
}

Remplacez les éléments suivants :

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 :

server "chezmoi.tld" {
    listen on * tls port 443
    root "/htdocs/monsite" # à modifier
    hsts
    tls {
        certificate "/etc/ssl/acme/chezmoi.tld-fullchain.pem"
        key "/etc/ssl/acme/private/chezmoi.tld-privkey.pem"
    }
    
    # n'oubliez pas d'ajouter la configuration
    # specifique liee à votre site
    
    location "/.well-known/acme-challenge/*" {
        root { "/acme/" , strip 2 }
    }
}

8.1.2. 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 :

Cliquez pour afficher l'image.

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.pem à votre convenance :

# openssl req -x509 -sha512 -nodes -days 365 -newkey rsa:4096 \
	-keyout /etc/ssl//certificat.pem \
	-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.pem
# 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).

8.1.3. 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.

Cliquez pour afficher l'image.

8.2. Notes et astuces diverses

Ces informations sont à lire dans le désordre selon vos besoins.

8.2.1. Comment on devient "root" ou "superutilisateur" ?

Entrez la commande su puis le mot de passe de l'utilisateur root.

8.2.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.

8.2.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 :

8.2.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.

8.2.5. Comment créer un utilisateur ?

Créer des utilisateurs peut vous servir à plusieurs choses, notamment :

Selon les cas, vous ne configurerez pas l'utilisateur de la même façon. En résumé :

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…).

8.2.5.1. Utilisateur pour compte mail

Par défaut, chaque utilisateur peut recevoir des mails. Son adresse est nom-d-utilisateur@chezmoi.tld.

Voici à quoi ressemblera la création d'un utilisateur pour un compte mail, qui n'a pas le droit de lancer d'autres 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é.

8.2.5.2. Supprimer un utilisateur

Pour supprimer un utilisateur, c'est très rapide :

# userdel toto
# groupdel toto

Et voilà!

8.2.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>

8.2.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

8.2.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 :

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ù :

Vous prendrez bien quelques exemples?

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.

8.2.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).

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 :

Ç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 :

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 :

$ dd if=/dev/urandom count=128 bs=1M 2>&1 | md5 | cut -b-15

8.2.8. 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 :

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

8.2.9. 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_3 -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_3 -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
    # 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.

8.2.10. É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

8.2.11. 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 :

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.

8.2.12. 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

8.2.13. 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.

Bien sûr, davantage d'explications sont disponibles dans la page man.

8.2.14. 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 :

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 :

On peut préciser ensuite si besoin :

Pour d'autres informations, regardez la page man de newsyslog et newsyslog.conf.

$ man newsyslog.conf

9. Annexes

9.1. Liens

Pour compléter la lecture de ce manuel, je vous conseille les liens suivants :

9.2. FAQ : Foire aux questions

9.2.1. Comment modifier un fichier?

Il existe une ribambelle d’éditeurs de texte (vim, nano…). L'éditeur par défaut sur OpenBSD est vi. Il peut être étonnant à utiliser au premier abord, vous voudrez peut-être installer à la place nano.

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 :

Cliquez pour afficher l'image.

Pour pouvoir écrire et modifier le fichier, appuyez sur la touche i.

Vous voilà en mode édition, vous pouvez écrire tout ce que vous voulez. Afin de quitter le mode édition, appuyez sur la touche échap.

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!.

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é.

Cela devrait être suffisant dans un premier temps. Si le fonctionnement de vi vous intéresse, vous pouvez consulter cette documentation.

9.2.2. 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é.

9.2.3. 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.

9.2.4. 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.

9.2.5. 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.

9.2.6. 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.

9.2.7. 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.

9.2.8. 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?

9.2.9. 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.

9.2.10. 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.

9.2.11. Que faire contre les coupures de courant ?

Plusieurs astuces sont possibles :

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.

9.3. Merci!

Ce document ne s'est pas fait tout seul. Au risque d'en oublier, je tiens à remercier le collectif 3hg où j'ai trouvé des amis passionnés avec lesquels échanger.

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 spécial à Fred Galusik, PengouinPdt et kuniyoshi qui m'ont accompagné et m'accompagnent encore dans l'aventure d' obsd4*.

Merci à Bastien Traverse, PengouinPdt 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.

9.4. Exemples et fichiers

9.4.1. /etc/pf.conf

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

## Configuration generale ##
ext_if = "re0"                         # interface
tun_if = "tun0"                        # vpn
ssh_port = "222"                       # port ssh
http_ports = "{ www https }"           # ports http(s)
mail_ports = "{ submission imaps }"    # ports mails 
tcp_pass = "{ gopher domain 22000 }"   # ports tcp ouverts
udp_pass = "{ domain 21027 }"          # ports udp ouverts
set block-policy drop                  # bloque silencieusement
set skip on lo                         # Pas de filtre en local
set limit table-entries 400000         # Grande taille de tables

## tables pour les vilains bruteforceurs
table <bruteforce> persist
table <vilain_bruteforce> persist

# antispam avec greylisting
table <spamd-white> persist
table <nospamd> persist file "/etc/mail/nospamd"
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"


## Traitement des paquets ##
# Paquets partiels
match in all scrub (max-mss 1440 no-df random-id reassemble tcp)
antispoof quick for $ext_if          	# Protection vol d'ip
antispoof quick for lo0                 # Protection vol d'ip
#block in quick from urpf-failed        # idem

## Les règles du [parefeu #pf] ##
# on bloque tout par defaut
block log all

# on bloque les ip blacklistees
block log quick from <bruteforce> 
block log quick from <vilain_bruteforce> 

# blocage des blockzones
block quick from { <t_badips>, <t_badips6> }

## antispam
pass in on $ext_if proto tcp from any to port smtp \
	divert-to localhost port spamd
pass in on $ext_if proto tcp from <nospamd> to port smtp
pass in on $ext_if proto tcp from <spamd-white> to port smtp
pass in quick on $ext_if proto tcp from <bgp-spamd-bypass> to port smtp

## Anti bruteforce
# Si + de 3 connections toutes les 60 secondes sur le port ssh
# on rajoute l'ip pour la bloquer.
pass in on $ext_if proto tcp to port $ssh_port flags S/SA modulate state \
	(max-src-conn-rate 5/60, overload <bruteforce> flush global)

# Protection bruteforce pour les mails
pass in on $ext_if proto tcp to port $mail_ports flags S/SA modulate state \
	(max-src-conn-rate 6/60, overload <bruteforce> flush global)

# 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 $ext_if proto tcp to port $http_ports flags S/SA modulate state
pass in quick on $ext_if proto tcp to port $tcp_pass flags S/SA modulate state
pass in quick on $ext_if proto udp to port $udp_pass 

# vpn
pass quick on $tun_if modulate state
pass out quick on $ext_if from 10.8.0.0/24 nat-to ($ext_if:0) modulate state

# tout ouvert en sortie
pass out on $ext_if proto { tcp udp icmp ipv6-icmp } modulate state

9.4.2. /etc/httpd.conf

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

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

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 
    tls {
        certificate "/etc/ssl/acme/chezmoi.tld-fullchain.pem"
        key "/etc/ssl/acme/private/chezmoi.tld-privkey.pem"
    }

    location "/Blog/" {
        directory index index.php
    }

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

    location "/DL/PDF/" {
        directory auto index
    }

    location "/educ/" {
        authenticate "education" with "/htdocs/educ.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/acme/chezmoi.tld-fullchain.pem"
        key "/etc/ssl/acme/private/chezmoi.tld-privkey.pem"
    }

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

server "autresite.chezmoi.tld" { 
    listen on * port 80 
    root "/htdocs/autresite" 
    directory index index.html
    log access "mateteestmalade.log"
} 

server "deb.chezmoi.tld" { 
    listen on * port 80 
    root "/htdocs/deb" 
    directory auto index 
    no log
} 

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 "/roundcubemail" 
    directory index index.php
    no log

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

    location "*.php*" {
        fastcgi socket "/run/php-fpm.sock"
    }
    # Deny Protected directories
    location "/config" { 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 }

} 

server "wiki.chezmoi.tld" { 
    listen on * port 80 
    listen on * tls port 443 
    root "/htdocs/dokuwiki" 
    directory index doku.php
    no log

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

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

    location "/data*"      { block }
    location "/conf*"      { block }
    location "/bin*"      { block }
    location "/inc*"      { block }
} 

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

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

    # Set max upload size to 513M (in bytes)
    connection max request body 537919488

    # First deny access to the specified files
    location "/db_structure.xml" { block }
    location "/.ht*"         { block }
    location "/README"       { block }
    location "*/data*"        { block }
    location "*/config*"      { block }

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

9.4.3. /etc/mail/smtpd.conf

table aliases file:/etc/mail/aliases

pki chezmoi.tld key "/etc/ssl/acme/private/chezmoi.tld-privkey.pem"
pki chezmoi.tld certificate "/etc/ssl/acme/chezmoi.tld-fullchain.pem"
ca chezmoi.tld certificate "/etc/ssl/acme/chezmoi.tld-fullchain.pem"

## RECEPTION ##
# Messages avec signature DKIM
listen on lo0 port 10028 tag DKIM   
# Messages verifies par spamassassin
listen on lo0 port 10026 tag NOSPAM
# Messages locaux
listen on lo0

## ENVOI ##
# Pour utiliser un client mail
listen on re0 port smtp hostname chezmoi.tld tls pki chezmoi.tld
listen on re0 port submission hostname chezmoi.tld tls-require pki chezmoi.tld auth

## RECEPTION ##
# Message venant du système
accept from local for local alias <aliases> deliver to maildir "~/Maildir"
# Message NOSPAM
accept tagged NOSPAM for domain "chezmoi.tld" deliver to maildir "~/Maildir"
# Message venant d'ailleurs, on scanne avec spamassassin
accept from any for domain "chezmoi.tld" relay via smtp://127.0.0.1:10025

## ENVOI ##
# Mail sortant portant une signature DKIM
accept tagged DKIM for any relay

# Mail en envoi pas encore signe avec DKIM
accept from local for any relay via smtp://127.0.0.1:10027

9.4.4. /etc/mail/smtpd.conf utilisateurs virtuels

table aliases file:/etc/mail/aliases
table domains file:/etc/mail/domains # one line, on domain
table passwd passwd:/etc/mail/passwd
table virtuals file:/etc/mail/virtuals

pki chezmoi.tld key "/etc/ssl/acme/private/chezmoi.tld-privkey.pem"
pki chezmoi.tld certificate "/etc/ssl/acme/chezmoi.tld-fullchain.pem"
ca chezmoi.tld certificate "/etc/ssl/acme/chezmoi.tld-fullchain.pem"

## Quelques options ##
expire 7d
queue compression
queue encryption key 7d3b5db2353beb64caf8d9e25288c1e8

## ECOUTE ##
# Messages avec signature DKIM
listen on lo0 port 10028 tag DKIM
# Messages verifies par spamassassin
listen on lo0 port 10026 tag NOSPAM
# Messages locaux
listen on lo0


## RECEPTION DE MESSAGES ##
listen on re0 port smtp tls pki certsssl tag INCOMING
## ENVOI DE MESSAGES ##
listen on re0 port submission tls-require pki certsssl auth <passwd> tag OUTGOING


## RECEPTION ##
# Message venant du système
accept from local for local alias <aliases> deliver to maildir "~/Maildir"

# Message NOSPAM
accept tagged NOSPAM from any for domain <domains> virtual <virtuals> \
     deliver to maildir "/var/vmail/%{rcpt.domain}/%{rcpt.user}/Maildir"
accept from any for domain <domains> relay via smtp://127.0.0.1:10025

## ENVOI ##

# Mail sortant portant une signature DKIM, multi domaine
accept tagged DKIM sender {"@yeuxdelibad.net"} for any relay hostname "yeuxdelibad.net"
accept tagged DKIM sender {"@3hg.fr"} for any relay hostname "3hg.fr"
accept tagged DKIM sender {"@ouaf.xyz"} for any relay hostname "ouaf.xyz"
accept tagged DKIM for any relay

# Mail en envoi pas encore signe avec DKIM
accept from local for any relay via smtp://127.0.0.1:10027

###
# Relay
accept from any for domain domainebackup.eu relay backup


===/etc/relayd.conf===[relaydconf]
%!include: relayd.conf.t2t

===/etc/monitrc===[monitrc]
%!include: monitrc.t2t

===/var/nsd/etc/nsd.conf===[nsdconf]
%!include: nsd.conf.t2t

===/etc/mail/spamd.conf===[spamdconf]
%!include: spamd.conf.t2t

%%===/etc/webalizer.conf===[webalizerconf]
%%%!include: webalizer.conf.t2t


%LATEXEND

%!include: htmlinclude.t2t