Un des points les plus importants pour améliorer la sécurité de votre système GNU/Linux est d'être sûr d'appliquer les correctifs de sécurité fournis par votre distribution.

Si vous administrez une distribution sous Debian stable, ces mises à jours sont peu fréquentes. Néanmoins, elles peuvent survenir de manière inopinée. Cette année, il y a eu ShellShock et quelques problèmes sur OpenSSL. Bien entendu, si vous faîtes un peu de veille technologique, vous serez au courant. Pour autant, difficile de se concentrer sur toutes les failles de sécurité qui concernent vos machines de production qui peuvent avoir des paquets différents d'une machine à l'autre.

Certains diront qu'on peut configurer des mises à jour automatiques sans interaction. Pourtant, sur des machines de production, je ne recommande pas cette stratégie. En effet, une machine de production doit être stable et la mise à jour des paquets doit se faire uniquement après des tests concluants. Sous Debian, il est très rare qu'une mise à jour de sécurité pose problème mais ça peut arriver et là, c'est le drame.

Le vrai défi est donc d'avoir une alerte qui indique lorsqu'il y a une mise à jour et ensuite, on peut réaliser les tests sur des machines de pré-production pour voir s'il n'y a pas de régressions. Donc, ce qu'on veut, c'est juste avoir l'information qu'une mise à jour existe et non d'appliquer aveuglément la mise à jour.

Une des solutions que j'ai retenue pour ce problème est d'utiliser le paquet apticron. Ce dernier est un simple script cron qui se lance tous les jours et qui va réaliser un apt-get update et voir s'il y a des paquets à installer. Si c'est le cas, il vous envoie un mail. Le principe est donc simple et très efficace.

Sa mise en oeuvre l'est également. Il suffit d'installer le paquet apticron de la manière suivante:

# aptitude install -R apticron

Par défaut, apticron recommande apt-listchanges mais à l'usage, ce paquet n'est pas nécéssaire. Voilà pourquoi je fais une installation minimaliste.

Ensuite, il faut juste renseigner l'adresse email qui va recevoir l'alerte dans le fichier de configuration situé dans /etc/apticron/apticron.conf:

# apticron.conf
#
# set EMAIL to a space separated list of addresses which will be notified of
# impending updates
#
EMAIL="mederic.ribreux@medspx.fr"
...

Le reste du fichier de configuration sert à customiser un peu le comportement d'apticron ou le contenu du mail qui sera envoyé. Pour ma part, je n'ai rien changé.

Une fois mis en service, le script cron est disponible dans /etc/cron.d/apticron. Son contenu est très simple à comprendre:

44 * * * * root if test -x /usr/sbin/apticron; then /usr/sbin/apticron --cron; else true; fi

Toutes les heures, lors de la 44ème minute, le script se lance. Par défaut, l'option --cron permet à apticron de ne pas envoyer de courriel plus d'une fois par jour. Cette configuration par défaut me convient bien.

A chaque mise à jour disponible sur les paquets de mes machines, je reçois une alerte par courrier électronique. Après, c'est à moi de voir ce que je dois faire... Mais au moins, j'ai l'information dans un délai raisonnable.

Posted sam. 13 déc. 2014 19:32:00 Tags:

Un Plugcomputer est décidément un matériel bien spécial... Depuis le début, j'ai toujours eu des problèmes de boot sur mon Sheevaplug. Concrètement cela se manifeste par le fait qu'après le reboot de la machine, un certain nombre de services ne sont pas lancés. Il faut se connecter sur la machine pour relancer manuellement les services. Cette relance manuelle ne pose aucun problème: tous les services se lancent correctement. Mais c'est assez pénible et on se met à craindre chaque reboot de la machine qui, chez moi, indique une panne de courant.

De plus, ce problème est très variable: parfois, deux services sont non lancés, parfois, c'est juste un seul... Pas facile à débugger ! J'ai essayé de jouer sur les priorités de lancement mais sans succès (du moins, avec un succès restreint).

Dernièrement, je me suis battu avec Apache. A chaque reboot, le service n'était pas lancé. Rien dans les logs... la relance manuelle via SSH ne posait jamais de problème. J'ai essayé d'y voir un peu plus clair en trickant le fichier d'init (cette machine ne bénéficie pas de systemd) mais tout ce que je pouvais constater, c'est que le service ne se lance pas et ce, sans aucun message d'erreur (même en balançant toute les sorties vers un fichier de log). Le symptôme est le suivant: parfois /usr//lib/apache2/mpm-prefork/apache2 échoue sans erreur. A ce stade, on ne pas faire grand chose: impossible d'avoir des informations sur ce qui plante.

Ce symptôme qui est un vrai problème est, à mon avis, dû au fait qu'une machine basée sur un SOC et qui utilise un périphérique de masse lent comme une carte SD est assez mal ordonnancée. Je suppose que certains systèmes indispensables à Apache ne sont pas correctement initialisés au moment du boot. Comme il m'est impossible de diagnostiquer plus avant, j'ai imaginé une solution de contournement à peu de frais...

Pourquoi pas retarder le lancement des services utilisateurs avec une simple commande sleep ? J'ai donc conçu un script sysv qui fait tout simplement ça. En voici le contenu (je l'ai mis dans /etc/init.d/slowboot):

#!/bin/sh

### BEGIN INIT INFO
# Provides:        slowboot
# Required-Start:  $network
# Required-Stop:   $network
# Default-Start:   S
# Default-Stop:    0 6
### END INIT INFO

PATH=/sbin:/bin:/usr/sbin:/usr/bin

. /lib/lsb/init-functions

# Sheevaplug boots too fast for himself.
# Some services cannot be launched correctly if you don't
# make a pause to the booting process.
# This scripts just wait 15 seconds !
NAME=slowboot

case $1 in
     start|force-reload|restart)
    log_action_begin_msg "Slowing done boot !"
        sleep 15
        log_action_end_msg 0
        ;;
     stop)
    exit 0
        ;;
     status)
    exit 0
     ;;
     *)
        echo "Usage: $0 {start|stop|restart}"
    exit 2
    ;;
esac

Pour l'activer, lancer la commande suivante:

# update-rc.d slowboot start 14 S 

Cela permet de l'activer au moment du lancement des scripts /etc/rcS.d (les scripts systèmes lancés avant le niveau précisé par inittab) à la position 14 (chez moi, ça correspond à peu près après le lancement du réseau).

Une fois activé, mes problèmes ont disparu. 15 secondes sur une séquence de boot d'environ 2 minutes, ce n'est franchement pas la mer à boire. En tout cas, je préfère une relancement retardé de 15 secondes où les services sont tous lancés que d'avoir à me reconnecter à distance pour les réactiver manuellement.

Posted dim. 14 déc. 2014 12:15:50 Tags: