• L’identification du serveur et la sécurisation du flux
• L’identification du client
• L’authentification du client

Vous devez faire le bon compromis entre sécurité et flexibilité. Il ne faut pas forcément pousser le bouton à fond pour tous les cas de figures.

Génération des clés et certificats

Pour MQTTS, 2 options s’offre à vous comme pour un serveur HTTPS :

• générer vos certificats auto-signé
• via une autorité de certification

Dans mon cas ce n’est que du local, ce sera donc de l’auto-signé.

Je génère toujours les clés et certificats sur ma machine perso et ensuite je copie les certificats/clés sur le serveur et les clients, afin de les archiver. C’est donc à faire dans un dossier à garder sous Linux ou en WSL sous Windows.

Veillez bien à remplacer les DNS suivants par votre domaine externe pointant sur votre serveur ainsi que votre DNS interne ou IP interne pour joindre votre serveur MQTT (dans mon cas installé sur mon serveur Jeedom) : DNS:jeedom.YOURDOMAIN.TLD,DNS:jeedom.home

mkdir ca broker clients

#CA
openssl genrsa -out ca/ca.key 2048
openssl req -new -x509 -days 9999 -subj "/C=BE/CN=MQTT-CA/O=home" -key ca/ca.key -out ca/ca.crt

#broker
openssl genrsa -out broker/mosquitto.key 2048
openssl req -new -subj "/C=BE/O=home/CN=MQTT-mosquitto" -key broker/mosquitto.key -out broker/mosquitto.csr
openssl x509 -req -extfile <(printf "subjectAltName = DNS:jeedom.YOURDOMAIN.TLD,DNS:jeedom.home,DNS:localhost,IP:127.0.0.1,IP:::1") -in broker/mosquitto.csr
 -CA ca/ca.crt -CAkey ca/ca.key -CAcreateserial -out broker/mosquitto.crt -days 9999 -sha256
 
#client (facultatif) si on souhaite une authentification par certificat du client au lieu de password
openssl genrsa -out clients/local-tasmotas.key 2048
openssl req -new -subj "/C=BE/O=home/CN=MQTT-client-tasmotas" -key clients/local-tasmotas.key -out clients/local-tasmotas.csr
openssl x509 -req -in clients/local-tasmotas.csr -CA ca/ca.crt -CAkey ca/ca.key -CAcreateserial -out clients/local-tasmotas.crt -days 9999 -sha256

MQTTS côté broker Mosquitto

Les certificats et clés privées doivent être archivés, ils ne le sont pas dans le backup Jeedom.

La configuration de base du fichier Debian est : /etc/mosquitto/mosquitto.conf

# Place your local configuration in /etc/mosquitto/conf.d/
#
# A full description of the configuration file is at
# /usr/share/doc/mosquitto/examples/mosquitto.conf.example

pid_file /var/run/mosquitto.pid

persistence true
persistence_location /var/lib/mosquitto/

log_dest file /var/log/mosquitto/mosquitto.log

include_dir /etc/mosquitto/conf.d

C’est conseillé d’utiliser un fichier dans conf.d : dans mon cas sous Jeedom avec l’installation du plugin jMQTT, le fichier suivant est créé et sera utilisé : /etc/mosquitto/conf.d/jMQTT.conf

Copie des fichiers nécessaires du broker sur le serveur Jeedom :

scp ca/ca.crt broker/mosquitto.crt broker/mosquitto.key jeedom:
ssh jeedom
sudo mv ca.crt mosquitto.crt mosquitto.key /etc/mosquitto/certs/
ls -l /etc/mosquitto/certs

Editer via l’interface web la configuration du fichier jMQTT.conf ou via vim /etc/mosquitto/conf.d/jMQTT.conf

• on laisse les connexions en clair du port 1883 provenant de localhost uniquement (127.0.0.1), plus d’accès en clair depuis l’extérieur (sert pour jeedom se connecter au broker Mosquitto)
• on active le port TLS 8883 sur toutes les interfaces

# jMQTT Mosquitto configuration file
listener 1883 127.0.0.1
allow_anonymous true

# jMQTTS
listener 8883 0.0.0.0
protocol mqtt
cafile /etc/mosquitto/certs/ca.crt
certfile /etc/mosquitto/certs/mosquitto.crt
keyfile /etc/mosquitto/certs/mosquitto.key

# Only allow clients with a valid certificat (false to only trus the broker and not the clients)
require_certificate true

Rédémarrez le service et vérifier que le port 8883 est ouvert pour tous et 1883 n’est plus accessible que par 127.0.0.1 :

sudo systemctl restart mosquitto.service
sudo ss -tlpn | egrep '(1883|8883)'
LISTEN    0         100                0.0.0.0:8883             0.0.0.0:*        users:(("mosquitto",pid=14185,fd=6))
LISTEN    0         100              127.0.0.1:1883             0.0.0.0:*        users:(("mosquitto",pid=14185,fd=5))

A ce moment là, le trafic entre nos clients et notre serveur est sécurisé. Mais n’importe quel client peut se connecter à notre serveur sans mot de passe!

Basé sur la documentation jMQTT officielle, d’autres informations et erreurs courantes sont disponibles sur ce blog.

Authentification

Mes clients étant des ESP32 qui disposent de Wifi ou mon pc avec MQTT explorer pour le debug, tout en local, une authentification par mot de passe est suffisante. Je distingue les clients IoT avec un seul mot de passe et mes 2 pc avec chacun un mot de passe différent.

Pour un serveur MQTTS publique, l’authentification des clients par certificat est recommandé

1. Créer les fichiers de mot de passe : mosquitto_passwd -c <password file> <username>
   sudo mosquitto_passwd -c /etc/mosquitto/distant.passwd tasmota
2. Configurer le broker avec la ligne : password_file <path to the configuration file>
3. Ajout d’un second utilisateur sudo mosquitto_passwd /etc/mosquitto/distant.passwd hp
4. Redémarrer : sudo systemctl restart mosquitto.service

Le fichier /etc/mosquitto/conf.d/jMQTT.conf

per_listener_settings true

# jMQTT Mosquitto configuration file
listener 1883 127.0.0.1
allow_anonymous true

# jMQTTS
listener 8883 0.0.0.0
protocol mqtt
cafile /etc/mosquitto/certs/ca.crt
certfile /etc/mosquitto/certs/mosquitto.crt
keyfile /etc/mosquitto/certs/mosquitto.key
allow_anonymous false
persistence false
require_certificate false
password_file /etc/mosquitto/distant.passwd

Si vous préférez utiliser un mot de passe pour Jeedom en local, selon si le plugin vous l’impose, vous pouvez le faire :

per_listener_settings true

# jMQTT Mosquitto configuration file
listener 1883 127.0.0.1
allow_anonymous false
persistence false
password_file /etc/mosquitto/local.passwd

# jMQTTS
listener 8883 0.0.0.0
protocol mqtt
cafile /etc/mosquitto/certs/ca.crt
certfile /etc/mosquitto/certs/mosquitto.crt
keyfile /etc/mosquitto/certs/mosquitto.key
allow_anonymous false
persistence false
require_certificate false
password_file /etc/mosquitto/distant.passwd

source

L’article MQTTS sécuriser Mosquitto MQTT est apparu en premier sur Mon linux.

Voici quelques bases d’explications, que vous pouvez compléter avec la documentation officielle du protocole.

architecture de communication de MQTT

Nous avons un broker, celui qui passe les messages.
Des clients Publisher vont envoyer des messages avec un nom appelé Topic
Des clients Subscriber vont recevoir des messages s’ils sont abonnés à ce Topic

architecture du protocole MQTT

C’est organisé en Topic / sujets

On peut faire un topic racine : toto
Et des sous topic :

• toto/test1/o1
• toto/test1/o2
• toto/test2/o1
• toto/test2/o2
• toto/test3

On peut souscrire à plusieurs Topic via toto/* ou toto/#
Il n’est pas possible de mettre # pour la racine

On peut s’inscrire à plusieurs sous Topic via le + : toto/+/o1

MQTT Broker

Le plus utilisé : Mosquitto. Il est open-source et simple de configuration.

Organisation des Topic Jeedom

Il faut vous organiser à l’avance pour l’arborescence des topic qui seront utilisé chez vous. Voici ce que j’ai organisé chez moi pour les niveaux :

1. mettre le protocole passerelle
2. mettre la pièce ou une référence à la pièce
3. mettre le device
4. mettre les topics du device

Cela permet par exemple de matcher tous les objets du bureau quelque soit son protocole!

• MQTT direct : ip/piece/device/xxx
  • si plusieurs composant pour un seul objet, mettre cet objet devant le device : ip/display-rdc/matrixled-temp/xxx et ip/display-rdc/matrixled-spotify/xxx par exemple
• modbus2mqtt : modbus/rdc/device/xxx
• zigbee2mqtt : zigbee/bureau/device/xxx
• zwaveJS : zwave/bureau/device/xxx

clients

• Windows : MQTT Explorer permet le MQTT en clair, en MQTTS avec certificat serveur uniquement ou avec la pair de certificat/clé client
• Android j’en cherche encore un bon pour le debug

L’article MQTT broker est apparu en premier sur Mon linux.

Il existe une version mineure LTS 3.28.66 supportée jusque juin 2023. Plus de version LTS après cela!

L’OS utilisé passant à Ubuntu 22.04, il faut déjà trouver un intermédiaire pour faire fonctionner la version actuelle et la mettre à jour. La version installée ne supporte uniquement que PHP 7.0.

Le but à atteindre étant d’utiliser la dernière version de l’application 6.1.8 et sa version PHP supportée 8.0.

Phases de migration LimeSurvey

1. Migrer en dernière version LTS 3.28.66 (support PHP 7.4 max)
2. Mise à jour de PHP 7.0 vers 7.4
3. Migrer vers 5.6.31 (supports PHP 7.2.5 to 8.0.x)
4. Migrer vers 6.1.8 (requires PHP 7.4.x or newer)
5. Mise à jour de PHP 7.4 vers 8.0

Pré-requis

1. On va devoir utiliser une sandbox docker ayant différentes versions de PHP pour faire la migration de l’application du à l’incompatibilité entre les version PHP de l’app et la nouvelle machine
2. On va ajouter un dépôt pour gérer les versions de PHP qui ne sont pas dans le dépôt ubuntu https://ppa.launchpadcontent.net/ondrej/php/ubuntu/ jammy main

Pour utiliser docker sous Windows, je vous réfère à mon article sur Docker Desktop.

Export/Import base de donnée LimeSurvey actuel

Export :

cd /var/www
sudo tar -czf /home/b/lime-prod.tgz limesurvey
sudo mysqldump --defaults-file=/etc/mysql/debian.cnf limesurveydb | gzip --to-stdout > /home/b/lime-prod.sql.gz

import :

scp new-srv:lime-prod.* ./
zcat lime-prod.sql.gz | sudo mysql lime
cd /data/www
sudo tar -xf /home/b/lime-prod.tgz
sudo chown -R www-data limesurvey/tmp limesurvey/upload limesurvey/application/config

Migrer LimeSurvey en dernière version LTS

Sur la sandbox docker, ajouter le support de PHP 7.0 et 7.4 via un dépôt supplémentaire.

La version Version 3.15 ne supportant pas php 7.4, il faut passer par le 7.0 pour mettre à jour vers la 3.28.66 et puis essayer de passer php en 7.4

Situation fonctionnelle

• Ajout du dépôt

sudo add-apt-repository ppa:ondrej/php

• ajout des paquets

sudo apt update
sudo apt install php7.0 php7.0-curl php7.0-mysql php7.0-mbstring php7.0-zip php7.0-gd php7.0-ldap php7.0-simplexml
sudo apt install php7.4 php7.4-curl  php7.4-mysql  php7.4-mbstring  php7.4-zip  php7.4-gd  php7.4-ldap  php7.4-simplexml

• Switch du PHP par défaut :

sudo update-alternatives --config php
There are 3 choices for the alternative php (providing /usr/bin/php).

  Selection    Path             Priority   Status
------------------------------------------------------------
* 0            /usr/bin/php8.1   81        auto mode
  1            /usr/bin/php7.0   70        manual mode
  2            /usr/bin/php7.4   74        manual mode
  3            /usr/bin/php8.1   81        manual mode

Press <enter> to keep the current choice[*], or type selection number: 1
update-alternatives: using /usr/bin/php7.0 to provide /usr/bin/php (php) in manual mode

• Vérifier : php -v
• Activer dans apache la version à utiliser, ici 7.0 d’abord:

sudo a2dismod php8.1
sudo a2enmod php7.0
sudo systemctl restart apache2

• Importer les fichiers tgz + db

zcat limesurvey.sql.gz | mysql lime
cd /data/www
tar -xf lime-prod.tgz

• changer les accès db dans application/config/config.php

Pour le debug limesurvey :
application/config/config.php
‘debug’=>2,

Migration de LimeSurvey 3.15.3 vers 3.28.66

Notes de migration anciennes version

cd
wget https://download.limesurvey.org/latest-3.x-LTS/limesurvey3.28.66+230719.zip
cur_version=3.15.3
cd /data/www
sudo mv limesurvey limesurvey-$cur_version
sudo unzip /home/b/limesurvey3.28.66+230719.zip
sudo cp limesurvey-$cur_version/application/config/config.php limesurvey/application/config/
sudo cp -ar limesurvey-$cur_version/upload limesurvey/
sudo chown -R www-data limesurvey/tmp limesurvey/upload limesurvey/application/config

Upgrade DB en console :

sudo -u www-data php limesurvey/application/commands/console.php updatedb
Update mysql:host=localhost;port=3306;dbname=lime_stag; with prefix :lime_ from 355 to 366
Database has been successfully upgraded to version 366

Après connexion à l’interface admin, pas de message pour upgrade la DB. Et vérifier si erreur template.

==> Etat OK, customisation logo, templates formulaire également.

Switch de PHP 7.0 vers PHP 7.4

Pour les versions suivantes, la version minimum est PHP 7.2.5 et il faut donc abandonné PHP7.0. Allons directement en 7.4 qui est censé être supporté par la version 3.28.66….

sudo update-alternatives --config php
There are 3 choices for the alternative php (providing /usr/bin/php).

  Selection    Path             Priority   Status
------------------------------------------------------------
  0            /usr/bin/php8.1   81        auto mode
* 1            /usr/bin/php7.0   70        manual mode
  2            /usr/bin/php7.4   74        manual mode
  3            /usr/bin/php8.1   81        manual mode

Press <enter> to keep the current choice[*], or type selection number: 2
update-alternatives: using /usr/bin/php7.4 to provide /usr/bin/php (php) in manual mode
Time: 0h:00m:03s
php -v
sudo a2dismod php7.0
sudo a2enmod php7.4
sudo systemctl restart apache2

==> Etat OK également!

Migrer LimeSurvey vers 5.6.31

Cette version 5.6.31 supporte PHP 7.2.5 à 8.0.x.

cd
wget https://download.limesurvey.org/latest-5.x/limesurvey5.6.31+230718.zip
cur_version=3.28.66
sudo mysqldump lime | gzip --to-stdout > lime-${cur_version}.sql.gz
cd /data/www
sudo mv limesurvey limesurvey-$cur_version
sudo unzip /home/b/limesurvey5.6.31+230718.zip
sudo cp limesurvey-$cur_version/application/config/config.php limesurvey/application/config/
sudo cp -ar limesurvey-$cur_version/upload limesurvey/
sudo chown -R www-data limesurvey/tmp limesurvey/upload limesurvey/application/config

On est à la version 366 de la base de données pour rappel.

Update en console possible :

sudo -u www-data php limesurvey/application/commands/console.php updatedb
Update mysql:host=localhost;port=3306;dbname=lime; with prefix :lime_ from 366 to 497
Database has been successfully upgraded to version 497
Time: 0h:00m:18s

Si erreur pour faire l’update entre 418 et 497, voir si bien en php 7.4 et recommencer depuis la 3.28.66. Un oubli arrive vite…

Migrer LimeSurvey vers 6.1.8

Cette version 6.1.8 de Limesurvey nécessite PHP 7.4.x ou plus.

Upgrade 5.6.31 vers 6.1.8

Attention l’interface est très différente, à voir l’impacte sur les utilisateurs de l’application !

cd
wget https://download.limesurvey.org/latest-master/limesurvey6.1.8+230717.zip
cur_version=5.6.31
sudo mysqldump lime | gzip --to-stdout > lime-${cur_version}.sql.gz
cd /data/www
sudo mv limesurvey limesurvey-$cur_version
sudo unzip /home/b/limesurvey6.1.8+230717.zip
sudo cp limesurvey-$cur_version/application/config/config.php limesurvey-$cur_version/application/config/security.php limesurvey/application/config/
sudo cp -ar limesurvey-$cur_version/upload limesurvey/
sudo chown -R www-data limesurvey/tmp limesurvey/upload limesurvey/application/config

On est à la version 497 de la base de données

Update en console possible :

sudo -u www-data php limesurvey/application/commands/console.php updatedb
Update mysql:host=localhost;port=3306;dbname=lime; with prefix :lime_ from 497 to 607
Database has been successfully upgraded to version 607
Time: 0h:00m:04s

Switch de PHP 7.4 vers PHP 8.0

Pour les versions suivantes de LimeSurvey, la version minimum est PHP 7.4.x. Pas d’infos officielles sur la version maximal, mais un information sur le forum :

8.1 and 8.2 are not supported, yet.
The maximum PHP version currently supported by LimeSurvey 5 is 8.0.x.

Il faut donc tester… Résultat des tests :

• PHP 7.4 est OK
• PHP 8.0 est OK
• PHP 8.1 ne semble pas supporté!!!
• PHP 8.2 non testé

Il faut donc utiliser PHP 8.0.

Installer :

sudo apt install php8.0 php8.0-curl  php8.0-mysql  php8.0-mbstring  php8.0-zip  php8.0-gd  php8.0-ldap  php8.0-simplexml
sudo a2dismod php7.4
sudo a2enmod php8.0
sudo systemctl restart apache2

sudo update-alternatives --config php
There are 4 choices for the alternative php (providing /usr/bin/php).

  Selection    Path             Priority   Status
------------------------------------------------------------
  0            /usr/bin/php8.1   81        auto mode
  1            /usr/bin/php7.0   70        manual mode
* 2            /usr/bin/php7.4   74        manual mode
  3            /usr/bin/php8.0   80        manual mode
  4            /usr/bin/php8.1   81        manual mode

Press <enter> to keep the current choice[*], or type selection number: 3
update-alternatives: using /usr/bin/php8.0 to provide /usr/bin/php (php) in manual mode
php -v

Conclusion

La tâche n’était pas simple sans avoir une manipulation officielle d’un changement de version application + PHP. Il faut donc faire quelques raté pour en arriver à cette manipulation. Espérant aider le plus grand nombre!

L’article LimeSurvey migration 3.15 vers 6.1.8 est apparu en premier sur Mon linux.

Systemd va pouvoir avoirune dépendance au réseau par exemple, pour monter le CIFS uniquement si la daemon réseau a bien été démarré. Le système pourra booter en level 3 même si le CIFS n’est pas joignable!

Le fichier systemd à placer dans /etc/systemd/system/

[Unit]
  Description=cifs mount script
  Requires=network-online.target
  After=network-online.service

[Mount]
  What=//192.168.56.1/mp$
  Where=/mnt/mp
  #Options=username=yourCifsUser,password=Secretpassword,workgroup=YourDomain,rw
  Options=credentials=/etc/systemd.cred.MonNas
  Type=cifs

[Install]
  WantedBy=multi-user.target

Je conseille d’utiliser le format avec un fichier de credentials qui aura des droits stricts 600 pour que seul root y accède. Laissant notre fichier systemd lisible.

• network-online permet d’attendre que la ressource réseau soit accessible avant de tenter le montage
• What est notre ressource distante
• where est notre point de montage local
• Options permet de définir les options, voir man mount.cifs
• Type est cifs dans ce cas-ci
• multi-user est le niveau 3 de démarrage, un classique

Le fichier credentials

username=MonUser
password=MonPass
domain=domain.tld

Nommage du fichier de configuration

Pour choisir un nom de fichier, attention que systemd est capricieux, il faut échapper pour être certain. Pour un répertoire, une option -p est prévue ainsi que --suffix.
Préféré un nom de point de montage avec des underscores plutôt que des tirets pour une meilleure lisibilité :

~$ systemd-escape -p --suffix=mount "/data/MON-DUMP-DB"
data-MON\x2dDUMP\x2dDB.mount
~$ systemd-escape -p --suffix=mount "/data/MON_DUMP_DB"
data-MON_DUMP_DB.mount

On relance et on active systemd :

sudo systemctl daemon-reload
sudo systemctl enable mnt-dp.mount
sudo systemctl start mnt-dp.mount

Quelques infos avec une variante pour un démontage après un temps d’inutilisation via automount.

Personnellement j’utilise ce montage pour faire les dump DB MySQL et mariaDB sur un NAS, afin de ne pas faire un backup d’une vm contenant elle-même des backups…

L’article Systemd – point de montage CIFS est apparu en premier sur Mon linux.

Installation du rôle Ansible Automysqlbackup

Pour installer ce rôle de configuration sous Debian ou Ubuntu rien de plus simple :

ansible-galaxy install belgotux.automysqlbackup

Pré-requis

Il est préférable de créer un utilisateur spécifique pour automysqlbackup sur chaque serveur devant être sauvegardé. Pour cela les droits suivants sont nécessaire :

CREATE USER 'automysqlbackup'@'serverA' IDENTIFIED BY  '<your_password_secret>';
GRANT SELECT, LOCK TABLES, SHOW VIEW, EVENT, TRIGGER,USAGE ON *.* TO 'automysqlbackup'@'serverA' ;

Pour utiliser le rôle Ansible Automysqlbackup en local, les droits suivants :

CREATE USER 'automysqlbackup'@'localhost' IDENTIFIED BY  '<your_password_secret>';
GRANT SELECT, LOCK TABLES, SHOW VIEW, EVENT, TRIGGER,USAGE ON *.* TO 'automysqlbackup'@'localhost' ;

Configuration des variables Ansible

Nécessaires

Configuration du serveur :

• automysqlbackup_repo répertoire où déposer le projet git (défaut /opt)
• automysqlbackup_client binaire sql client à utiliser, soit mariadb-client ou mysql-client (défaut mariadb-client)
• automysqlbackup_bin répertoire où copier le script (défaut /usr/local/bin)
• automysqlbackup_conf répertoire des configurations (défaut /etc/automysqlbackup)
• automysqlbackup_backupdir répertoire des sauvegardes

Configuration du client SQL

• automysqlbackup_default_user utilisateur MySQL utilisé par défaut pour les serveurs (défaut automysqlbackup)
• automysqlbackup_default_passwd mot de passe MySQL utilisé par défaut pour les serveurs
• automysqlbackup_configurations liste des serveurs à sauvegarder. Prend la valeur de automysqlbackup_default_user, automysqlbackup_default_passwd, etc si user, passwd, etc n’est pas défini

automysqlbackup_configurations:
- name: server1
  server: xxx.yourdomain.tld
  port: 3306            # default use 3306
  user: test            # default use `automysqlbackup_default_user`
  passwd: testpwd       # default use `automysqlbackup_default_passwd`
  cron: "0 23 * * *"    # default use `automysqlbackup_default_cron`
  montly: 01            # default use `automysqlbackup_monthly`
  weekly: 5             # default use `automysqlbackup_weekly`
  daily_to_keep: 5      # default use `automysqlbackup_daily_to_keep`
  weekly_to_keep: 4     # default use `automysqlbackup_weekly_to_keep`
  monthly_to_keep: 3    # default use `automysqlbackup_monthly_to_keep`
- name: server2
  server: 192.168.x.x

• automysqlbackup_default_db_exclude liste des bases de données exclues par défaut si la variable db_names n’est pas remplie sur la configuration serveur (défaut « ('information_schema' 'performance_schema' 'sys' )« )
• automysqlbackup_default_table_exclude liste des tables à exclure au format db_name.table_name (défaut « ('mysql.event')« )
• automysqlbackup_default_cron défini le cron par défaut à utiliser pour tous les serveurs, exemple "0 23 * * *"
• automysqlbackup_create_user utilisateur système à créer par le rôle, true or false ? Crée automysqlbackup_default_cron_user (défaut true)

Facultatif

Server configuration

• automysqlbackup_multicore utilisation de compression multicore pigz pour gzip ou pbzip2 pour bzip2. Peut être 'yes' ou 'no' (défaut 'no')
• automysqlbackup_multicore_threads nombre de cpu à utiliser. Peut être un nombre ou auto pour laisser pigz ou pbzip2 choisir (défaut auto)
• automysqlbackup_default_cron_user utilisateur à utiliser pour exécuter le cron (default automysqlbackup)
• automysqlbackup_default_cron_group groupe à utiliser pour le dossier de backup (défaut users)
• automysqlbackup_default_cron_path répertoire cron (défaut /etc/cron.d)

SQL client configuration

• automysqlbackup_monthly quelle jour faire le backup mensuel ? (01 à 31) mettre 0 pour désactivé le backup mensuel (défaut 01)
• automysqlbackup_weekly uelle jour faire le backup hebdomadaire ? (1 à 7 ou 1 est lundi) mettre 0 pour désactivé le backup hebdomadaire (défaut 5)
• automysqlbackup_daily_to_keep combien de backups journaliers à garder (défaut 6)
• automysqlbackup_weekly_to_keep combien de backups hebdomadaires à garder (défaut 28)
• automysqlbackup_monthly_to_keep combien de backups mensuels à garder (défaut 180)
• automysqlbackup_no_tablespaces le droits sql PROCESS est nécessaire depuis MySQL 5.7.31 et 8.0.21, l’option –no-tablespaces permet d’éviter d’avoir l’erreur. Peut être 'yes' ou 'no' (défaut 'yes')
• automysqlbackup_dump_usessl Utiliser le chiffrement SSL avec mysqldump ? Peut être 'yes' ou 'no' (défaut 'no')
• automysqlbackup_dump_single_transaction Lors de l’utilisation de cette option, il est important de noter que seules les tables InnoDB sont sauvegardées dans un état cohérent. Par exemple, toutes les tables MyISAM ou MEMORY sauvegardées lors de l’utilisation de cette option peuvent encore changer d’état. Peut être 'yes' ou 'no' (défaut 'no')
• automysqlbackup_dump_dbstatus Statut de sauvegarde de table(s) dans un fichier texte. Cela est très utile lors de la restauration des sauvegardes, car cela donne une idée des changements survenus entre-temps. Peut être 'yes' ou 'no' (défaut 'no')
• automysqlbackup_dump_create_database Inclure la commande CREATE DATABASE dans le backup. Peut être 'yes' ou 'no' (défaut 'no')
• automysqlbackup_dump_use_separate_dirs séparer le répertoire de backup pour chaque base de données. Peut être 'yes' ou 'no' (défaut 'yes')
• automysqlbackup_dump_compression choisir une compression du type gzip or bzip2 (défaut gzip)
• automysqlbackup_dump_latest Stocker une copie supplémentaire (lien physique) de la dernière sauvegarde dans un emplacement standard afin qu’elle puisse être téléchargée par des scripts tiers. Peut être 'yes' ou 'no' (défaut 'yes')
• automysqlbackup_dump_latest_clean_filenames Supprimer toutes les informations de date et d’heure des noms de fichiers dans le dossier le plus récent. (défaut yes)
• automysqlbackup_mailcontent Que souhaitez-vous recevoir par courrier électronique : log (envoi les log), files (envoie les logs et fichiers sql en attaché), stdout (affiche les log dans la sortie standard utile pour l’exécution manuelle), quiet (envoie les log uniquement si une erreur apparait) (défaut log)
• automysqlbackup_mail_address addresse mail du destinataire
• automysqlbackup_dryrun Simulation de ce qui sera fait, ne fait rien en réalité. 0 mode inactif, 1 mode actif (défaut 0)

L’article Rôle Ansible Automysqlbackup est apparu en premier sur Mon linux.

Si vous essayé d’utiliser les variables d’environnement https_proxy=socks5://votreserver:port vous aurez l’erreur suivante :

InvalidSchema: Missing dependencies for SOCKS support.

La solution est de télécharger les dépendances nécessaires sur une machine ayant l’accès à Internet!

Dépendances pip sur la machine ayant le net :

mkdir pipdep && cd pipdep
echo pysocks > requirements.txt
echo pyvmomi >> requirements.txt
pip download -r requirements.txt

Vous copier le dossier sur la machine cible

Installation des dépendances python pip sur la machine cible

C’est à exécuter en temps d’utilisateur pour rappel :

pip install -r requirements.txt --no-index --find-links .

Le gist est disponible sur Github

L’article Python pip installation offline de librairies est apparu en premier sur Mon linux.

Pour utiliser Nmap pour identifier l’OS Windows, vous pouvez utiliser la commande suivante :

nmap -O [IP_ADDRESS]

Pour l’identification plus poussée via le protocole SMB :

export NMAPDIR=.
mkdir scripts

wget http://nmap.org/svn/scripts/smb-os-discovery.nse

nmap --script smb-os-discovery.nse -p445 127.0.0.1

nmap -sU -sS --script smb-os-discovery.nse -p U:137,T:139 127.0.0.1

Nmap scan report for 10.xx.xx.xx
Host is up (0.00020s latency).
PORT    STATE SERVICE
445/tcp open  microsoft-ds
MAC Address: F8:BC:xx:xx:xx:xx (Unknown)
Host script results:
| smb-os-discovery:
|   OS: Windows 7 Professional 7601 Service Pack 1 (Windows 7 Professional 6.1)
|   NetBIOS computer name: IHATEWINDOWS
|   Workgroup: WORKGROUP
|_  System time: 2015-03-20 22:55:05 UTC+1

Nmap done: 1 IP address (1 host up) scanned in 0.49 seconds

La librairie se trouve ici : smb-os-discovery NSE Script.

Ce ne sera que les windows répondant à SMB.

Et la version qui essaye d’authentifier l’OS comme précédemment + les hotes en samba (plus fouillis mais au moins on prouve que c’est du matos switch, linux, vmware, etc)

nmap --script smb-os-discovery.nse -O -p445 10.102.69.0/22 --exclude 10.102.69.107 > scan-$(date '+%d-%m-%Y-%H-%M.txt')

Disponible en version graphique avec zenmap.

L’article NMAP – identification exacte de l’OS d’un Windows est apparu en premier sur Mon linux.

Utilisation simple d’un Ansible proxy socks

Pour expliquer l’utilisation de proxy avec Ansible, il faut d’abord comprendre la base : créer un proxy socks depuis une machine sans internet en zone restreinte vers une machine ayant internet en ssh. Pour ma part, je préfère ouvrir ssh dans un screen pour laisser un visu et fermer la connexion par la suite. Il est possible d’utiliser l’argument ssh permettant créer la connexion en arrière plan.

Sur notre serveur sans internet :

~$ ssh -4 -D 8888 mon_serveur_avec_internet
~$ curl -m 5 perdu.com
curl: (28) Failed to connect to perdu.com port 80 after 3852 ms: Connection timed out
~$ export ALL_PROXY="socks5://localhost:8888"
~$ curl -m 5 perdu.com
<html><head><title>Vous Etes Perdu ?</title></head><body><h1>Perdu sur l'Internet ?</h1><h2>Pas de panique, on va vous aider</h2><strong><pre>    * <----- vous &ecirc;tes ici</pre></strong></body></html>
~$ export ALL_PROXY=

On a donc bien accès à internet depuis notre machine.

Il arrive parfois que vous n’ayez même pas un serveur sur qui rebondir… A ce moment là il est possible d’utiliser votre propre machine comme passerelle! Pour cela il faut faire 2 choses :

• Depuis votre pc, vous créez avec ssh un bind de port reverse sur votre propre machine en vous connectant sur la machine n’ayant pas accès à internet :

~$ ssh -R 2222:127.0.0.1:22 serveur_sans_internet

• La console vers le serveur sans internet s’ouvre
• Vous créez le port dynamique pour le socks sur le port local 2222 du serveur (qui va rediriger vers le ssh de votre pc

~$ ssh -4 -D 8888 -p 2222 127.0.0.1

• Vous ouvrez un second terminal pour vous connecter directement au serveur et vous avez accès au net

~$ export ALL_PROXY="socks5://localhost:8888"
~$ curl -m 5 perdu.com
<html><head><title>Vous Etes Perdu ?</title></head><body><h1>Perdu sur l'Internet ?</h1><h2>Pas de panique, on va vous aider</h2><strong><pre>    * <----- vous &ecirc;tes ici</pre></strong></body></html>

Ansible et proxy ssh socks

Variable d’environnement du role Ansible

Dans un playbook, nous pouvons ajouter directement une directive environment qui sera utilisée sur un role ou une tasks. Exemple dans un playbook automysqlbackup :

- name: Automysqlbackup Installation
  hosts: databases_dump_server

  roles:
    - role: roles/database/belgotux.automysqlbackup
      environment:
        all_proxy: "socks5://localhost:8888"

Cela va faire l’équivalent de l’export vu plus haut : export ALL_PROXY="socks5://localhost:8888"

Pour en savoir plus sur le rôle Ansible Automysqlbackup.

Utilisation plus générique et facultative sur un playbook existant

On peut utiliser une variable proxy qui sera utilisée dans les variables de l’hôte ou du groupe si besoin d’utiliser un proxy. Avec l’option default pour ne pas que notre playbook soit inutilisable sur un serveur n’ayant pas besoin de proxy…

playbook.yml :

- name: Automysqlbackup Installation
  hosts: databases_dump_server

  roles:
    - role: roles/database/belgotux.automysqlbackup
      environment:
        all_proxy: "{{ proxy | default('')}}"

hote.yml :

proxy: "socks5://localhost:8888"

L’article Ansible proxy avec machine sans internet est apparu en premier sur Mon linux.

L’utilisation est presque la même, hormis l’utilisation préférable d’un fichier my.cnf pour ne plus avoir les identifiants MySQL dans la ligne de commande… Le mot de passe est stocké dans un fichier à devoir remplir dans la variable CONFIG_mysql_mycnf_file .

D’autres bugfix ont été réglés pour des arguments actuellement dépréciés –ssl, ainsi que des problèmes lié à un accès refusé pour les tablespaces.

Pour ceux qui ne connaissent pas, AutoMySQLBackup permet un fonctionnement en mode whitelist ou blacklist des bases de données à sauvegarder. Souvent, on va lui dire que tout sauvegarder sauf information_schema, performance_schema, sys. C’est donc une sauvegarde MySQL automatique ! Et toute nouvelle base de données ajoutée sur le serveur mutualisé sera automatiquement sauvegardée ! Il permet de gérer une rétention différente pour les backups journaliers, hebdomadaires ou mensuels.

Installation d’AutoMySQLBackup

Voici les étapes d’installation :

• Pré-requis de bonne pratique, créer un utilisateur dédié au dump MySQL pour AutoMySQLBackup

CREATE USER 'automysqlbackup'@'localhost' IDENTIFIED BY  '<MOT_DE_PASSE>';
GRANT SELECT, LOCK TABLES, SHOW VIEW, EVENT, TRIGGER,USAGE ON *.* TO 'automysqlbackup'@'localhost' ;

• Copier le répertoire git OU directement le dernière version de l’archive

git clone https://github.com/belgotux/automysqlbackup.git
wget https://github.com/belgotux/automysqlbackup/archive/refs/heads/main.zip && unzip main.zip

• Installer le script et les fichiers de configuration

sudo bash install.sh

• Créer le fichier contenant les identifiants de connexion /etc/automysqlbackup/votre-server.cnf

[mysqldump]
user=automysqlbackup
password=""
[mysql]
user=automysqlbackup
password=""
[mysqlshow]
user=automysqlbackup
password=""

• Créer le fichier de configuration /etc/automysqlbackup/votre-server.conf en vous basant sur le template. Les points importants sont :

CONFIG_mysql_mycnf_file='/etc/automysqlbackup/votre-server.cnf'
CONFIG_mysql_dump_host='localhost'
CONFIG_backup_dir='/backup/db'
CONFIG_db_names=()  # laisser vide pour sauvegarder toutes les bases de données
CONFIG_db_month_names=() # idem
CONFIG_db_exclude=( 'information_schema' 'performance_schema' 'sys' ) # exclus ces bases
CONFIG_table_exclude=('mysql.event') # exclus cette table
CONFIG_do_monthly="01"
CONFIG_do_weekly="6"
CONFIG_rotation_daily=7
CONFIG_rotation_weekly=4
CONFIG_rotation_monthly=180
CONFIG_mysql_no_tablespaces='yes'
CONFIG_mysql_dump_use_separate_dirs='yes'
CONFIG_mysql_dump_compression='gzip'
CONFIG_mysql_dump_latest='yes'
CONFIG_mysql_dump_latest_clean_filenames='no'
CONFIG_mailcontent='quiet'
CONFIG_mail_address='root'

• Créer le cron /etc/cron.d/automysqlbackup

0 21 * * *       root    /usr/local/bin/automysqlbackup /etc/automysqlbackup/votre-server.conf > /dev/null

• Tester manuellement une première fois pour vérifier la création des dossiers daily/weekly/monthly

/usr/local/bin/automysqlbackup /etc/automysqlbackup/votre-server.conf

Voilà, vos sauvegardes MySQL sont maintenant automatisées, vous recevez un mail en cas de problème du script!

Si vous utilisez une architecture MySQL master-slave, je vous conseille de le faire sur le slave, afin de ne pas faire durer un lock table sur le master. Une désynchronisation du slave est préférable, voir un slave dédié si vous ne pouvez vous permettre une désynchro de quelques secondes

L’article AutoMySQLBackup – sauvegarde MySQL est apparu en premier sur Mon linux.

L’utilisation d’un relais tel que Microsoft 365 facilite la sécurisation de nos échanges mails, car une intégration de DKIM et DMARC est déjà gérée nativement! Si vous avez déjà vos mails ou l’ensemble de votre active directory, c’est dans cette direction qu’il faut se diriger pour une mise en place efficace.

Je suppose qu’il est possible de faire cela également avec Infomaniak pour ceux disposant de comptes pro chez eux. Avec mon compte perso je n’ai pas vu cette option. Avec OVH, oubliez directement! Du temps où j’étais encore client chez eux, j’avais parlé DKIM DMARC au support, et on m’a posés des questions pour savoir pourquoi je veux ces fonctions etc. Vraiment comme si j’étais un extraterrestre! On était tout de même en 2020… Rien n’était fait pour le mail mutualisé donc… Longtemps client perso et pro je suis passé chez Infomaniak pour la partie mutualisée en partie pour cela. J’arrête le OFF là

Configuration dans l’Exchange 365

Il faut créer un connector dans mail flow > connectors > Add a connector :

L’authentification est faite par adresse IP ou certificat valide. Il faut savoir que votre serveur relais interne postfix va lui-même se connecter sur VOTRE_DNS.mail.protection.outlook.com et celui-ci présente un certificat valide. Votre « client » va donc authentifier le serveur de Microsoft comme valide (notre serveur relais est client par rapport au relais M365).

L’authentification par IP est déjà suffisante en soit. Mais vous pouvez décider que les serveurs relais de Microsoft n’acceptent QUE les mails si le serveur client (votre relais SMTP) présente le bon certificat client. Ce qui fait qu’il y a une identification et authentification de part et d’autre!

• Configurer une restriction par votre IP publique de sortie :

• Configurer une restriction par un certificat valide : dans ce cas cela ne doit pas forcément être le certificat *.votredomain.tld, cela peut très bien être monrelais.mondomainetechnique.tld. La seule règle étant que ce certificat soit émis par une autorité de certification reconnue.

Mettre un certbot avec let’s encrypt sur votre serveur est envisageable si vous utilisez une vérification let’s encrypt par dns.

Si vous souhaitez plus d’infos, la documentation Microsoft est bien faite.

Remarque : Les limites d’envoie pour M365 sont larges et dépendent de votre licence.

Un mot sur le serveur Postfix

Il faut tout de suite savoir que Postfix est à la fois un serveur et un client. Il faut donc bien distinguer les directives. Veillez donc bien au début qui peut être :

• smtp_tls_xxx en tant que client
• smtpd_tls_xxx en tant que serveur

Notre serveur relais est serveur par rapport à nos serveurs internes. Il est client par rapport à Microsoft 365.

Configuration de notre relais mail Postfix

J’ai distingué les directives serveurs et clients pour que la configuration soit lisible.

Pour le comportement serveur du relais SMTP :

• smtpd_tls_security_level=may permet de spécifier que notre serveur accepte une liaison client en TLS mais également en clair. Il faut penser aux copieurs ou autre matériel ne gérant pas le TLS interne à notre réseau
• smtpd_tls_loglevel permet d’avoir une trace des connexions TLS dans les logs avec les ciphers pris en compte, pratique pour voir quel client envoie encore en clair et s’il peut être modifié
• smtpd_tls_cert_file et smtpd_tls_key_file renseignent le certificat et la clé utilisé en interne
• smtpd_tls_chain_files est le nouveau format pour pouvoir contenir plusieurs clés et certificats pour différents noms de domaine. Il faut toujours la clé et puis la chaîne de certificat et le certificat final
• smtpd_tls_session_cache_database permet d’avoir un peu de performance quand beaucoup de mails sont envoyés

### SERVER ###
smtpd_tls_security_level=may
smtpd_tls_loglevel = 1

smtpd_tls_cert_file=/etc/xxx.crt
smtpd_tls_key_file=/etc/xxx.key
#alternative
#smtpd_tls_chain_files=/etc/your-key-and-local-crt-and-chain-with-your-local-ca-combined.all

#optionel
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache



### CLIENT ###
relayhost = your-domain.mail.protection.outlook.com
smtp_tls_security_level = encrypt # optionnel : secure
smtp_tls_mandatory_ciphers = high
smtp_tls_loglevel = 1
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
#optionnel
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_tls_chain_files = /etc/xxx.all

Pour le comportement client du relais SMTP :

• relayhost on vient mettre le DNS de notre tenant M365
• smtp_tls_security_level le niveau de securité minimal accepté en TLS. Je vous conseille secure
• smtp_tls_mandatory_ciphers high contient un « bundle » de ciphers satisfaisant
• smtp_tls_loglevel permet d’avoir une trace des connexions TLS
• smtp_tls_CAfile permet de spécifié le fichier des CA faisant autorité. Un fichier du système contient déjà les CA connus du monde
• smtp_tls_session_cache_database permet d’avoir un peu de performance quand beaucoup de mails sont envoyés
• smtp_tls_chain_files spécifiez la chaine de certificats client qui est utiliser si vous aviez choisi une restriction par un certificat client pour votre connector M365. L’ordre dans la chaine est importante : votre clé privée, suivie de votre certificat, ensuite le certificat intermédiaire et pour finir le certificat du CA

host xxx.mail.protection.outlook.com[104.47.2.7] said: 550 5.4.1 Recipient address rejected: Access denied. AS(201776281) [AB4EUR01RT057.eop-EUR01.prod.protection.outlook.com] (in reply to RCPT TO command)

postfix/smtp[71318]: your-domain.mail.protection.outlook.com[104.47.0.36]:25: matched peername: *.mail.protection.outlook.com
postfix/smtp[71318]: your-domain.mail.protection.outlook.com[104.47.0.36]:25: subject_CN=mail.protection.outlook.com, issuer_CN=DigiCert Cloud Services CA-1, fingerprint=6A:DD:32:6D:2A:0C:C5:3A:9E:D7:E7:91:3D:6F:5C:F4, pkey_fingerprint=20:78:41:CD:EC:4F:19:7A:E0:B2:01:4F:3C:3D:1C:EE
postfix/smtp[71318]: Verified TLS connection established to your-domain.mail.protection.outlook.com[104.47.0.36]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

Fichier main.cf d’un relais SMTP Postfix complet :

myorigin = /etc/hostname
mydomain = your-local-domain
mydestination = $myhostname, $myorigin, localhost.localdomain, localhost, localhost.your-local-domain

# Backward compatibility off
compatibility_level = 3.6
relay_domains = $mydestination
append_dot_mydomain = yes
smtputf8_enable=yes
smtpd_banner = $myhostname ESMTP
biff = no
readme_directory = no

# TLS parameters server
smtpd_tls_chain_files=/etc/your-key-and-local-crt-and-chain-with-your-local-ca-combined.all
#alternative
#smtpd_tls_cert_file=/etc/xxx.cer
#smtpd_tls_key_file=/etc/xxx.key
smtpd_tls_security_level=may
smtpd_tls_loglevel = 1
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache

# TLS parameters client
relayhost = xxx.mail.protection.outlook.com
smtp_tls_security_level = secure
smtp_tls_mandatory_ciphers = high
smtp_tls_loglevel = 1
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

# Client certificat to be identified by M365
#smtp_tls_chain_files = /etc/xxx.all

smtpd_client_restrictions = permit_mynetworks reject
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination

alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases

mynetworks = 10.0.0.0/22,xxx
mailbox_size_limit = 0
message_size_limit = 29480000
recipient_delimiter = +
inet_interfaces = all
inet_protocols = ipv4

header_checks = regexp:/etc/postfix/header_checks_regexp
smtp_header_checks = regexp:/etc/postfix/replace_header_checks_regexp

sender_canonical_maps = regexp:/etc/postfix/sender_canonical_regexp

Configuration d’un serveur client interne linux

Voici la partie TLS d’un fichier main.cf d’un postfix « satellite » qui se connecte à notre relais interne. Il dois évidement avoir le certificat serveur de notre relais ou notre CA interne de configuré dans les certificats du système ou via la directive smtp_tls_CAfile.

smtp_tls_security_level = may
smtp_tls_loglevel = 1
#optionnel
smtp_tls_security_level = secure
smtp_tls_mandatory_ciphers = high
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

L’article Relais mail Postfix – envoyer ses mails sécurisés vers M365 est apparu en premier sur Mon linux.