Catégorie : Configuration

Déploiement d’un routeur R7000 supplémentaire sous FreshTomato

Ca y est, le domicile parentale est enfin équipé en fibre optique, en remplacement d’une connexion Adsl vieillissante. Si la qualité et la stabilité du signal s’est donc grandement améliorée, l’organisation physique du réseau a quelque peu changée. La box fibre du fournisseur d’accès se retrouve à la cave, avec l’impact que vous devinez sur la couverture du signal WiFi.

Pour palier au problème, et plutôt que de souscrire à une option de répétiteur WiFi facturée mensuellement, je me suis procuré un routeur R7000 d’occasion. Comme d’habitude, plutôt que de rester sur le firmware Netgear, j’ai immédiatement procédé à l’installation de FreshTomato, pour disposer d’un système bien plus à jour et de nombreuses fonctionnalités supplémentaires, en particulier: des règles de filtrage DNS directement au niveau du routeur.

Sans rentrer dans les détails, la procédure d’installation tient en quelques étapes:

Principales difficultés dans l’opération: ne pas oublier qu’il faut commencer par installer l’image initial et ensuite, trouver ou retrouver les couples utilisateur/mot de passe à utiliser pour chaque image. Ce qui nous donne:

  • initial: admin/@newdig ou root/admin
  • AIO: root/admin

Et pour de plus amples détails, direction la documentation en anglais: Installing FreshTomato.

Test d’un role Ansible

Après avoir réorganisé l’ensemble de mes rôles Ansible, j’avais en tête de trouver un moyen de tester leur exécution dans un environnement vierge. L’idée n’est pas nouvelle. Le but : vérifier l’exécution du rôle plus facilement, c’est-à-dire, sans savoir à installer une nouvelle VM, ou à louer un serveur à cette occasion, même si cette dernière solution est, par expérience : pratique, assez rapide à mettre en œuvre et d’un faible coût en utilisant un serveur facturé à l’heure.

Ayant parcouru quelques dépôts de rôle Ansible présent sur Ansible Galaxy et ayant sauvegardé quelques articles évoquant le sujet, j’avais donc une idée des outils disponibles et des exemples fonctionnels. Il ne restait plus qu’à se retrousser les manches, et à tenter l’implémentation sur l’un de mes rôles les plus simples consistant à installer fail2ban.

Installation

Première étape avant configuration, l’installation des outils qui permettront de tester le rôle en exécutant une seule commande, à savoir : Molecule et virtualenv. Avec python3 installé, je commence donc par installer virtualenv via: pip install virtualenv. J’initialise ensuite un environnement virtuel python avec virtualenv dans le dossier contenant mon rôle ansible, soit les commandes :

$ pip3 install virtualenv
$ virtualenv -p python3 .venv
$ source .venv/bin/activate

Étape suivante, l’installation de molecule via pip.

$ pip3 install --upgrade setuptools
$ pip3 install 'molecule[ansible,docker,lint]'

Configuration basique

Maintenant que les outils sont installés, je génère la configuration de base avec la commande: molecule init scenario. Cette commande a pour effet de créer quatre fichiers.

  • INSTALL.rst : contient des instructions pour l’installation d’autres dépendances, ou des étapes de configuration à réaliser. Dans mon cas, installation de molecule[docker], que j’ai donc directement intégré dans la commande citée précédemment.
  • molecule.yml : fichier principal décrivant les outils utilisés pour le test.
  • converge.yml : le playbook ansible chargé de déployer le rôle testé.
  • verify.yml : un fichier ansible permettant de décrire les vérifications à effectuer après déploiement du rôle.

Comme j’utilise docker pour la gestion de l’instance de test, je suis les préconisations de la documentation pour vérifier que docker fonctionne correctement.

$ docker run hello-world

Une fois l’environnement prêt, je peux passer à l’exécution du test.

$ molecule test

En théorie, ce premier test devrait au minimum réussir jusqu’à l’étape de vérification, en fonction des modifications effectuées dans verify.yml. En cas d’erreur, je trouve très utile d’exécuter manuellement les différentes étapes de molecule test. A savoir:

  1. molecule create : Création de l’instance.
  2. molecule converge: Déploiement du rôle.
  3. molecule login : Connexion à l’instance pour aller explorer son état, très pratique en cas d’erreur.
  4. molecule verify : Exécuter les vérifications.
  5. molecule destroy : Nettoyage.

Il convient de noter que, si le rôle ansible utilise service pour vérifier l’état d’un service, la configuration par défaut présente dans le fichier converge.yml n’est pas suffisante. J’ai été bloqué un bon moment avant de trouver des précisions à ce sujet au détour d’une issue sur Github. C’est pourquoi je vais maintenant décrire la configuration que j’ai mise en place.

Cas concret

La configuration que je décrite à la suite permet donc de tester un rôle relativement simple, que j’utilise pour installer fail2ban à partir de l’un des paquets deb du projet. Paquet distribué dans la partie release du projet GitHub. Commençons par le fichier molecule.yml.

---
dependency:
  name: galaxy
driver:
  name: docker
platforms:
  - name: instance
    image: geerlingguy/docker-debian10-ansible:latest
    command: ${MOLECULE_DOCKER_COMMAND:-""}
    volumes:
      - /sys/fs/cgroup:/sys/fs/cgroup:ro
    privileged: true
    pre_build_image: true
provisioner:
  name: ansible
  playbooks:
    prepare: prepare.yml
verifier:
  name: ansible

Cette configuration présente quelques adaptations par rapport à la configuration par défaut. En particulier, du côté de platforms, où les instructions command et volumes sont nécessaires pour que l’instruction service dans ansible soit fonctionnelle. Notons aussi l’ajout de prepare dans provisioner. Cet ajout a pour but d’effectuer quelques actions supplémentaires sur l’instance juste après son installation et avant de commencer le déploiement du rôle. Le contenu du fichier prepare.yml est le suivant :

---
- name: Prepare
  hosts: all
  become: true
  tasks:
    - name: Install ssh
      apt:
        name: [ 'ssh' ]
        state: present
        update_cache: yes
        cache_valid_time: 3600
    - name: restart ssh
      service:
        name: ssh
        state: restarted

Après quelques tentatives de tests et d’erreur au démarrage du service fail2ban, dernière étape de mon rôle, je constate que ssh ne semble pas installé par défaut dans l’image docker choisie. Problème, fail2ban sous debian active par défaut une jail pour ssh et se plaint donc de ne pas trouver les fichiers de logs pour ssh. Ces quelques lignes ont donc pour but d’installer ssh et de démarrer le service associé. On pourrait discuter du fait que ces vérifications devraient être portées par le rôle, mais cela ne me semble pas pertinent, étant donné que mon utilisation du rôle se fait toujours dans le cas d’une installation sur une machine à laquelle j’accède via ssh. Le service est donc toujours présent dans ma situation.

Vient ensuite le fichier converge.yml. Pas de modification de ce côté là.

---
- name: Converge
  hosts: all
  become: true
  tasks:
    - name: "Include role-install-fail2ban"
      include_role:
        name: "role-install-fail2ban"

Enfin verify.yml dernier fichier de configuration. Pour un premier test, j’ai fait au plus simple et je me contente de vérifier que fail2ban fait bien partie des paquets installés sur le système.

---
- name: Verify
  hosts: all
  tasks:
    - name: Gather package facts
      package_facts:
        manager: auto

    - name: Verify Packages
      assert:
        that: "'{{ item }}' in ansible_facts.packages"
      with_items:
        - fail2ban

Voilà pour la configuration du test de mon rôle d’installation de fail2ban.

Conclusion

Après une première soirée passée sur le sujet du test d’un rôle ansible, je suis plutôt satisfait du résultat. Bien que le rôle soit l’un de mes rôles les plus simples, cela ne devrait pas être trop compliqué de généraliser cette méthode à l’ensemble de mes rôles, mais cela nécessitera sans aucun doute de nombreuses heures de développement. Comme souvent, c’est un processus itératif qui sera effectué progressivement sur les prochains mois. La simplicité de réaliser un test sur un système vierge est vraiment appréciable et permettra de vérifier qu’un rôle modifié fonctionne toujours, et cela, sans avoir à passer par le déploiement d’un serveur vierge. Prochaines étapes : étudier l’intégration avec le système d’actions GitHub et tester le playbook permettant le déploiement automatique d’Unicoda.

Sources

exim4

J’ai effectué courant décembre 2020, une migration de mes services auto-hébergés vers une nouvelle machine. Ayant réorganisé en 2019 l’ensemble de mes roles Ansible, et passant d’une base Debian 9 à Debian 10, de nombreuses corrections ont une nouvelle fois été nécessaires avant que l’ensemble soit à nouveau déployé correctement de manière automatique. La majorité des adaptations provenaient du passage à php7.4, avec un test de la version 8 (encore trop récente pour plusieurs services). Le reste concernait l’envoi de mail depuis le serveur avec exim4.

En commençant l’aventure de l’auto-hébergement, la question de l’envoi des mails ne s’était pas posée, car, dans mes souvenirs en tout cas, WordPress arrivait à me notifier par mail sans avoir de modification à effectuer au niveau du système Debian fournit avec le serveur Kimsufi que j’utilisais à l’époque. En migrant par la suite sur un VPS et en auto-hébergeant certains services à mon domicile, l’envoi de mail avait cessé de fonctionner et j’avais choisi d’ignorer la question jusqu’à la mie 2019, où j’avais réussi à produire une configuration fonctionnelle, en utilisant les serveurs de mail de l’hébergeur. Une nouvelle migration d’Unicoda courant 2020 avait à nouveau rendu l’envoi de mail inopérant. Idem avec la récente migration de ma machine locale.

Afin de continuer de recevoir les notifications liées à l’exécution des sauvegardes journalières de l’ensemble des services, et de bénéficier à nouveau des notifications WordPress, comme celles des nouveaux commentaires, je me suis donc replonger dans les profondeurs de la configuration des services mails sous GNU/Linux, afin de corriger le rôle Ansible responsable de la configuration automatique des services mails.

Voici donc à la suite, le résultat de mes notes de 2019, adaptées et corrigées après les recherches de décembre l’an dernier. J’espère ne pas avoir oublié d’étapes, mais les essais successifs de paramètres différents conduisent parfois à des incohérences, lorsque les notes ne sont pas mises à jour avec les dernières modifications effectuées à l’issue d’une session éreintante de débogage :). Par ailleurs, si mon rôle Ansible a bien été mis à jour, il me reste néanmoins à le tester une nouvelle fois, sur un système vierge, dans l’idéal, afin de garantir son bon fonctionnement. Cela étant dit, voici la configuration qui permet à mes serveurs d’envoyer des mails.

Configuration

Commençons par installer les composants nécessaires:

sudo aptitude install exim4 openssl ca-certificates mailutils

Je modifie ensuite /etc/email-addresses pour lier utilisateurs locaux et adresses mails. Ici, le but est de renvoyer tout vers l’adresse example@unicoda.com (adresse fictive pour l’exemple):

root : example@unicoda.com
monUtilisateur : example@unicoda.com
* : example@unicoda.com

Manipulation similaire, cette fois dans /etc/aliases , puis j’exécute la commande newaliases :

root: monUtilisateur
monUtilisateur : example@unicoda.com

Je modifie ensuite le fichier /etc/exim4/passwd.client, pour y ajouter une ligne contenant les informations de connexion au serveur mail choisi pour l’envoi, de la forme target.mail.server.example:login:password , et lui applique un masque 640 pour les autorisations d’accès.

Avant d’aller plus loin dans la configuration, je m’assure également que mon fichier /etc/hosts contient une ligne faisant pointer le hostname de la machine vers elle-même, soit la ligne 127.0.0.1 hostname. Par ailleurs, je modifie également /etc/mailname pour y ajouter le hostname, cette modification m’ayant été particulièrement utile pour le cas d’un message à destination d’un utilisateur de la machine, soit par exemple root@hostname.

Étape suivante, déploiement du fichier /etc/exim4/exim4.conf.localmacros avec le contenu suivant, pour l’utilisation de TLS et du port 465:

MAIN_TLS_ENABLE = 1
REMOTE_SMTP_SMARTHOST_HOSTS_REQUIRE_TLS = *
TLS_ON_CONNECT_PORTS = 465
REQUIRE_PROTOCOL = smtps
IGNORE_SMTP_LINE_LENGTH_LIMIT = true

Avant de continuer plus avant, il faut créer un certificat TLS pour exim4, on peut se baser pour cela sur l’étape 4 de ce tutoriel, qui donne la commande à exécuter. De mon côté, j’utilise les modules openssl_privatekey, openssl_csr et openssl_certificate dans ansible pour réaliser ces opérations.

J’apporte quelques modifications au fichier /etc/exim4/update-exim4.conf.conf, correspondant aux étapes 9 et 10 du tutoriel cité ci-dessus, à savoir, l’ajout du bloc suivant, juste avant la ligne .ifdef REMOTE_SMTP_HEADERS_REWRITE (étape 9):

.ifdef REQUIRE_PROTOCOL
  protocol = REQUIRE_PROTOCOL
.endif

Ainsi que le bloc suivant, juste après la ligne (étape 10):

.ifdef TLS_ON_CONNECT_PORTS
  tls_on_connect_ports = TLS_ON_CONNECT_PORTS
.endif

Enfin, édition du fichier /etc/exim4/update-exim4.conf.conf pour spécifier le comportement d’exim4, qui peut également être généré dynamiquement via sudo dpkg-reconfigure exim4-config. À noter, que le mode satellite ne prend pas en considération l’envoi local, et ne tient donc pas compte des alias configurés (comme précisé dans ce message). Pour être complet, je lui ai donc préféré le mode smarthost. J’ai pour ma part changé le dc_readhost par rapport au tutoriel dont je me suis inspiré, qui proposait localhost comme valeur. Je crois me souvenir que localhost ne fonctionnait pas dans mon cas, mais une nouvelle série de tests avec cette configuration ne serait pas inutile pour être fixé.

dc_eximconfig_configtype='smarthost'
dc_other_hostnames=''
dc_local_interfaces='127.0.0.1 ; ::1'
dc_readhost='unicoda.com'
dc_relay_domains=''
dc_minimaldns='false'
dc_relay_nets=''
dc_smarthost='target.mail.server.example::465'
CFILEMODE='644'
dc_use_split_config='false'
dc_hide_mailname='true'
dc_mailname_in_oh='true'
dc_localdelivery='mail_spool'

Nous y sommes presque, il suffit à présent de déployer la configuration exim4 via sudo update-exim4.conf, puis de redémarrer le service avec la commande sudo service exim4 restart. On peut ensuite essayer d’envoyer un mail depuis la machine avec echo "test" | mail -s "Test" example@unicoda.com. Si tout va bien, le mail arrive correctement à l’adresse fournie, sinon, il vous faudra, comme moi, parcourir les logs (sudo tail /var/log/exim4/mainlog) pour comprendre la nature du problème de configuration et parcourir les nombreux sujets et documentation autour d’exim4.

Pour finir, avant une liste d’article qui m’avait été utile lors de la configuration, voici encore quelques commandes utiles pour déboguer une configuration exim4 non fonctionnelle.

Commandes

Consulter la liste des messages gelés.

exim4 -bp

Supprimer tous les messages gelés.

exiqgrep -z -i | xargs exim -Mrm

Sources

Windows 10 – Au secours !

Mes parents m’ont demandé d’effectuer, en fin d’année 2020, une configuration basique sur un ordinateur récent tournant sous Windows et je dois dire que le fonctionnement de cet OS m’irrite au plus haut point.

Lorsqu’un utilisateur sans mot de passe éteint l’ordinateur, c’est le compte de cet utilisateur qui est ouvert automatiquement par défaut. Complètement idiot si vous avez plus d’un utilisateur, cela obligeant un utilisateur à déconnecter le compte ouvert pour se connecter. Seule solution, à priori, mettre en place un mot de passe.

À la première installation du poste, pas de moyen visible de créer un compte local, sans utiliser la ruse qui consiste à saisir plusieurs fois un numéro de téléphone erroné, ou en ne se connectant pas au réseau comme demandé dans une étape précédente.

L’affichage est par défaut zoomé, 150% sur ce poste. Éventuellement utile pour l’accessibilité si vous avez des problèmes de vue, sinon, cela donne une interface horriblement grosse et prenant une place folle en comparaison du contenu.

Créer un autre compte utilisateur local est une plaie.

Des tas de bidules pas utile de base. Une icône LinkedIn, sérieux !? Heureusement, un petit coup de PrivateZilla permet de désactiver pas mal de choses.

Le petit message quand en changeant le navigateur par défaut la première fois, cherche à semer le doute dans la tête de l’utilisateur lambda.

Le petit choix proposé l’OS pour avoir des pubs non ciblées, qui seront donc moins pertinentes. On en pleurerait.

Et pour terminer, un petit coup de W10Privacy dans le système pour être certain de désactiver certains paramètres relatifs à la vie privée et bien cacher dans l’interface.

Et j’en oublie certainement d’autres. Pour le reste, le système a l’air de fonctionner correctement. Alors bien entendu, je pourrais tout supprimer et installer une version de GNU/Linux, mais n’étant pas l’utilisateur principal, je préfère ne pas forcer les choses. Je peux proposer, expliquer, mais c’est à l’utilisateur final de savoir s’il est prêt à devoir retrouver ces marques dans un autre système, avec une autre interface. Il faudrait également être certain de la compatibilité logiciel ou de la présence d’alternative pour certains outils.

En tout cas, cela ne me donne vraiment pas envie de remplacer Windows 7 pour mes quelques sessions de jeux, malgré l’absence de nouvelles mises à jour.

Voilà pour les réactions à chaud. Je me dis donc que j’ai bien fait de passer à MacOS au boulot. Et pourtant, je n’ai pas remarqué tous ces problèmes lors de tests en machine virtuelle Win 10 sur MacOS, mais cela pouvait peut-être provenir de l’utilisation d’une version Entreprise du système. Et qui sait, un jour peut-être, un OS GNU/Linux au quotidien dans le domaine pro, avec une configuration aux petits oignons et utilisable majoritairement au clavier: le rêve.

Il va y avoir du ban !

Je disais il y de cela deux semaines, que j’avais profité du retour d’Unicoda chez OVH pour faire un tour du côté des logs du serveur. En continuant de creuser et d’analyser, l’intérêt de mettre en place un outil automatique, ou un processus d’analyse périodique, se fait clairement sentir.

En effet, en étudiant les résultats de l’agrégation des logs sur une dizaine de jours, je constate avec étonnement que l’url la plus demandée est xmlrpc.php. Pas de problème, la chose est connue, un ou plusieurs bots doivent encore être en train de s’amuser à essayer d’infiltrer la plateforme. En revanche, ce qui m’intrigue au plus haut point, c’est que le nombre d’appels soit si élevé, étant donné que je déploie systématiquement une configuration très agressive contre ceux qui spam les appels à cette page, à savoir ban IP d’une journée via fail2ban.

En allant regarder les logs de fail2ban, je constate que celui-ci se plaint de ne pas arriver à déterminer la date correcte d’un événement. Aie ! Les filtres fonctionnent correctement, mais la configuration n’est plus suffisante pour que le timestamp Apache du log soit bien compris par fail2ban. Après plusieurs essais, je décide d’en profiter pour mettre à jour fail2ban vers une version plus récente que celle fournie de base dans Debian 10, en suivant la procédure décrite sur cette page. Cela ne suffisant pas à résoudre le problème, je passe donc à la modification de mes filtres.

Pour protéger la page xmlrpc.php, j’obtiens finalement la configuration suivante:

[INCLUDES]
before = apache-common.conf

[Definition]
failregex = ^<HOST> -.* "(GET|POST|HEAD) /xmlrpc.php HTTP.*"
ignoreregex =
datepattern = ^[^[]*[({DATE})
              {^LN-BEG}

En ce qui concerne la page de login, la mise à jour de la configuration nous donne le filtre ci-dessous.

[INCLUDES]
before = apache-common.conf

[Definition]
failregex = ^<HOST> -.* "(GET|POST|HEAD) /wp-login.php HTTP.*"
ignoreregex =
datepattern = ^[^\[]*\[({DATE})
              {^LN-BEG}

Enfin, j’ai remarqué dans les logs qu’un bot testait des urls au pif, afin d’essayer de récupérer des éventuels fichiers de sauvegarde ou de configuration, à l’aide de requêtes HEAD qui terminent donc toutes en erreurs 404. J’en profite donc pour ajouter un nouveau filtre afin de traiter ce cas précis.

[INCLUDES]
before = apache-common.conf

[Definition]

failregex = ^<HOST> -.* "HEAD /.* HTTP.*" 404
ignoreregex =
datepattern = ^[^\[]*\[({DATE})
              {^LN-BEG}

Après ces quelques modifications, mon fail2ban fonctionne à nouveau correctement et il est vraiment satisfaisant de voir les bots se faire bannir automatiquement en temps réel. Cela devrait également permettre de soulager un peu le serveur, en évitant qu’il traite du trafic non désiré.

Depuis combien de temps fail2ban ne fonctionnait plus correctement ? Aucune idée… Et c’est là que le manque de monitoring se fait doucement sentir. Rien qu’avec une agrégation des logs, j’aurais été en mesure de détecter l’augmentation du nombre d’appel tentant de trouver une faille. A une époque, je recevais un mail quotidien de fail2ban résumant le nombre d’IPs bloquées et d’autres métriques similaires, malheureusement, lorsque j’avais tenté de réactiver l’envoi, le mail se faisait systématiquement attraper par les filtres de l’hébergeur, car contenant ce qui était identifié comme des liens vers du contenu malfaisant (spam, piratages, etc).

L’année 2021 s’oriente donc vers la question du monitoring, longtemps laissée de côté, faute de temps, ou pour des questions de priorité. Affaire à suivre. Les mécanismes de blocage automatique des attaquants sont donc à nouveau en place sur Unicoda et en totalité depuis le week-end dernier. Une bonne chose de faite, et qui ne devrait en aucun cas impacter les lecteurs !