cd / ;
apropos ;
find * ;
Une fois votre serveur en route, il faudra veiller à ce que tout fonctionne correctement. Ça paraît bête, mais c'est très important. Inutile d'aller plus loin si vous comptiez laisser votre serveur dépérir 😉. Heureusement, tout est déjà prévu dans OpenBSD pour nous faciliter la vie.
Chaque jour (enfin plutôt chaque nuit 😄) un rapport est généré à l'aide d'un outil nommé "security". Il est envoyé à l'administrateur du serveur, cet utilisateur répondant au charmant nom de "Charlie Root". Vous pourrez y lire un tas d'informations utiles comme :
Lisez la page "man security" pour en apprendre davantage.
Au bout du compte, un rapport peut ressembler à ceci :
Running security(8): Checking mailbox ownership. user spamd.black mailbox is owned by root user spamd.black mailbox is -rw-r--r--, group wheel ====== /etc/rc.local diffs (-OLD +NEW) ====== --- /var/backups/etc_rc.local.current Sat Jun 4 03:46:48 2016 +++ /etc/rc.local Thu Oct 20 09:46:54 2016 @@ -1 +1 @@ -su pi -c "tmux new -s rtorrent -d rtorrent" +/usr/bin/su pi -c "/usr/bin/tmux new -s rtorrent -d /usr/local/bin/rtorrent" ====== /etc/spwd.db SHA-256 checksums ====== OLD: 075455a721ef[...]b942f590fb8e3edfd88c5dd4 NEW: 37eba7537dd7[...]42468cc4cbe768fcf496b230
On y voit des alertes sur les propriétaires de certains fichiers.
Ensuite, les modifications sur un fichier. Les lignes commençant par un + correspondent à ce qui a été rajouté et celles qui commencent par un - à ce qu'il y avait avant.
Enfin, on voit qu'une somme de contrôle a changé : un nouvel utilisateur a-t-il été créé par vos soins ? Espérons que oui puisque le fichier /etc/spwd.db a changé. Normalement, ce rapport est très peu rempli, c'était un exemple 😉.
Tout ceci, c'est bien beau, mais comment recevoir ces messages?
Comme vous allez le voir, c'est d'une simplicité enfantine :
root : toto@chezmoi.tld
Bien sûr, vous remplacerez l'adresse mail par celle que vous consultez régulièrement.
Entrez maintenant :
# newaliases.
Et voilà ! 😎
Si vous voulez tester que tout fonctionne comme prévu, saisissez la commande suivante pour envoyer un mail test à root, c'est-à-dire à vous-même :
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.
Éditez ce fichier, et écrivez, 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@chezmoi.tld.
Je vous suggère d'ajouter la ligne suivante dans le fichier /etc/daily.local :
CHECKFILESYSTEMS=1
De cette façon, une recherche d'erreurs sera effectuée tous les jours sur les systèmes de fichiers.
Lisez aussi le man 8 daily pour en apprendre plus 😉.
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 ! Comme toujours on va simplifier au maximum puis proposer des exemples plus complexes (pas "compliqués" 😉) pour ceux qui veulent aller plus loin.
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, finalement facile à appréhender.
Avant toutes choses, il faut se demander ce dont on va avoir besoin sur notre serveur. Un serveur web ? 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. Cela signifie qu'une nouvelle règle, si elle correspond au paquet en question, peut écraser les précédentes ⚠. Si ce n'est pas ce que vous souhaitez, vous pourrez utiliser une règle match au lieu de block ou pass, de cette façon l'état de la règle reste inchangé. Sinon, vous pouvez utiliser le mot clé quick ce qui retient pf de lire plus loin et appliquer directement la règle. Rassurez-vous, c'est en fait assez facile, vous le constaterez avec le premier exemple 😉.
Pour approfondir les notions décrites ensuite, je vous conseille la lecture du guide pf officiel.
https://www.openbsd.org/faq/pf/index.html
Prêts ? C'est parti pour un exemple détaillé mais simple. Nous allons configurer le pare-feu 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 à gérer.
tcp_pass = "{ 80 443 }"
Remarquez que c'est identique à :
tcp_pass = "{ www https }"
Ensuite, on autorise les visiteurs éventuels à accéder à votre serveur. Ce seront des connexions dites "entrantes", on utilisera donc le mot clé "in".
Au lieu de chercher le nom de votre interface réseau (qui dépend de votre matériel), nous allons préciser le nom du groupe que portent ces interfaces afin que ça fonctionne sans inquiétudes : "egress".
pass in on egress proto tcp to port $tcp_pass
T'es mignon hein, mais c'est du charabia tout ça !
D'accord, nous allons expliquer ce que veut dire cette syntaxe. On peut la traduire la ligne de configuration précédente ainsi : "laisse passer vers l'intérieur (pass in) à travers les interfaces egress (on egress) pour le protocole tcp (proto tcp) vers les ports contenus dans la variable tcp_pass (to port $tcp_pass)".
Pfouh ! 😋
Je vous suggère de permettre à votre serveur de répondre au ping.
Il s'agit du protocole icmp:
pass in proto icmp
Enfin, on autorise tout le trafic en sortie (mot clé "out") :
pass out
Cela nous donne au final :
tcp_pass = "{ 80 443 }"
block log
pass in proto icmp
pass in on egress proto tcp to port $tcp_pass
pass out
Facile, non ? 😁
Vous l'aurez compris, pf nous permet un contrôle de premier ordre sur notre serveur. Dans un premier temps, vous souhaiterez simplement choisir quels ports doivent être ouverts.
Cela fait de nombreuses nouvelles notions, prenez le temps de relire ce qui a été écrit jusqu'ici si besoin.
Lorsque vous serez plus à l'aise, sachez qu'on pourra filtrer le trafic entrant et sortant, et même rediriger une partie de celui-ci vers des services internes (par exemple un anti-spam).
Les parties suivantes décrivent et approfondissent les possibilités offertes par 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.
Je vous laisse construire votre fichier /etc/pf.conf selon vos besoins. Partez de l'exemple vu ci-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 toujours le 22 (par défaut), alors vous aurez dans la configuration de pf :
pass in on egress proto tcp to port 22
Bien sûr, vous pouvez aussi vous contenter de modifier uniquement la variable tcp_pass :
tcp_pass = "{80 443 22}"
pass in...
Je vous propose le modèle suivant, à éditer et décommenter selon vos besoins:
ifaces = "{ egress }"
# maybe useful later
#tcp_pass = "{ www https }" # change me
#udp_pass = "{ domain }" # change me
table <bruteforce> persist
set skip on { lo }
antispoof for $ifaces
block
block quick from <bruteforce> label "BRUTES"
# allow ping
pass on $ifaces inet6 proto ipv6-icmp all #icmp6-type echoreq
pass on $ifaces inet proto icmp all # icmp-type echoreq
pass in on $ifaces proto tcp to port ssh modulate state \
(source-track rule, \
max-src-conn 8, max-src-conn-rate 15/5, \
overload <bruteforce> flush global)
#pass in on $ifaces proto tcp to port $tcp_pass modulate state
#pass in on $ifaces proto udp to port $udp_pass
pass out on $ifaces proto { tcp udp }
Je vous propose une liste de commandes utiles pour gérer pf :
Certaines IP sont connues pour être nuisibles. Entre celles qui scannent pour trouver un port ouvert ou celles qui tentent des attaques par bruteforce, la liste est longue. Heureusement, on peut configurer le pare-feu pour qu'il ignore totalement ces IP et ainsi protéger et alléger la charge de notre serveur.
C'est ce que permet le projet pf-badhost dont je vous invite à lire la page officielle.
https://www.geoghegan.ca/pfbadhost.html
Ci-dessous, je vous propose une traduction pour mettre ce dispositif en place.
Il consiste en un script qui récupère une liste d'IP qui seront ensuite ignorées par pf.
On commence par créer un utilisateur dédié à ce script. On l'appelle "_pfbadhost". Cela permet de séparer les privilèges, ce qui est bienvenu, même si les étapes intermédiaires pourraient être évitées si on faisait tout en tant que superutilisateur (mais non 😋) :
# useradd -s /sbin/nologin -d /var/empty _pfbadhost
On télécharge et installe le script pfbadhost avec les bonnes permissions :
# ftp https://www.geoghegan.ca/scripts/pf-badhost.sh # install -m 755 -o root -g bin pf-badhost.sh /usr/local/bin/pf-badhost
On doit ensuite créer les fichiers nécessaires au bon fonctionnement du script (liste des IP et logs):
# install -m 640 -o _pfbadhost -g wheel /dev/null /etc/pf-badhost.txt # install -d -m 755 -o root -g wheel /var/log/pf-badhost # install -m 640 -o _pfbadhost -g wheel /dev/null /var/log/pf-badhost/pf-badhost.log # install -m 640 -o _pfbadhost -g wheel /dev/null /var/log/pf-badhost/pf-badhost.log.0.gz
L'auteur conseille d'installer les programmes ripgrep et mawk pour de meilleures performances. C'est facultatif:
# pkg_add ripgrep mawk
Ajoutez ces lignes dans le fichier /etc/doas.conf afin que l'utilisateur _pfbadhost puisse recharger la liste des IP à blacklister dans le pare-feu :
permit root permit nopass _pfbadhost cmd /sbin/pfctl args -nf /etc/pf.conf permit nopass _pfbadhost cmd /sbin/pfctl args -t pfbadhost -T replace -f /etc/pf-badhost.txt # Optional rule for authlog scanning permit nopass _pfbadhost cmd /usr/bin/zcat args -f /var/log/authlog /var/log/authlog.0.gz
Faites en sorte que l'utilisateur _pfbadhost lance le script à intervalles réguliers avec crontab.
# crontab -u _pfbadhost -e ~ 0~1 * * * -s pf-badhost -O openbsd
(La ligne est à écrire avec l'éditeur vi décrit dans la partie "Guide de survie : quelles commandes dois-je absolument connaître?")
Ainsi, pf-badhost sera lancé chaque nuit entre minuit et 1h du matin. Cela permet d'éviter que tous les utilisateurs de pf-badhost n'utilisent ce script en même temps et ainsi, d'éviter de surcharger les serveurs.
Ajoutez ces lignes au fichier /etc/pf.conf pour que pf tienne compte de la liste noire :
table <pfbadhost> persist file "/etc/pf-badhost.txt" block quick on egress from <pfbadhost>
Le mot clé "quick" permet de ne pas lire les règles qui suivent : on bloque et puis c'est tout.
Lancez le script pour la première fois comme si vous étiez l'utilisateur _pfbadhost :
# doas -u _pfbadhost pf-badhost -O openbsd
Notez que vous devez pouvoir utiliser doas. Enfin, rechargez le pare-feu puis relancez le script :
# pfctl -f /etc/pf.conf doas -u _pfbadhost pf-badhost -O openbsd
Et voilà !
Pour configurer pf-badhost, vous devez éditer directement le script et chercher ce qui est en-dessous de la ligne :
# User Configuration Area -- START
Vous pourrez notamment décommenter (retirer le "#") pour une liste spécifique ou activer l'IPv6.
Lisez le manuel de pf-badhost bien sûr 😉.
https://www.geoghegan.ca/pub/pf-badhost/0.5/man/man.txt
Je mets à disposition des listes d'IP à blacklister sur votre serveur.
Servez-vous 😉.
Une méthode qu'utilisent les pirates pour s'en prendre à un serveur s'appelle "bruteforce". Ce type d'attaque consiste à 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êtes, 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 pare-feu les IP des "attaquants". Ça tombe bien, vous pouvez utiliser nono ou sshguard dont on parle un peu plus loin.
nono:
sshguard:
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. Lisez le paragraphe suivant 😉.
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 :
Ça nous donne donc ceci :
table <ssh_abuse> persist
block in log quick proto tcp from <ssh_abuse> to any port ssh
pass in on egress proto tcp to any port $ssh_port modulate state \
(source-track rule, \
max-src-conn-rate 3/60, \
overload <ssh_abuse> flush global)
Encore une fois, on utilise quick pour bloquer sans chercher plus loin, on ne prend pas le risque d'écraser cette règle.
Voici un autre exemple pour un site web (ports http et https) :
http_ports = "{ www https }"
# Si + de 40 connexions toutes les 5 secondes sur les ports http(s)
# ou si essai de se connecter + de 100 fois
# on ajoute l'ip pour la bloquer.
pass in on egress proto tcp to any port $http_ports modulate state \
(source-track rule, \
max-src-conn 100, max-src-conn-rate 40/5,\
overload <http_abuse> flush global)
Je me permets de vous proposer un outil que j'ai écrit dans le but de mettre sur liste noire d'éventuelles IP lorsque leur comportement ressemble fort à celui d'une tentative d'intrusion. Il ne nécessite rien de plus que ce qui est déjà présent de base dans OpenBSD.
Vos retours d'utilisation permettront de l'améliorer.
Le script en question s'appelle nono, et est détaillé à la page:
nono : say "no no" to intruders.
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. 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 qui sont aussitôt bloquées :
table <sshguard> persist block in from <sshguard>
Rechargez le pare-feu avec "# pfctl -f /etc/pf.conf".
Maintenant, on installe sshguard comme on a l'habitude de le faire :
# pkg_add sshguard
Copiez le fichier de configuration donné en exemple :
# cp /usr/local/share/examples/sshguard/sshguard.conf.sample /etc/sshguard.conf
Éditez ce fichier si vous le souhaitez pour le rendre plus ou moins sévère. Les options par défaut sont plutôt raisonnables.
Nous pouvons maintenant activer et lancer sshguard :
# rcctl enable sshguard # rcctl start sshguard
Et voilà, votre serveur est désormais sous bonne garde.
Vous voudrez peut-être mettre sur liste blanche quelques adresses IP. Il vous suffit pour cela de remplir le fichier /etc/sshguard.friends, une IP par ligne (ou rangées d'IP) :
46.23.93.119 192.168.1.0/24 10.0.0.1
iblock vous permet de bannir des IP qui tenteraient de joindre votre serveur sur des ports inutilisés. Puisque vous n'avez aucun service derrière ces ports, il y a fort à parier que ce sont des scans aux intentions discutables. Je recommande vivement l'utilisation de cet outil.
https://tildegit.org/solene/iblock
SSH, est un outil génial 🙋. Il 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, la plupart des serveurs sont administrés ainsi, mais vous êtes chez vous après tout, donc vous pouvez faire comme vous voulez.
De plus, SSH est un protocole permettant bien plus : créer des tunnels chiffrés vers votre serveur, avoir un espace de stockage de fichiers en SFTP...
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, il faut le garder ainsi et éventuellement éditer la configuration de SSH dans le fichier /etc/ssh/sshd_config.
PermitRootLogin no
Pour vous connecter à la machine, il faudra créer un utilisateur simple avec la commande adduser.
Une fois les modifications réalisées, relancez le démon SSH :
# rcctl reload sshd
Par la suite, pour vous connecter au serveur, vous utiliserez la commande suivante à partir de votre ordinateur (dans un terminal, ou avec un client comme putty sous windows) :
$ ssh toto@chezmoi.tld
Et si vous avez changé le port par défaut :
$ ssh -p 222 toto@chezmoi.tld
Ça demandera le mot de passe de l'utilisateur toto, puis vous pourrez administrer le serveur à distance.
Il est tout à fait possible de se connecter en SSH sans utiliser de mot de passe. À la place, on se sert de paire de clés. C'est une bonne idée au moins pour les raisons suivantes :
Toutefois, cela vous impose d'avoir la clé privée sur la machine servant à se connecter, ce qui n'est pas toujours le cas.
Voici la marche à suivre :
Sur le serveur, modifiez le fichier /etc/ssh/sshd_config pour qu'il contienne cette ligne :
PubkeyAuthentication yes
Maintenant, sur l'ordinateur qui veut accéder au serveur, nous allons générer la paire de clés avec la commande suivante :
ssh-keygen -t ed25519 -f ~/.ssh/clessh -a 100
Vous trouverez deux nouveaux fichiers :
L'algorithme ed25519 est utilisé, car très fiable à l'heure actuelle.
Ne mettez pas de mot de passe puis patientez le temps que les clés soient générées.
Sur un système OpenBSD ou Linux, vous prendrez soin d'éditer le fichier ~/.ssh/config de votre utilisateur pour le remplir ainsi :
Host votreserveur HostName nomtreslong.vraimenttroplong.long User jeanbaptiste.professeurdanseur Port 222 PasswordAuthentication no IdentityFile ~/.ssh/clessh
Bien sûr, vous modifierez le nom de domaine de votre serveur ainsi que le nom de l'utilisateur qui doit se connecter. Ensuite, lancez la commande suivante pour copier la clé publique sur le serveur.
ssh-copy-id -p xxx -i ~/.ssh/clessh.pub "jeanbaptiste.professeurdanseur@nomtreslong.vraimenttroplong.long"
Ici, remplacez "xxx" par le port utilisé par SSH.
Dans le cas où l'outil ssh-copy-id ne serait pas disponible, il faut copier la clé publique manuellement. Pour l'afficher, entrez :
$ cat ~/.ssh/clessh.pub
Connectez-vous sur le serveur en SSH, puis ajoutez dans le fichier ~/.ssh/authorized_keys le contenu du fichier affiché précédemment.
Une fois ceci fait, vous pouvez vous connecter sans devoir entrer de mot de passe avec simplement la commande :
$ ssh votreserveur
Pratique non ?
Si ça fonctionne comme prévu, vous pouvez si vous le souhaitez désactiver l'identification par mot de passe pour de bon afin de ne garder que le jeu de clés comme possibilités. Modifiez le fichier /etc/ssh/sshd_config pour qu'il contienne cette ligne :
PasswordAuthentication no
⚠ ATTENTION à ne pas perdre votre jeu de clés !
Vous aurez certainement besoin d'envoyer des fichiers sur votre serveur de temps en temps. Une fois que SSH est configuré, vous pourrez utiliser la commande scp depuis n'importe quel ordinateur afin de copier un fichier vers votre serveur. Par exemple :
$ scp -P <port ssh> utilisateur@chezmoi.tld:/emplacement/de/destination fichier-a-copier
C'est très pratique.
Si vous souhaitez toutefois transférer de nombreux fichiers, sauvegarder ou stocker des documents, tournez-vous plutôt vers le protocole SFTP, disposant de davantage de fonctionnalités comme la reprise d'un transfert interrompu.
Si les fichiers sont trop gros, vous pouvez les découper pour réaliser les transferts en plusieurs fois.
Pour en apprendre plus sur la sécurisation et l'utilisation de SSH, vous pouvez lire la page man, ou encore le site officiel.
Lors de la première connexion à votre serveur via SSH, un client va récupérer l'empreinte de votre serveur. Cependant, comment être sûr qu'il s'agit bien de la bonne? Au lieu d'accepter la première fois puis vérifier ensuite si l'empreinte a changé (dans ce cas, il y a certainement un problème), vous pouvez publier dans votre zone DNS les informations permettant de vérifier que tout va bien.
Pour cela, depuis votre serveur, entrez la commande "ssh-keygen -r chezmoi.tld" puis copiez le résultat dans votre zone (sans oublier d'adapter au besoin en ajoutant un "." final après votre domaine ou en le modifiant pour un "@").
Par exemple :
@ IN SSHFP 1 1 97f5a9479fd16fbee1381c425297f7b2773a67a4 @ IN SSHFP 1 2 bd50a3c271e83dc769ea7c249a5c07aea1a817c62910129de56eba2763f93607 @ IN SSHFP 2 1 05fb8516842fc270ea5abda38d1c32b41e75da8a @ IN SSHFP 2 2 491489437e137d7d27959a4de3ba7660185ef98cbd3abc2287c82f82e8f032ab @ IN SSHFP 3 1 b7305417b0e981c4513642020a1f57ee03915af5 @ IN SSHFP 3 2 f15d33852df5f4043c77b6bf1c6134a5e11de0a513c1ec127fcbb8fae733b178 @ IN SSHFP 4 1 a1120fe90e69c0f534fece3dc837db6a262c3371 @ IN SSHFP 4 2 a36e418b517d95a74f1e0be1228d46e7aeaa8ed310359e91162d8c40b373eb55
Rassurez-vous, on parle des zones DNS un peu plus loin 😉.
Afin que ces enregistrements soient comparés à l'empreinte du serveur, les utilisateurs devront avoir activé l'option "VerifyHostKeyDNS" lorsqu'ils utiliseront ssh. Cela peut s'activer en ajoutant dans leur fichier ~/.ssh/config :
Host *
VerifyHostKeyDNS yes
Pour en savoir plus, Solène Rapenne a écrit à ce sujet :
https://dataswamp.org/~solene/2023-08-05-sshfp-dns-entries.html
Pour conserver un système sécurisé, il est essentiel de le maintenir à jour. Afin d'appliquer les correctifs de sécurité, vous devrez maintenir :
Pour les pressés 😉 :
# syspatch # pkg_add -u
Mettre les paquets à jour est l'histoire d'une seule commande :
# pkg_add -u
Oui, c'est tout. 😁
Merci à solene qui a rendu cela possible.
https://marc.info/?l=openbsd-announce&m=156577865917831&w=2
Puisque ce paragraphe est un peu court, j'en profite pour vous donner deux astuces 😊. Je vous conseille d'ajouter au fichier /etc/daily.local la commande :
pkg_add -nu
De cette façon, dans le mail journalier envoyé par Charlie Root, vous verrez ce qu'il pourrait se passer si des paquets pouvant être mis à jours sont disponibles. En réalité, rien n'est fait, car si un programme mis à jour doit être redémarré, il risque de ne pas fonctionner le temps que vous le relanciez.
Ainsi, vous êtes avertis d'éventuelles mises à jour à appliquer, et avec l'option -n, les paquets sont gardés dans le cache afin de gagner du temps sans risquer de mettre un service en panne s'il doit être redémarré suite à la mise à jour. Vous entrerez à la main "# pkg_add -u" lorsque vous en aurez l'occasion.
Si vous souhaitez tout de même appliquer les mises à jour automatiquement, je vous conseille d'installer avant tout le port checkrestart qui vous indiquera si un service doit être relancé suite à la mise à jour. Cela donnera donc dans /etc/daily.local :
pkg_add -u echo "Service à relancer avec rcctl restart:" checkrestart
Il faudra tout de même recharger les services à la main avec rcctl.
Tout d'abord, un petit rappel : OpenBSD est disponible 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 (c'était il y a déjà longtemps) :
Get/Verify syspatch61-002_vmmfpu.tgz 100% |*******************************| 9377 KB 00:49 Installing patch 002_vmmfpu Get/Verify syspatch61-003_libress... 100% |*******************************| 11391 KB 00:22 Installing patch 003_libressl ...
Cet outil n'est disponible que pour les architectures i386, amd64, et plus récemment arm64. Vous souhaiterez alors peut-être utiliser l'ancienne méthode de récupération des sources et installation manuelle.
Tout ceci est décrit dans la FAQ officielle.
https://www.openbsd.org/stable.html
Pour savoir si des mises à jour doivent être appliquées, vous pouvez consulter la page errata qui contient la liste des patchs de sécurité disponibles. Il s'agit de "https://www.openbsd.org/errataXX.html", en remplaçant "XX" par le numéro de version OpenBSD : 70 pour la version "7.0" par exemple.
Vous pouvez aussi être averti par mail (et ça c'est top 😊). Pour recevoir les messages importants de mises à jour disponibles sur le système, inscrivez-vous aux listes announce et security-announce. Pour ça, on envoie un premier mail à majordomo@OpenBSD.org contenant simplement :
subscribe announce
Puis envoyez un second message avec :
subscribe security-announce
Je vous conseille aussi de vous inscrire à la liste indiquant qu'il existe une nouvelle version des ports en vous inscrivant à la liste ports-security en envoyant toujours à la même adresse un message contenant :
subscribe ports-security
Lorsqu'une nouvelle version majeure d'OpenBSD est disponible, la procédure de mise à jour est toujours détaillée sur le site officiel. Les notes de version sont consultables sur "https://www.openbsd.org/faq/upgradeXX.html". Remplacez "XX" par la version vers laquelle vous voulez mettre à jour.
Depuis la version 6.5, il suffit d'une simple commande pour réaliser la mise à jour vers la dernière publication release ou vers -current :
# sysupgrade
À CHAQUE FOIS : lisez les instructions officielles de changement de version.
Si votre installation date un peu, vous pouvez vérifier quels fichiers vous avez peut-être oublié de supprimer avec l'aide du port sysclean (commande du même nom).
Seront alors listés les fichiers qui ne sont pas censés être présents par rapport à un système de base. Lisez attentivement la sortie, car il y a fort à parier que la plupart sont des fichiers de configuration créés par vos soins 😉.
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 😼... Ça, c'est INDISPENSABLE.
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". C'est bien xx qui doit être précisé comme option de montage, c'est spécifique à la fonctionnalité altroot.
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 ! 😁
C'est surtout utile si vous réalisez cette sauvegarde sur un disque différent du disque principal.
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>.
boot> set device hd1a boot> boot -s
Ou tout en une seule fois :
boot> boot -s hd1a:/bsd
Si le moment venu vous ne savez plus sur quelle partition se trouve votre sauvegarde, entrez ceci :
boot> machine diskinfo
⚠ ATTENTION : seul le contenu de la partition racine / est sauvegardé. Si /usr/local, /var ou autres sont montées sur des partitions respectives, elles ne seront pas sauvegardées. Ce n'est pas grave pour dépanner un système puisqu'avec le partitionnement par défaut, vous disposerez quand même du système de base, mais en aucun cas des paquets tiers installés ou vos données de sites web, ... Le paragraphe suivant est donc essentiel, ne passez pas à côté 😉
N'hésitez pas à consulter la FAQ officielle qui parle de duplication de fichiers.
https://www.openbsd.org/faq/faq14.html#DupFS
Vous pouvez utiliser une partition dédiée à vos sauvegardes. Dans l'exemple ci-dessous, on utilisera le point de montage /mnt/sauvegarde créé pour nos besoins.
Je vous conseille d'installer l'excellent outil "rsync" pour vos sauvegardes, qui ne copiera que les fichiers qui ont été modifiés. Notez que sous OpenBSD, vous disposez de base d'un équivalent "openrsync".
Il s'agit en effet d'une réécriture de rsync pour OpenBSD, qui propose moins d'options et est actuellement moins performant, mais qui a le mérite d'exister par défaut.
Si la machine cible est une OpenBSD "pure" (sans le port rsync d'installé en plus), précisez l'option --rsync-path=openrsync. Par défaut, c'est l'exécutable rsync qui est utilisé sinon.
Voici un exemple d'utilisation sur votre serveur.
Ajoutez au fichier /etc/weekly.local les lignes suivantes afin de sauvegarder quotidiennement les dossiers /var et /usr/local :
/usr/local/bin/rsync -a --delete /var/ /mnt/sauvegardes/var.bak/ /usr/local/bin/rsync -a --delete /usr/local/ /mnt/sauvegardes/usrlocal.bak/
Notez que vous pouvez aussi envoyer des données à sauvegarder de votre ordinateur personnel si vous voulez utiliser votre serveur comme espace de stockage. À partir de cet ordinateur, lancez la commande :
$ rsync -e "ssh" -avz --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.
Vous pouvez créer une archive des différents points de montage de votre système avec tar.
Voici une proposition générant une archive avec un nom contenant la date du jour.
BACKDIR="/mnt/bckp"
BACKLIST="/var
/home
/etc"
for i in $BACKLIST; do
backupfile="${BACKDIR}/$(basename ${i})-$(date +%F).tar.gz"
tar -czf "${backupfile}" "${i}"
done
chmod 700 "${BACKDIR}"
# remove olds
#find "${BACKDIR}" -type f -mtime +90 -delete
À la fin du script, vous pouvez décommenter la ligne commençant par "#find" si vous souhaitez supprimer les archives vieilles de plus de 90 jours.
Le protocole SFTP ressemble beaucoup au célèbre FTP qui sert surtout à transférer des fichiers, mais se base sur un tunnel SSH. À vrai dire, chaque utilisateur disposant d'un accès SSH peut envoyer et télécharger des données en SFTP avec ses identifiants habituels. Un des avantages intéressant est de pouvoir reprendre un chargement partiel là où il en était, très utile pour envoyer/recevoir des fichiers volumineux.
Si vous voulez déployer un serveur SFTP pour un plus grand nombre d'utilisateurs, la mise en place d'un "chroot" est conseillée. Cette procédure est décrite plus loin dans le document car un poil plus complexe.
Pour copier des fichiers, vous pouvez utiliser la commande sftp :
$ sftp -P <port> utilisateur@chezmoi.tld
Si vous avez désactivé l'identification par mot de passe au profit des clés, indiquez quelle est votre clé privée ainsi :
$ sftp -P <port> -i ~/.ssh/clessh utilisateur@chezmoi.tld
ou :
$ sftp -P <port> -o IdentityFile=~/.ssh/clessh utilisateur@chezmoi.tld
Vous voilà alors devant une invite de commande.
Voici quelques commandes utiles :
Rien de bien compliqué finalement, mais vous préférerez peut-être un client graphique comme expliqué ci-dessous.
Selon votre système d'exploitation, il y a fort à parier que votre gestionnaire de fichiers soit lui même capable d'ouvrir une session SFTP (gvfs est utile pour ça). Comme chemin vers le dossier, indiquez simplement :
sftp://utilisateur@chezmoi.tld:222
Remplacez 222 par le port ssh du serveur (22 si vous ne mettez rien). Bien sûr, "utilisateur" est aussi à remplacer (par exemple jean_eudes ou toto).
sshfs (port "sshfs-fuse") est un outil qui permet de monter un dossier disponible via SFTP comme s'il s'agissait d'un point de montage de votre système. Peu importe votre gestionnaire de fichiers, vous pourrez copier vos documents comme s'il s'agissait d'un dossier classique.
sshfs s'utilise tout simplement ainsi :
sshfs -d utilisateur@chezmoi.tld:/dossier/distant /mnt/sftp
Ensuite, le dossier /mnt/sftp contiendra le contenu du dossier distant.
Dans le cas où vous utilisez une identification par clé uniquement, indiquez quelle clé privée utiliser ainsi :
sshfs -d utilisateur@chezmoi.tld:/dossier/distant /mnt/sftp \
-o IdentityFile=/home/toto/.ssh/sshkey
L'idée ici est d'enfermer dans un dossier les utilisateurs appartenant au groupe sftpusers que l'on crée pour cette occasion afin de gérer finement les permissions. Cela leur évitera de copier n'importe où leurs documents, d'accéder à des éléments sensibles ou encore de supprimer des éléments importants du serveur.
À titre d'exemple, nous allons mettre le chroot dans le dossier /var/sftp. Chaque utilisateur aura dans ce dernier un dossier qui lui sera propre. Il ne pourra pas en sortir. Les utilisateurs auront l'impression qu'il s'agit d'une nouvelle racine /. Automatiquement, ils seront placés dans un dossier /home situé dans cette nouvelle racine. Il faudra donc créer des répertoires /var/sftp/home/utilisateur1, /var/sftp/home/utilisateur2, ...
Créons de suite le groupe en question :
# groupadd sftpusers
Éditez le fichier de configuration ssh /etc/ssh/sshd_config puis ajoutez les lignes suivantes pour enfermer les utilisateurs de ce groupe dans un chroot :
Match Group sftpusers
ChrootDirectory /var/sftp/
ForceCommand internal-sftp
AllowTcpForwarding no
Notez que vous pouvez faire de même pour un utilisateur en particulier. Dans ce cas vous ajouterez une section "Match User utilisateur".
Si vous souhaitez ne permettre que l'identification par clé, précisez dans cette section :
PasswordAuthentication no
Ensuite, relancez SSH : "# rcctl reload sshd"
Créez maintenant un dossier /var/sftp pour que les utilisateurs y soient automatiquement placés à leur connexion.
# mkdir -p /var/sftp
Modifiez les permissions pour assurer le bon fonctionnement du chroot :
# chown root:wheel /var/sftp # chmod 700 /var/sftp
Chaque utilisateur du groupe sftpusers verra ce dossier comme la nouvelle racine "/". Notez que ces utilisateurs ne pourront qu'utiliser le protocole sftp, et donc la commande sftp (ou un client graphique), mais pas scp ou openrsync au travers d'un tunnel ssh.
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 :
# install -d -o ${user} -g ${user} -m 700 "/var/sftp/home/${user}"
L'utilisateur peut maintenant utiliser le protocole SFTP. Il sera enfermé dans son dossier précédemment créé.
Je vous invite à créer un script pour vous faciliter cette procédure :
#!/bin/sh
# addsftpuser.sh :
if [ $# -ne 1 ]; then
echo "usage: $0 user"
exit
fi
# CHANGE MOI
CHROOT=/var/sftp/
user="$1"
mkdir -p "${CHROOT}"
useradd -G sftpusers -s /sbin/nologin -m "${user}" || exit 1
install -d -o ${user} -g ${user} -m 700 "${CHROOT}/home/${user}"
exit
Si vous avez activé l'identification par clé, vous remplirez le fichier .ssh/authorized_keys dans le dossier personnel de l'utilisateur : celui placé dans /home, pas le /home du chroot mais celui du système hôte ⚠.