Serveurs Archives • Les nouvelles de Frédéric

Installer NextCloud sur un hébergement mutualisé Perso chez OVH

Dans ce tuto, nous allons installer NextCloud version 24.0.0.12 dans un hébergement mutualisé OVH de type ‘perso’.

NextCloud est un applicatif écrit en PHP et il utilise une base de données pour pouvoir fonctionner.

L’hébergement mutualisé Perso OVH dispose de 100 GB d’espace disque, dont on va utiliser ½ GB pour NextCloud lui-même, et une base de données MySQL de 200 MB dont environ 10 MB vont être utilisés dès le départ par NextCloud.

L’installation présuppose que vous êtes familier avec les hébergements OVH, et qu’il n’y a pas déjà une installation NextCloud dans cet hébergement.

Vous êtes supposé être capable de :

créer un nouveau site via la page ‘multisite’ de l’espace client,
activer un certificat SSL sur ce site
utiliser un client FTP comme FileZilla,
utiliser le protocole sftp plutôt que ftp,
créer une base de données MySQL
ou utiliser une base existante et en récupérer le mot de passe

Afin de ne pas alourdir inutilement le texte, les instructions qui y sont relatives pourront être concises.

Pour cet exemple, j’ai même utilisé l’hébergement Perso d’un autre domaine que celui qui nous intéresse:

Ce hébergement existe depuis 2008, ce qui explique la présence de fichiers portant cette date.

Voici la liste des fichiers via FTP:

On peut y voir ‘www’ et ‘drive’, qui sont les ‘dossiers racine’ des deux sites hébergés sur cet hébergement.

J’ai aussi créé ‘drivedata’ qui est destiné à contenir les fichiers utilisateur de NextCloud. Je recommande que ce répertoire ne se trouve dans aucun des dossiers racine des sites hébergés. Ainsi aucun site n’y a accès, en-dehors de NextCloud ou d’une autre application PHP hébergée.

Passons aux préparatifs sérieux.

Configurez l’hébergement avec la version la plus récente de PHP, actuellement stable64 et PHP 8.1.

Configurez le multi-site, afin que votre cloud ait une adresse unique (p.ex. drive.example.com mais pas www.drive.example.com)

N’activez pas le firewall. Activez les logs séparés ou non, selons vos désirs. Activez SSL, puis allez dans la page générale pour regénérer le certificat.

Téléchargez depuis https://nextcloud.com/install/#instructions-server

Vous allez recevoir un téléchargement du fichier ‘latest.zip’ (143 MB à la date de rédaction 15/05/2022, version 24.0.0.12).

Dézippez-le : 346 MB, 19500 fichiers et 3200 dossiers.

Il faut maintenant ‘pousser’ tout le contenu dans votre hébergement FTP, dans le répertoire /drive si vous avez suivi mon exemple. Ca prendra “un certain temps” ou “un temps certain”. A la fin vous aurez ceci :

Pendant que ça copie, vous pouvez préparer la base de données.

Vous devez être en possession de 4 paramètres (adaptez nomdelabase):

serveur: nomdelabase.mysql.db
base de données: nomdelabase
utilisateur: nomdelabase
mot de passe: vous seul le connaissez

Si cette base existe déjà (par exemple pour un site WordPress déjà présent) voyez dans les fichiers de configuration quels sont ces 4 paramètres (dans le cas de WordPress, vous pouvez consulter wp-config.php). Ne changez pas le mot de passe via l’espace client, car vous rendriez ce site inopérant.

Maintenant, lorsque la copie est terminée, vous pouvez visiter votre site en appelant son adresse définitive dans un navigateur (avec votre nom de domaine et https)

Vous devrez préciser une série d’informations ET ABSTENEZ-VOUS D’APPUYER sur ENTER ou de cliquer OK tant qu’on n’a pas rempli tous les champs:

login et mot de passe du futur admin
sélection de MySQL/MariaDB –> complétez les 4 paramètres nécessaires
sélection du répertoire data (je conseille /drivedata plutôt que /drive/data, voyez plus haut)

L’installation commence, et se termine sur un magnifique “Gateway Timeout”.
Attendre 5 minutes et se reconnecter à l’adresse du site.
Tout semble être là et parfaitement opérationnel.

Connectez-vous avec le compte admin.

Dans les réglages:

Administration > Paramètres de base, serveur e-mail: mode d’envoi “Sendmail”
Personnel > Informations personnelles > mettre une adresse mail > vous devriez recevoir un mail
Applications (depuis le menu à droite) > Pack d’applications
Eventuellement ajouter “Calendar” et “Contacts”.
Aller dans la gestion des utilisateurs ; créer un ou des groupes ordinaires et créer des utilisateurs non privilégiés dans ce groupe.
A partir de maintenant traviller exclusivement avec ces utilisateurs non privilégiés.

L’installation n’a pas été testée en profondeur dans des conditions réelles.

Considérez ceci comme une facilité à usage personnel.

N’allez jamais construire un cloud dans un tel hébergement web mutualisé, et qui deviendrait peu à peu un élément critique pour votre activité professionnelle.

Lors de mes essais, j’ai pu charger plusieurs centaines de photos et des vidéos pesant jusqu’à plus de 260 MB, alors que phpinfo() me dit: post_max_size 130M et upload_max_filesize 128M. C’est encourageant.

Bientôt la version de MySQL 5.6 proposée par OVH ne sera plus supportée par NextCloud, un jour ce sera autre chose, etc.

Sachez aussi qu’en ultime recours, vous trouverez :

les fichiers dans le répertoire ftp /drivedata
les événements Calendar sont dans la table `oc_calendarobjects`, dans le champ [blob] calendardata
de même les contacts se trouvent dans la table `oc_cards`, dans le champ [blob] carddata

SPF, DKIM, DMARC, petit rappel

Bonjour,

Je fais ici un petit rappel de théorie.

SPF, DKIM, DMARC, ça sert à quoi ?

Ces protocoles sont destinés à authentifier les e-mails émis par les utilisateurs de votre domaine . Ils n’empêchent pas la falsification (quelqu’un qui se fait passer pour vous ou vos collaborateurs) mais ils aident à les contrer d’une manière relativement efficace.
En fin de compte c’est le serveur en réception qui va consulter ou non vos directives (SPF, DKIM, DMARC) et éventuellement rejeter le mail falsifié si vous avez donné instruction qu’il fallait les rejeter.

OVH implémente SPF.
OVH n’implémente pas DKIM, ce qui en 2022 est assez inacceptable.
DMARC ne devrait pas être conseillé si vous n’avez pas DKIM. Chez OVH je le déconseille donc.

SPF sert à publier les adresses IP des serveurs qui sont autorisés à émettre des mails de votre domaine (typiquement ce sont les serveurs d’OVH. Si vous faites appel à une société extérieure pour des mailings, il faudra ajouter leurs serveurs)
Le SPF est publié dans votre zone DNS, dans un enregistrement TXT.

DKIM authentifie sur base d’une signature numérique dans les en-têtes SMTP, vous ne la voyez habituellement pas. A toute clé numérique il y a une partie privée (dans le cas de DKIM: détenue exclusivement par votre serveur mail d’envoi), et une partie publique, publiée dans votre zone DNS.
Le serveur en réception consulte la clé publique dans votre zone DNS pour vérifier la signature électronique du mail reçu. Si ça colle, alors le mail est authentique, quelle que soit l’adresse IP du serveur qui l’a envoyé.

Je rappelle que les serveurs d’envoi OVH n’insèrent pas de signature DKIM. Donc pas besoin de mettre une clé publique dans DNS non plus.

DMARC vous permet de donner des instructions aux serveurs en réception et comment ils doivent se comporter face à des mails qui échouent au contrôle SPF et DKIM. Le but est d’indiquer “si un mail échoue à SPF et DKIM alors il est frauduleux et il faut le refuser”.

Faire confiance à SPF tout seul est une loterie car un message qui fait l’objet d’une redirection ou via une mailing list sera considéré comme frauduleux, puisque l’adresse IP du serveur de l’émetteur n’est plus celle du domaine d’origine. (sauf si le redirecteur adhère à SRS, ce sera peut être l’objet d’un autre article !)

The 2020 Web Almanac

Voilà une compilation d’informations à garder en référence.
https://almanac.httparchive.org/en/2020/

Par exemple prenons le chapitre 11 sur la sécurité des sites Web. C’est d’une précision rarement atteinte dans tout ce que j’ai pu lire jusqu’à aujourd’hui.

https://almanac.httparchive.org/en/2020/security

Voici la table des matières de ce chapitre 11, capturé le 11 décembre 2020:

IndexIndex

    Introduction
        Methodology
    Transport security
        Protocol versions
        Cipher suites
        Certificate Authorities
        Browser enforcement
            HTTP Strict Transport Security
    Cookies
    Content inclusion
        Content Security Policy
        Subresource integrity
        Feature policy
        Iframe sandbox
    Thwarting attacks
        Security mechanism adoption
        Preventing XSS attacks through CSP
        Defending against XS-Leaks with Cross-Origin Policies
        Web Cryptography API
        Utilizing bot protection services
    Relationship between the adoption of security headers and various factors
        Country of a website's visitors
        Technology stack
        Co-occurrence of other security headers
    Software update practices
        WordPress
        jQuery
        nginx
    Malpractices on the web
    Evolution & conclusion

Domoticz, Zigbee, Sonoff, Tasmota, Raspberry Pi…

Ca fait un bail que je suis resté silencieux à propos de mon installation Domoticz (voir ici)

Pour rappel mon Domoticz tourne sur un Raspberry Pi 3B équipé d’un adaptateur PiZiGate, et mes périphériques sont: IPX-800, divers Sonoff, et des bidules Zigbee.

Entre-temps j’ai acheté un petit SSD (32€) et un adaptateur USB2-SATA (7€). En effet je n’ai pas envie d’attendre que la carte micro-SD de 8GB me claque entre les mains en raison de sa lente et inévitable usure.

J’ai installé un détecteur de fumée Zigbee, la transmission d’alerte par Telegram fonctionne.

Le dernier Sonoff Basic R2 que j’ai acheté n’a pas voulu fonctionner avec ESPeasy. Du coup j’ai essayé Tasmota et je l’ai adopté.

Enfin nous avons commandé des stores, et j’ai demandé une livraison avec moteur classique commandé par fil (et non avec une télécommande propriétaire Somfy). En attendant la livraison et l’installation, j’ai déjà préparé la commande à distance.

Pour chacun il y aura un relais Wifi à 2 canaux avec relais inverseurs à contact sec, avec la ferme intention de les flasher avec Tasmota comme j’ai fait précédemment avec les derniers Sonoff. Et surprise, alors que la photo montrait clairement les petits trous dans le circuit imprimé pour y brancher un câble série, le modèle que j’ai reçu en fait défaut !

Déception ! Du coup je me suis intéressé à piloter Domoticz > IFTTT > eWelink > relais et j’y suis arrivé avec un certain succès. Sauf que… eWelink est payant si on veut l’interfacer, statut VIP 10$/an ; et IFTTT est devenu payant si on veut avoir plus que 3 scripts, statut Pro 2$/mois !

Tout ça pour avoir un relais qui s’actionne avec 5 secondes de retard, voire plus, et être à la merci d’une défaillance de l’accès internet, de IFTTT, et/ou de eWelink. Payer et devoir dépendre des autres, non merci ! C’est l’occasion de rappeler tout le mal que je pensais de l’application eWelink qui demande de se foutre (virtuellement) à poil devant son appareil.

Après d’intéressantes lectures sur internet, notamment de data sheets du PSF-B04 en chinois (identification du chip en montage surélevé), je sors mon fer à souder équipé de sa panne la plus fine, pour souder 4 fils dont deux sur des pattes de circuit de 1 mm de large. Ceci me donne accès à GND (zéro volt), Vcc (+3.3) et les classiques TX et RX. Et hop, ça y est Tasmota est flashé dans l’appareil !

Je déclare cet appareil comme un Sonoff 4CH Pro même s’il n’a que 2 sorties.

Au niveau du câblage qui est prévu pour le store électrique, le relais 1 amène le courant ou le coupe, et le relais 2 est utilisé comme inverseur pour activer un moteur ou l’autre. Il est donc impossible de commander à la fois la montée et la descente, et il ne faut pas dépendre d’une fonction “interlock” du relais.

A ce stade, on peut commander les relais au moyen de la télécommande RF433 qui est livrée avec (si on a choisi ce modèle bien sûr), ou bien avec les boutons sur l’appareil, ou bien à partir de la page Web Tasmota à l’adresse IP où il se trouve. C’est peu convivial et uniquement une solution de secours.

On va lui ouvrir l’horizon. Dans Domoticz, on déclare 2 switches on/off virtuels à partir de Setup > Hardware > Virtual Sensors, et pour ces 2 switches, on leur donne un nom à chacun et la commande HTTP qui actionne le switch (ou MQTT pour ceux qui l’ont implémenté).

[Edit: avec MQTT configuré sur Tasmota, les On et Off Actions sont superflues]

On peut maintenant créer une ou plusieurs scènes où on va actionner ces switches pour en faire ce que l’on veut.

J’ai commandé des boutons Zigbee (ici ou ici ou autre modèle ici)

et la petite notice en chinois bien sûr, ici la page qui montre comment l’ouvrir pour changer la pile

Appairage:

Ces boutons différencient le simple clic et le double-clic. Celui-ci supporte aussi le triple et quadruple-clic, tandis que d’autres modèles reconnaissent un appui long. Je vais utiliser le simple-clic pour actionner le store (en inversant le sens) et le double-clic pour un arrêt immédiat. J’ai essayé avec des scènes et des scripts Blockly sans y arriver. Finalement un script dzVents de quelques lignes fait le travail à merveille

return {

   on = { devices = { 94 }},        -- idx of button

   execute = function(dz, item )
           dz.log("state of " .. item.name .. " is " .. item.state)
           if item.state == "1 Click" then
            dz.devices(73).toggleSwitch()    -- idx of up/down switch
            dz.devices(72).switchOn()      -- idx of power switch
        elseif item.state == "2 Click" then
            dz.devices(72).switchOff()    -- idx of power switch
        end
   end
}

Un mot d’explication:

Si le bouton idx=94 est activé, le script est exécuté. Si l’état est “1 Click” alors on inverse le switch2 (idx=73) pour monter/descendre et on allume le switch1 (idx=72) qui donne l’alimentation électrique. Lors de l’action “2 Click” (arrêt du store) le switch 1 est éteint.

En outre un timer de 17 secondes avait été mis sur le switch1, à régler quelques secondes de plus que l’ouverture ou la fermeture complète, ainsi on ne laisse jamais le store sous tension en permanence.

A remarquer que l’utilisation directe des boutons sur les relais, ou des télécommandes RF433 n’informent pas Domoticz de cette action. Une commande MQTT telle que ‘domoticz/in’ avec un payload ‘{ “idx” : 72, “nvalue” : 0}’ permet de changer l’état dans Domoticz sans que Domoticz n’envoie en écho (et possiblement en boucle infinie) un ordre d’extinction au relais.

Au niveau de Tasmota, avec les configurations MQTT et Domoticz complétées, plus aucun échange en http n’est encore nécessaire. La réactivité est bien meilleure et fiable dans les deux sens.

A propos des e-mails, S/MIME, chiffrement, signature

S/MIME permet de signer un e-mail, et/ou d’encrypter (le mot correct est: chiffrer) à des destinataires connus. Ceci se fait avec des certificats, clés privées tout comme pour les sites web https ou signer du logiciel.

Le mail signé apporte une preuve d’authenticité, de non-falsification et de non-répudiation
– authentique: le certificat de la personne ou entité qui a signé est attaché au mail signé. Une autorité (par exemple Comodo) a délivré ce certificat à une personne, une société… en vérifiant l’identité et l’adresse e-mail de cette personne. La signature possède aussi la date et l’heure de l’ordinateur utilisé.
– non-falsification: un hash (check-sum) est calculé sur l’entièreté du mail, et c’est le hash qui est signé. Si on n’enlève ne fût-ce qu’une virgule, la signature est invalidée.
– non-répudiation(*): Sur base de cette signature on peut attester qui a signé et quand, et la personne qui a signé ne peut pas se rétracter.

(*) selon le certificat qu’on a acquis

Pour l’encryptage, pourquoi destinataires connus ? Parce qu’envoyer un message encrypté à un destinataire inconnu n’a simplement pas de sens.

S/Mime agit au niveau des clients mails (logiciels de mail) et non au niveau des serveurs. On parle de sécurisation de bout en bout.
Au niveau des serveurs, un message signé et/ou encrypté est juste un message comme un autre, pouvant contenir des sections relatives à S/Mime.

Il y a une quinzaine d’années, il y a eu Thawte (sud-Africain) qui a proposé des certificats gratuits pour faire du mail. Ils ont arrêté cette offre.

Il y a une dizaine d’années StartCom StartSSL a fait quelque chose de similaire, puis StartSSL s’est fait racheter par des Chinois, sans rien annoncer au public. Les Chinois ont merdé avec des pratiques inacceptables (production de certificats anti-datés, etc, donc faux en écriture) et ils se sont fait bannir, plus personne n’a reconnu les certificats qu’ils émettaient. Ils ont mis la clé sous le paillasson début 2018.

Il y a aussi eu notoirement Comodo, mais là c’est fini aussi.

Depuis, pour trouver un certificat gratuit émanant d’une autorité de certification il faut se gratter.

La carte d’identité belge permet de signer numériquement des documents, par exemple via Adobe Reader, mais ne permet pas de signer un e-mail. En effet la Belgique atteste de votre identité, mais absolument pas que votre adresse e-mail correspond à votre personne.

Lecture: http://kb.mozillazine.org/Getting_an_SMIME_certificate

Alternative, faire son propre CA et générer ses certificats soi-même,
Comme l’échange encrypté ne s’improvise pas, on peut envoyer ses certificats à ses correspondants par un autre moyen que le mail et on se fait confiance réciproquement. Ca fonctionne.

Signer avec un certificat qu’on a fabriqué soi-même n’apporte de la valeur ajoutée qu’auprès des correspondants réguliers qui peuvent enregistrer le certificat dans leur registre d’émetteurs de confiance.

Alternative: regarder du côté de gpg, système anarchique (sans autorité centrale) et qui fonctionne via un réseau de confiance.

Noter qu’aucun webmail ne peut valablement sécuriser vos e-mails car l’admin du webmail peut être le maillon faible.

Installer un webmail Roundcube sur Debian 10

Chers lecteurs bonjour,

Dans un article précédent j’avais proposé l’installation d’un serveur d’envoi de mail, avec liberté de spécifier l’adresse mail de l’expéditeur et signature DKIM.

Cet article-ci est une continuation et présuppose que vous ayez réalisé ce serveur. Néanmoins tout serveur Debian peut faire l’affaire.

A ce stade on avait installé: Postfix, SASL, OpenDKIM.

Pour le Webmail Roundcube, il faut: un serveur de courrier de type IMAP, un serveur d’envoi SMTP, et pour le logiciel à installer: Apache2, PHP, MySQL/MariaDB, Certbot, Python.

Il faut bien se rendre compte que ce serveur ne contiendra à aucun moment les messages e-mail des utilisateurs, mais bien les carnets d’adresses que ceux-ci auraient constitués sur le webmail ainsi que les préférences d’affichage.

A vous de déterminer votre politique de backup ou l’absence de celle-ci.

Dans l’article précédent j’avais appelé le serveur bazooka.example.com.

Vous avez peut-être envie de “vendre” votre webmail avec un nom plus cohérent, par exemple rc.example.com (rc pour Roundcube)

Dans la zone DNS de example.com, vous ajouterez une entrée, soit un CNAME qui redirige rc vers bazooka, soit une entrée A vers l’adresse IP du serveur.

Testez en faisant:

ping rc.example.com

Je vous livre les commandes à exécuter sur le serveur lui-même pour installer des packages supplémentaires, à partir de l’utilisateur root.

apt-get install apache2 mariadb-server mariadb-client
apt-get install php php-common php-curl php-mysql php-mbstring 
apt-get install php-intl php-imagick php-pear php-ldap php-json php-xml

On va créer un utilisateur ‘rc’ sous lequel le webmail sera installé.

adduser rc (répondez aux questions)

Visitez maintenant le site de Roundcube, et identifiez la dernière version stable dans les downloads. Copiez l’adresse du download “Complete” dans votre presse-papiers, on va en avoir besoin.
Lors de la rédaction de cet article, il s’agit de https://github.com/roundcube/roundcubemail/releases/download/1.4.3/roundcubemail-1.4.3-complete.tar.gz

On va se connecter dans le contexte de l’utilisateur rc, et exécuter une série de commandes:

# su - rc

$ wget https://github.com/roundcube/roundcubemail/releases/download/1.4.3/roundcubemail-1.4.3-complete.tar.gz
$ tar xvfz roundcubemail-1.4.3-complete.tar.gz
$ mv roundcubemail-1.4.3 www

(Roundcube est maintenant dans le sous-dossier www. Vous pouvez un peu investiguer ce dossier, et lire le fichier INSTALL)

Terminez la session de l’utilisateur ‘rc’ avec control-D, on revient dans le shell ‘root’.

On va créer un lien symbolique entre l’emplacement du site web par défaut (/var/www/) et le répertoire www de l’utilisateur ‘rc’ (/home/rc/www/).

cd /var/www
ln -s /home/rc/www rc

On va configurer ce nouveau site dans Apache

cd /etc/apache2/
cd sites-available/
cp 000-default.conf rc.conf

On va éditer ce fichier de configuration rc.conf . J’indique juste les lignes qui ne sont pas des commentaires.

<VirtualHost *:80>
ServerName rc.example.com
ServerAdmin webmaster@example.com
DocumentRoot /var/www/rc
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined

puis on l’active:

a2ensite rc
systemctl reload apache2

On le teste via l’adresse http://rc.example.com , on doit recevoir ce message d’erreur:

CONFIGURATION ERROR
config.inc.php was not found.
Please read the INSTALL instructions!

Sous debian, on a un éternel problème de permissions dans la configutation standard. Le serveur web tourne sous l’utilisateur www-data. On va réciproquement partager les groupes de ‘rc’ et ‘www-data’ pour diminuer les problèmes de droits d’accès:

adduser www-data rc
adduser rc www-data
service apache2 restart

Il faut créer une base de données ‘rc’, un utilisateur ‘rc’ et des droits d’accès.

mysql
mysql> CREATE DATABASE `rc`;
CREATE USER 'rc' IDENTIFIED BY 'password';
GRANT USAGE ON *.* TO 'rc'@localhost IDENTIFIED BY 'password';
GRANT ALL privileges ON `rc`.* TO 'rc'@localhost;
FLUSH PRIVILEGES;

Tout devrait maintenant être prêt pour procéder à l’installation du webmail. On a:

un serveur SMTP
un serveur IMAP
une base de données

Comme indiqué dans la documentation de Roundcube, on dirige son navigateur vers http://rc.example.com/installer

tout est ok ? >> [Next]

il faut changer les permissions d’accès aux répertoires temp et logs :

chmod g+rwx /var/www/rc/temp /var/www/rc/logs

Je choisis de ne pas utiliser de Spell checker.

Pour la database choisir: mysql, puis host=localhost, database=rc, user=rc, password.

On peut opter pour un préfixe rc1_ ça peut toujours servir si plusieurs instances devaient partager une base de données.

imap:
POUR OVH: ssl://ssl0.ovh.net (c’est bien un zéro, pas un O)
POUR GMAIL: ssl://imap.gmail.com (Gmail ne le permet pas sans changer plusieurs réglages au préalable sur son compte Gmail)

smtp:
tls://localhost, port 587 , user: (votre utilisateur créé dans l’article précédent)
décocher: [ ] use the current IMAP username

Ensuite on clique sur [Next]

L’installer propose de télécharger le fichier de configutation généré, téléchargez-le donc, et ouvrez-le avec Notepad (bloc-notes)

Cherchez “smtp_server” et ajoutez les lignes indiquées en rouge:

$config['smtp_server'] = 'tls://localhost';

// SMTP port. Use 25 for cleartext, 465 for Implicit TLS, or 587 for STARTTLS (default)
$config['smtp_port'] = 587;

$config['smtp_conn_options'] = array(
'ssl' => array(
'verify_peer' => false,
'verify_peer_name' => false,
), );

// SMTP username (if required) if you use %u as the username Roundcube
// will use the current username for login
$config['smtp_user'] = '...';

// SMTP password (if required) if you use %p as the password Roundcube
// will use the current user's password for login
$config['smtp_pass'] = '...';

Cette modification est rendue nécessaire car le serveur SMTP se présente avec un certificat auto-signé. Sans cette configuration, le client (webmail) échoue lors de la connexion car le certificat n’est pas authentifié par une autorité de certification (CA).

Copiez l’entièreté du fichier de configuration dans votre presse-papiers et recopiez-le sur le serveur comme ceci :

cat > /var/www/rc/config/config.inc.php

puis collez (sous PuttY, c’est un clic droit). Puis faites un retour à la ligne et control-D

Cliquez sur [Next].

La base de données n’est pas initialisée, faites-le en un clic comme proposé.

Testez SMTP en indiquant une adresse d’expéditeur (de préférence configurée dans le chapitre précédent DKIM) et une adresse de destinataire. Le mail doit vous parvenir. Vous pouvez inspecter les en-têtes.

Ou mieux, obtenez une adresse temporaire sur mail-tester.com, envoyez-y un mail et vérifiez votre joli score de 10/10 !

Testez IMAP avec une adresse complète et son mot de passe.

Il nous reste quelques petits détails à régler. Par défaut PHP ne permet que des uploads de 2 mégabytes, c’est bien trop peu pour un webmail. Je propose 40 MB.

Dans le fichier /etc/php/7.3/apache2/php.ini, recherchez ces 2 lignes et augmentez leur valeur:

upload_max_filesize = 40M    #(au lieu de 2M)
post_max_size = 48M          #(au lieu de 8M)

et redémarrez Apache:

service apache2 restart

Maintenant que tout fonctionne, il manque quelque chose d’essentiel: https ?

apt-get install certbot python-certbot-apache
certbot --apache

Cette machine est encore presque vierge. On ne prend pas de risque à laisser Certbot faire automatiquement les modifications.

Après avoir accepté les termes de licence, donnez une adresse mail réelle, puis indiquez le nom du site web à protéger, en donnant son numéro dans la liste proposée. Vous pouvez opter de rediriger la version http vers https, n’hésitez pas à le faire. Ca fonctionne.

Certbot va s’occuper de regénérer automatiquement votre certificat tous les deux à trois mois.

Vous pouvez vérifier que le processus de mise à jour est opérationnel:

certbot renew --dry-run

Happy Webmail !

Serveur mail d’envoi + signature DKIM + liberté de choix d’adresse de l’expéditeur

On entend souvent les clients OVH se plaindre à propos du mail:

envoi compliqué, soumis à des quotas par heure et par IP
réputation médiocre des serveurs d’envoi partagés avec les autres clients
selon l’offre d’hébergement, impossible d’envoyer un mail à partir d’un alias ou adresse de redirection
absence de signature DKIM
mails envoyés qui disparaissent parfois, et aucun moyen de les retracer
webmail roundcube remplacé par Outlook Web (les choix ça ne se discute pas)

Dans ce tuto pas à pas, je vous propose de réaliser un serveur mail ayant les fonctionnalités suivantes:

envoi uniquement
pas de réception de mail (donc pas de problématique de filtrage du spam, etc)
pas d’hébergement de boîtes mail (le serveur ne contient aucune donnée à conserver)
c’est “votre serveur”, donc une adresse IP dédiée dont la réputation ne tient qu’à vous
soumission de mail uniquement via TLS sur le port 587 pour les utilisateurs autorisés.
Le port 25 est fermé.
le login d’authentification n’est pas relié à l’adresse mail de l’expéditeur
ajout de la signature DKIM pour un ou plusieurs domaines
accès aux fichiers log permettant un diagnostic (livraison ? refus ? etc)
En option, installation d’un serveur webmail roundcube, les messages restant sur le serveur IMAP. C’est publié ici !

Le tuto est réalisé sur la base d’un serveur VPS à 3€ TVAC par mois, loué au mois sans engagement, chez le fournisseur Hetzner. Il a un processeur 1 coeur, 20 GB de disque, 2 GB de RAM. C’est largement suffisant pour ce qu’on veut en faire. Vous avez le choix du fournisseur de cloud VPS. Il faut un VPS où vous avez le droit ‘root’.

Au niveau logiciel, debian 10.3, postfix, sasl, opendkim.

Il faut baptiser ce serveur (lui donner un nom complet dans un de vos domaines). Je déconseille formellement les nouveaux noms de domaines .site, .xyz, .pro, .bid, .best et autres, aussi bien dans le nom du serveur que dans les adresses mail d’expéditeur. Ces suffixes sont trop abusés par les spammeurs.

Appelons notre serveur bazooka.example.com dans la suite.

Supposons que vous avez 2 clients Tom et Jerry qui doivent recevoir chacun un login pour pouvoir envoyer des mails via ce serveur. Vous devez avoir confiance dans vos clients. Si l’un d’eux se met à spammer, il va pourrir la réputation de l’adresse IP de votre serveur.

Tom possède 2 domaines asteryx.be et obelyx.be dont les mails sortants devront être signés DKIM en sortie par notre serveur. (à la date de rédaction, ces 2 domaines sont libres)

Au niveau DNS, on devra

ajouter une entrée A pour bazooka.example.com. La mise à jour se fait dans la zone DNS là où le domaine example.com est hébergé.
mettre à jour le reverse (une entrée PTR) liée au serveur VPS. Cette mise à jour se fait chez le fournisseur du VPS et doit intervenir après l’étape précédente. N’oubliez pas de faire de même pour votre adresse IPv6 le cas échéant. C’est nécessaire pour le mail sortant.
ajouter une entrée TXT pour chacune des clés publiques DKIM. Cette mise à jour se fait par Tom ou son prestataire, auprès de l’hébergeur des domaines asteryx.be et obelyx.be.
Si vos domaines ont un enregistrement SPF, n’oubliez pas d’y ajouter l’adresse IP de votre nouveau serveur sous la forme IP4:123.45.67.89 . Idem pour l’adresse IPv6.

Hop à vos claviers ! Vous êtes supposé être capable d’utiliser ssh, putty, vi ou nano, et les commandes basiques.

Le serveur VPS est livré avec Debian 10 “tout nu”.

Commencez par changer le mot de passe de ‘root’, minimum 10 caractères, lisez mon article : Votre mot de passe est-il sûr ? .
Ou mieux, abandonner les bons vieux mots de passe au profit des clés ssh.

Mise à jour du système

apt-get update && apt-get dist-upgrade

Une petite parenthèse ici: si vous ne souhaitez pas que l’éditeur vi fasse de l’analyse syntaxique en couleurs, tapez la commande suivante:

echo syntax off >> ~/.vimrc

On va indiquer le nom du serveur, en éditant /etc/hostname : mettre le nom complet bazooka.example.com ; et /etc/hosts : à côté de l’adresse IP remplacer l’ancien nom par le nom complet, un espace, puis le nom court:

123.45.67.89 bazooka.example.com bazooka

Définition de notre fuseau horaire:

dpkg-reconfigure tzdata

Un reboot à ce stade ne fait pas de tort: “reboot” ou “shutdown -r now”.
Ensuite on va installer les packages qui nous intéressent, d’abord nos boîtes à outils:

apt-get install whois at telnet ntp mailutils dnsutils

et ensuite

apt-get install postfix

Cette installation pose une question. Il faut dire qu’il s’agit d’un “internet site” et renseigner le nom de ce serveur: bazooka.example.com

On continue:

apt-get install sasl2-bin libsasl2-modules

Comment cela fonctionne-t-il ?

Postfix transporte du mail mais ne gère pas l’authentification des utilisateurs. Pour cela on fait appel à un “sous-traitant” nommé SASL, une librairie qui sert exclusivement à cela.

Installation de SASL

Dans notre serveur, SASL validera sur base d’un compte Unix.
Configuration de SASL, on édite le fichier /etc/default/saslauthd

On change la ligne:
START=yes
Remarquez MECHANISMS=”pam” qui indique l’utilisation du compte Unix

et la dernière ligne doit être remplacée par:

OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd"

Sauvez le fichier.

On doit mettre Postfix dans le groupe SASL pour pouvoir avoir accès au socket de communication inter-processus.

adduser postfix sasl

et on redémarre le démon:
service saslauthd restart

On crée un compte pour tom

adduser tom
(-> répondre aux questions )

chsh tom
(-> répondre: /usr/sbin/nologin )

On vérifie que SASL est capable de valider le login/pass de Tom:

testsaslauthd -u tom -p goodpassword -f /var/spool/postfix/var/run/saslauthd/mux
0: OK "Success."

testsaslauthd -u tom -p badpassword -f /var/spool/postfix/var/run/saslauthd/mux
0: NO "authentication failed"

On fait de même pour jerry.

Configuration de Postfix

Postfix s’appuie essentiellement sur deux fichiers /etc/postfix/master.cf et /etc/postfix/main.cf.

Editez /etc/postfix/master.cf pour apporter les modifications suivantes:

Mettez en commentaire la ligne qui commence par “smtp”. Ceci empêchera la réception de mail sur notre serveur.
Décommentez la ligne qui commence par #submission ainsi que la dizaine de lignes de continuation qui suivent.

Editez /etc/postfix/main.cf et ajoutez ce bloc de lignes, mettez-le par exemple en-dessous des paramètres TLS

# suggéré via blog.demees.net
smtpd_restriction_classes = mua_sender_restrictions, mua_client_restrictions, mua_helo_restrictions
mua_client_restrictions = permit_sasl_authenticated, reject
mua_sender_restrictions = permit_sasl_authenticated, reject
mua_helo_restrictions = permit_mynetworks, reject_non_fqdn_hostname, reject_invalid_hostname, permit
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = smtpd
smtp_tls_security_level = may
message_size_limit = 40960000

Plus bas, vérifiez que la ligne “myhostname=” contient bien le nom complet du serveur, par exemple bazooka.example.com.

Il faut relier Postfix avec le démon saslauthd, via le fichier /etc/postfix/sasl/smtpd.conf :

pwcheck_method: saslauthd
mech_list: PLAIN LOGIN

Sauvez, et puis tapez la commande: postfix reload

A ce stade le serveur mail est opérationnel, mais sans DKIM.

Installation de OpenDKIM

Comme pour SASL, l’ajout de DKIM se fait par un module complémentaire.

Postfix et DKIM vont communiquer par un “socket” TCP n° 12301 choisi arbitrairement et que vous pouvez altérer à votre guise, des deux côtés de la configuration.

apt-get install opendkim opendkim-tools

A nouveau, on va éditer les fichiers de configuration, puis créer des clés pour les domaines dont il faut authentifier les mails.

Edition de /etc/opendkim.conf

On va ajouter tout un bloc de paramètres, et s’assurer de bien désactiver (mettre en commentaire) toute instruction contradictoire déjà présente.

# suggéré via blog.demees.net, inspiré d'un tuto sur Digitalocean
AutoRestart Yes
AutoRestartRate 10/1h
UMask 002
Syslog yes
SyslogSuccess Yes
LogWhy Yes
Canonicalization relaxed/simple
ExternalIgnoreList refile:/etc/opendkim/TrustedHosts
InternalHosts refile:/etc/opendkim/TrustedHosts
KeyTable refile:/etc/opendkim/KeyTable
SigningTable refile:/etc/opendkim/SigningTable
Mode s
PidFile /var/run/opendkim/opendkim.pid
SignatureAlgorithm rsa-sha256
UserID opendkim:opendkim
Socket inet:12301@localhost

Edition de /etc/default/opendkim : une seule ligne “SOCKET” doit subsister comme ceci. Les autres lignes “SOCKET=”doivent être mises en commentaire.

SOCKET=inet:12301@localhost

On doit encore ajouter quelques lignes à la configuration de Postfix pour lui indiquer comment communiquer avec OpenDKIM.

Ajoutez ces lignes dans /etc/postfix/main.cf, par exemple juste en-dessous de celles qu’on a ajoutées précédemment:

#OpenDKIM
milter_protocol = 2
milter_default_action = accept
smtpd_milters = inet:localhost:12301
non_smtpd_milters = inet:localhost:12301

On a encore du travail avec OpenDKIM

mkdir /etc/opendkim
mkdir /etc/opendkim/keys

On va créer une paire de clés par domaine. J’explique pour asteryx.be, il en est de même pour obelyx.be.

cd /etc/opendkim/keys
mkdir asteryx.be && cd asteryx.be
opendkim-genkey -s selector1 -d asteryx.be
chown opendkim:opendkim selector1.private

Il en résulte deux fichiers: selector1.private (clé privée à garder précieusement) et selector1.txt (clé publique à publier via DNS)

On va encore créer les fichiers suivants dans /etc/opendkim :

/etc/opendkim/TrustedHosts

127.0.0.1
localhost
192.168.0.1/24
#*.example.com

/etc/opendkim/SigningTable

*@asteryx.be selector1._domainkey.asteryx.be
*@obelyx.be selector2._domainkey.obelyx.be

/etc/opendkim/KeyTable

selector1._domainkey.asteryx.be asteryx.be:selector1:/etc/opendkim/keys/asteryx.be/selector1.private
selector2._domainkey.obelyx.be obelyx.be:selector2:/etc/opendkim/keys/obelyx.be/selector2.private

selector1 et selector2 sont des exemples, vous pouvez mettre ce que vous voulez en format alphanumérique, ce peut être bazooka, mail, mars2020. Il faut juste que ça corresponde avec l’entrée DNS que vous allez créer.

Vous transmettez le fichier asteryx.be/selector1.txt à l’administrateur du domaine asteryx.be. Celui-ci doit s’arranger pour ajouter cette clé publique dans un enregistrement TXT de sa zone DNS. Ca peut se trouver un peu compliqué car le contenu du champ est assez long. Parfois on doit passer par une édition en mode texte pour ajouter un tel enregistrement. La clé publique à publier dans DNS se trouve dans le fichier selector1.txt .

Voici un exemple avec k3 comme nom de selecteur et le nom de domaine fdm.ovh.

root@k3:/etc/opendkim/keys/fdm.ovh# cat k3.txt
k3._domainkey   IN      TXT     ( "v=DKIM1; h=sha256; k=rsa; "
          "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuWfTdOfeAXRt7nZkRSy46JWpk6mTC1vPtvUVdEQmYv+fzHesqWxtV8Ww7uq8L63p2L6OU8p61Deslodj3YjFL8vw9nVgt3/I1igPaPMuRcbHaM4WQnjOw6exP+U8qMTZEIpTgByowmmIruWXx/60QamRWGxdBxEWR9wZAgMZNYlVuafR+HjcdS1m2sVZqNSPFqx/q1E8ZnAyHI"
          "L0rQ7/qtIMHAB4MlK/eVvPPmGvx4djlaQJpCZfgMDdg0dzJMMvUMu37csCQcW/2XkoSOm6N2GlCEvKeYA2fZ66sKPKR3RhIuPZR/XHwLM/2fcsuUu6A/NiMSW1okmt/prI1xNaIQIDAQAB" )  ; ----- DKIM key k3 for fdm.ovh

après importation réussie dans DNS vous pouvez vérifier avec la commende dig, tout est sur une ligne. La commande nslookup peut vous présenter la réponse en plusieurs lignes où chaque morceau est encadré avec des apostrophes (“).

# dig +short k3._domainkey.fdm.ovh txt
"v=DKIM1; h=sha256; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuWfTdOfeAXRt7nZkRSy46JWpk6mTC1vPtvUVdEQmYv+fzHesqWxtV8Ww7uq8L63p2L6OU8p61Deslodj3YjFL8vw9nVgt3/I1igPaPMuRcbHaM4WQnjOw6exP+U8qMTZEIpTgByowmmIruWXx/60QamRWGxdBxEWR9wZAgMZNYlVuafR+H" "jcdS1m2sVZqNSPFqx/q1E8ZnAyHIL0rQ7/qtIMHAB4MlK/eVvPPmGvx4djlaQJpCZfgMDdg0dzJMMvUMu37csCQcW/2XkoSOm6N2GlCEvKeYA2fZ66sKPKR3RhIuPZR/XHwLM/2fcsuUu6A/NiMSW1okmt/prI1xNaIQIDAQAB"

C:\> nslookup -q=txt selector3._domainkey.fdm.ovh
Server:  s.home.local
Address:  192.168.99.2

Non-authoritative answer:
selector3._domainkey.fdm.ovh    text =

        "v=DKIM1; h=sha256; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA16O6zg653ZlnH6gSj+XcW1+bM07qXMuQ3dOOkcCgUQ6xAOMe+EtlMSGs7SdvcCG5PM7d0G3VxZx2CpXU56M3pa3/j7yV3CE2Iq+YEKeNoo/rdiTD5wbGnGmcIOxrLKfzUQoGGdfLjXt8L0OBaFa5xjamZQk/bjz+zIWRKEoXpG95N2VbAU"
        "U1oR3wbLzwuz6W2KOViP1ihK5/iIUbNBKPOF/Ue6lz8bZuSVJc54+PWdHxv/t+E51wvErFHpoFEVNnCdFbLZWL6fZ0pGdFKIv1sllKNhHw1orwGi/4UGuitLtnRsPIw2qjFXWC8XKDUrVKUDxf0i3I9wK9LEXBp63e9QIDAQAB"

Pour être certain que tout est bien réalisé et que tout redémarre de manière ordonnée, faites un reboot (toujours avec la commande “reboot” ou la commande “shutdown -r” ; jamais via le panneau d’administration de votre cloud ! jamais en tirant la prise !)

Enfin il nous reste une petite intervention à faire: si le serveur doit envoyer des mails à postmaster ou root, vous souhaitez les recevoir sur votre adresse habituelle.

Editez le fichier /etc/aliases, ajoutez une ligne

root: moi@example.net

sauvez et tapez la commande : newaliases.
Faites un test avec la commande: “echo test|mail root”

Ceci termine l’installation du serveur mail.
La maintenance est minimale. Par défaut Debian fait le ménage régulier des fichiers log pour que le disque ne se remplisse pas. Le serveur est peu vulnérable aux attaques si les mots de passe sont bien choisis.

Configuration de votre logiciel client

Dans votre client mail, par exemple Thunderbird, vous configurez un nouveau serveur d’envoi avec les paramètres suivants:

Thuderbird SMTP settings

Le mot de passe sera demandé lors de la première utilisation.

Et le webmail Roundcube ?

Je vous l’avais annoncé en titre. Avec le confinement du Coronavirus, j’ai trouvé le temps de rédiger cet article ! C’est par ici …

Votre mot de passe est-il sûr ?

Des listes de mots de passe circulent sur internet.

Plusieurs sites proposent ces dictionnaires en téléchargement, par exemple https://crackstation.net/

Pour voir si votre “excellent mot de passe” existe dans cette liste, cela se fait en deux temps.

calculez le hash sha-256 de votre mot de passe. Le hash est une procédé irréversible qui ne permet pas de reconstituer ce qui a été hashé.
présentez ce hash au site en question. S’il vous rend le mot de passe non hashé, c’est qu’il se trouve dans son dictionnaire, et est donc à déconseiller.

Pour calculez le hash d’un fichier, il y a des sites web par dizaines. Par exemple https://xorbin.com/tools/sha256-hash-calculator

Si vous ne voulez pas soumettre votre secret à un site inconnu, utilisez votre linux favori:

# echo -n “p@ssword”|sha256sum
0fd205965ce169b5c023282bb5fa2e239b6716726db5defaa8ceff225be805dc –

Puis vous allez sur crackstation.net et vous introduisez le hash (sans le “-” final)

Il vous restitue instantanément p@ssword car il est dans son dictionnaire.

Si vous avez oublié un mot de passe, demandez-le à Google !

Ce billet s’adresse plutôt aux utilisateurs d’Android et de Chrome.
Les aficionados de la Pomme auront probablement confié leurs précieux mots de passe à cette société-là.

Préambule: il est important que personne ne connaisse votre mot de passe Gmail / Google.

Allez voir ce site: https://passwords.google.com et puis Password Checkup.
(Si vous êtes parano et demi, ne cliquez pas sur ce lien, mais retapez l’adresse dans une autre fenêtre)

Vous devrez retaper votre mot de passe Google, et c’est très bien ainsi, car on va voir bien des choses.

Google va vous énumérer des sites où ce mot de passe a (probablement) été compromis, ceux où vous avez utilisé le même password, et ceux où vous avez un mot de passe “faible”.

En cliquant sur la petite flèche à droite, on peut détailler.Je viens de vous dévoiler que j’ai utilisé le même mot de passe sur tous ces sites.

On peut détailler encore plus. Cliquez sur ces trois petits points ⋮

Vous pouvez voir ce mot de passe et même le sélectionner pour le recopier ailleurs.

Postambule: il est important que personne ne connaisse votre mot de passe Gmail / Google.

Tous ces mots de passe stockés là le sont par votre propre volonté. Vous avez demandé à Google de les mémoriser, soit dans votre téléphone, soit dans une autre application Google comme Chrome.

Mais de là à les voir affichés en clair, c’est inattendu. Parmi les mots de passe mémorisés, seuls ceux posant problème peuvent être affichés.

Let’s Encrypt everything, la grosse arnaque du siècle !

Rappelez-vous de l’époque où on utilisait HTTPS uniquement pour les communications ayant un caractère privé (on parle aussi de TLS, SSL, certificats, etc).

A cette époque, pour obtenir un certificat, il fallait se diriger vers une autorité de certification, démontrer qu’on était autorisé à faire cette demande, payer une certaine somme, et installer ce certificat sur le serveur web, pour bénéficier d’une protection des communications transmises via le web. Toute cette procédure était assez malaisée pour le “webmaster moyen”.

Puis la grande vague “Let’s Encrypt” est passée par là depuis fin 2015, et tout le monde est en train de tout encrypter, facilement et gratuitement. Même les horaires de l’autobus. Même le présent blog. Même l’édition gratuite de la gazette. Même la recette du pot-au-feu de Mme Michu.

En fait tout le monde s’en fichait un peu, jusqu’au moment où Google, déjà victorieux de la troisième guerre mondiale, celle de l’information, a décidé de pénaliser les sites non-HTTPS dans ses résultats de son moteur de recherche en les éjectant de la première page.

Non content de crypter le trafic web mondial, il faut passer à la vitesse supérieure. On va de plus en plus encrypter le trafic DNS (conversations de machine à machine – entre autres répondre aux questions telle que celle-ci: quelle est l’adresse IP de xxx.com) , de telle manière que personne entre l’utilisateur et le serveur DNS questionné ne puisse “sniffer le câble” et prendre connaissance des questions DNS, et donc des sites visités et des habitudes de surf de l’utilisateur.

En fait tout ça me plaît lorsque que j’utilise le wifi gratuit mis à disposition par stib.brussels, ou bien un hôtel d’une grande chaîne ou le petit restaurant viet du coin. Ils n’ont pas à savoir si je vais sur Facebook et quels sont mes amis, ni intervenir dans mes conversations Skype. Ca me rassurerait “presque” d’oser utiliser ma banque en ligne.

Bien au contraire, les e-mails (ou mèl, ou courriels, …) sont très mal protégés. En 2019 la quasi-totalité des communications e-mail sont sécurisées. A moins d’utiliser Gmail, Hotmail ou équivalent, vous savez sans doute trop bien que c’est compliqué de configurer une messagerie sur votre téléphone ou PC. En contrepartie si les communications sont sécurisées, tous vos e-mails sont stockés en clair sur les disques durs de la société qui héberge vos mails. C’est à dire que vous êtes à poil devant Apple si vous mettez tout dans iCloud ; devant Microsoft pour Hotmail, Office365, Live, Onedrive ; devant Google pour Gmail et Googledrive…

Quand vous envoyez une information commerciale importante ou sensible à plusieurs personnes, combien de fois pouvez-vous affirmer qu’il n’y a pas au moins un destinataire chez ces Google, Apple et consorts ?

Tout ceci a un effet insidieux sur la sécurité des entreprises. Le responsable de la sécurité informatique se trouve fort démuni lorsqu’il doit prendre toutes les mesures contre les infections de virus et autres bestioles malfaisantes, exfiltration de données d’entreprise, visites de sites inacceptables, et j’en passe et des meilleures.