Quelle est l'urgence d'un *** redémarrage du système requis *** pour la sécurité?


56

Pour apprendre un peu d’administration de serveur, j’ai mis en place un simple serveur Ubuntu 14.04 sur lequel je gère un site Web personnel. Je l'ai configuré pour installer automatiquement les mises à jour de sécurité, mais je laisse de côté les autres mises à jour. Cela semble fonctionner assez bien. Parfois, lors de la connexion au serveur (avec ssh), je reçois un message disant:

*** System restart required ***

Les fois où cela s'est produit, j'ai simplement redémarré Ubuntu et tout allait bien. C'est ok parce que c'est un site web personnel simple. Ce que je me demande cependant, c’est comment cela fonctionne pour les serveurs Web, ce qui devrait représenter jusqu’à 99,9999% du temps? Ne redémarrent-ils pas et risquent-ils de compromettre la sécurité parce que les mises à jour de sécurité ne sont pas installées (ce que je ne peux pas imaginer)? Ou prennent-ils le temps d'arrêt pour acquis (ce que je ne peux pas imaginer non plus)?

Comment devrais-je gérer cela s'il s'agissait d'un serveur de production très important que je souhaite maintenir en activité? Tous les conseils sont les bienvenus!

[EDIT] Je sais que je peux faire cat /var/run/reboot-required.pkgspour lister les paquets qui causent le redémarrage. La commande génère actuellement les éléments suivants:

linux-image-3.13.0-36-generic
linux-base
dbus
linux-image-extra-3.13.0-36-generic
linux-base

mais comment puis-je savoir si les mises à jour sont de petites choses ou si j'ai une faille de sécurité grave si je ne fais pas le redémarrage?

[EDIT2] D'accord, j'ai maintenant combiné les commandes que j'ai trouvées utiles:

xargs aptitude changelog < /var/run/reboot-required.pkgs | grep urgency=high

Si cela ne produit rien, il ne semble pas y avoir de problèmes de sécurité urgents.

Une dernière question cependant: y lowat-il medium, et highles seules possibilités d’urgence, ou existe-t-il plus comme par exemple criticalou extremelyimportant?


Je ne comprends pas la question. Les sites Web à plus fort trafic planifient simplement ce temps d'arrêt pendant une période de temps avec moins de trafic. Son urgence dépend de ce qui est mis à jour exactement.
Ramhound

14
Je me demande combien de personnes sont venues ici parce qu'elles ont vu la question dans la liste "Hot Network Questions" et se sont demandé ce qu'étaient les explétives ... * lève la main *
David Richerby

6
@Ramhound: Ehm, non, ils basculent de manière transparente sur un serveur secondaire pour la durée de la maintenance.
Courses de légèreté avec Monica

1
Concernant la dernière question: je pense à filtrer les niveaux bas et moyen et à considérer tous les autres niveaux / inconnus comme urgents: | grep 'urgency=' | egrep -v '=(low|medium)'
KajMagnus

Réponses:


45

La réponse n’est pas simple car elle dépend des mises à jour effectuées. Si le noyau a eu un grave problème de sécurité, il est conseillé de redémarrer le plus rapidement possible. Si le noyau ne contenait que des correctifs mineurs, le redémarrage pourrait être différé.

Si vous garantissez une disponibilité> 99,9%, vous disposerez presque toujours d'un système en cluster où vous pourrez redémarrer les nœuds un par un sans interrompre le service.

Vous devez donc redémarrer le premier système et le rattacher au cluster. Puis le second et ainsi de suite. Ensuite, le service ne deviendra jamais indisponible.


2
Merci pour votre réponse. J'ai ajouté un petit morceau à ma question initiale; Je sais que je peux faire cat /var/run/reboot-required.pkgspour obtenir les packages qui nécessitent le redémarrage. Mais comment savoir s'il ne s'agit que de corrections mineures ou s'il s'agit d'une grave vulnérabilité de la sécurité?
kramer65

2
@ kramer65 chaque paquet a un changelog. Par exemple, le changlog pour le noyau peut être trouvé ici .
Uwe Plonus

2
Très bien, alors c’est au sysadmin (c’est-à-dire: dans ce cas moi-même) de déterminer si ces changements sont importants? J'ai trop peu de connaissances pour le déterminer pour le noyau Linux, encore moins pour les milliers d'autres paquets. N'y a-t-il aucun endroit central où je peux déterminer si la mise à jour est absolument nécessaire pour la sécurité?
kramer65

8
@ kramer65 Run aptitude changelog <package>, voici un exemple de sortie: paste.ubuntu.com/8410798 (Ceci est sur un système Debian, pas Ubuntu, mais cela fonctionnera aussi sur Ubuntu.)
nyuszika7h

5
Merci pour toute l'aide ici. J'ai finalement combiné toutes les choses que j'ai apprises ici dans une seule commande: xargs aptitude changelog < /var/run/reboot-required.pkgs | grep urgency=high(l'ajoutée à la question initiale également), ce qui donne un résultat indiquant quels paquets ont des correctifs hautement urgents. Après cela, les paquets individuels peuvent bien sûr être inspectés. Merci mille fois pour toutes les réponses et idées!
kramer65

3

addon pour la solution de sujet

J'effectue une vérification similaire pour les «exigences de redémarrage» du système de surveillance zabbix

Je vois 2 problème dans la solution 'Topic':

  1. aptitude fonctionne généralement mal dans les scripts. Je tue quelques heures mais je ne l'ai toujours pas fait fonctionner avec zabbix
  2. si seulement 1 journal des modifications inclut une mise à jour urgente , votre chèque affichera toujours des résultats positifs

Ma logique est:

  1. Vérifiez la dernière modification uniquement dans changelog pour chaque paquet nécessitant un redémarrage du système
  2. En sortie, affiche uniquement la mise à jour prioritaire

En utilisant la documentation Debian, j'ai trouvé 5 valeurs possibles pour 'urgence' et le fait qu'elle puisse être suivie de caractères égaux ("=") ou en point-virgule (":"). Il peut aussi y avoir des majuscules et des minuscules

Alors je me suis retrouvé avec:

#!/bin/bash
##################################
# Zabbix monitoring script
#
# Checking urgency in changelog 
# for updates which require system restart
#
##################################
# Contact:
#  anton.lugovoi@yandex.ru
##################################
# ChangeLog:
#  20151205    initial creation
#  20151208    check uniq packages only 
##################################

case "$1" in

status)
    if [ -f /var/run/reboot-required ]; then
      echo 1
    else
      echo 0
    fi 
    ;;

urgency)
    if [ -f /var/run/reboot-required.pkgs ]; then
      while read pkg; do
        tmp=`/usr/bin/apt-get changelog $pkg | \
             /bin/grep -m1 -ioP '(?<=[Uu]rgency[=:])(low|medium|high|emergency|critical)' | \
             tr '[:upper:]' '[:lower:]'`
        if [ -n $tmp ]; then
          if   [ "$tmp" == "low" ] && \
               [ "$urgency" != "medium" ] && \
               [ "$urgency" != "high" ] && \
               [ "$urgency" != "emergency" ] && \
               [ "$urgency" != "critical" ]; then 
            urgency=low
          elif [ "$tmp" == "medium" ] && \
               [ "$urgency" != "high" ] && \
               [ "$urgency" != "emergency" ] && \
               [ "$urgency" != "critical" ]; then 
            urgency=medium
          elif [ "$tmp" == "high" ] && \
               [ "$urgency" != "emergency" ] && \
               [ "$urgency" != "critical" ]; then 
            urgency=high
          elif [ "$tmp" == "emergency" ] && \
               [ "$urgency" != "critical" ]; then 
            urgency=emergency
          elif [ "$tmp" == "critical" ]; then 
            urgency=critical
            break
          fi
        fi 
      done < <(sort -u /run/reboot-required.pkgs)
    else
      urgency=none
    fi

    case "$urgency" in
        none)      urgency=0 ;;
        low)       urgency=1 ;;
        medium)    urgency=2 ;;
        high)      urgency=3 ;;
        emergency) urgency=4 ;;
        critical)  urgency=5 ;;
        *)         urgency=42 ;;
    esac

    echo $urgency
    ;;
esac
exit 0

Par conséquent:

  • reboot_required_check.sh status renvoie 1 si un redémarrage est requis, 0 sinon
  • reboot_required_check.sh urgency renvoie le niveau 'd'urgence' le plus élevé ou '0' si le redémarrage n'est pas requis

J'espère que ça aide quelqu'un à gagner du temps;)


0

Ce que je me demande cependant, c’est comment cela fonctionne pour les serveurs Web, ce qui devrait représenter jusqu’à 99,9999% du temps? Ne redémarrent-ils pas et risquent-ils de compromettre la sécurité parce que les mises à jour de sécurité ne sont pas installées (ce que je ne peux pas imaginer)? Ou prennent-ils le temps d'arrêt pour acquis (ce que je ne peux pas imaginer non plus)?

Les gros serveurs Web sont redémarrés lorsque le * redémarrage du système requis * apparaît pour des raisons de sécurité.

Mais cela est transparent pour l'utilisateur et le site n'est jamais en panne car les gros serveurs exécutent souvent deux ou trois serveurs qui stockent exactement les mêmes fichiers et affichent le même site. Le premier est le serveur principal tandis que les deux autres sont secondaires et ne sont utilisés que lorsque le serveur principal est en panne.


1
Bien que cela soit théoriquement correct, Big web serversexécutez les versions personnalisées de Linux. Ils ne verront pas de System restart requireddialogue, ils mettront à jour ce dont ils ont besoin pour rester en sécurité. Dans la plupart des cas, bon nombre des mises à jour, voire toutes, peuvent être effectuées lorsque le système est en cours d'exécution (je pense qu'il est même possible de mettre à jour un noyau Linux sur un système en cours d'exécution sans redémarrage).
Joeeey

Intéressant. J'ai un serveur sur Amazon et je le redémarre souvent à cause de ce message ... J'utilise Ubuntu sur mon serveur. Comment le personnaliser afin que je n'ai pas à le redémarrer de temps en temps?
rom

Je n'ai aucune expérience avec les serveurs Amazon. Big web serverssont exécutés sur des serveurs et VPS dédiés. De ce fait, l’administrateur système a plus de contrôle sur le logiciel. Amazon vous donne-t-il un accès root à votre serveur?
Joeeey

Oui, il est possible d'avoir un accès root.
rom

Ensuite, la mise à jour manuelle des packages, puis le redémarrage des services affectés et l'utilisation de quelque chose comme Ksplice pour les mises à jour du noyau seraient un moyen. Il convient de noter que Ksplice freezes execution of a computer so it is the only program runninglors de l’application d’un correctif, il peut donc rester un peu de temps mort (en raison du blocage du processus du serveur Web). C’est là que la réponse de @Uwe Plonus intervient.
Joeeey
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.