Forum Linux.debian/ubuntu Mis à jour automatique VPS Debian, faille de sécurité ?

Posté par  . Licence CC By‑SA.
Étiquettes :
0
29
avr.
2014

Bonjour,

Suite à quelques commentaires postés dans les forums j'essaye en ce moment le principe de VPS avec Iniz :

Je suis donc parti sur une VM Debian Wheezy et j'ai regardé un peu comment cela se passait.

Pas de gros soucis, c'est en gros comme une Debian que l'on installe soi-même sauf que :

  1. il y des limitations sur iptable à cause de la virtualisation: Issues with Ubuntu's UFW on OpenVZ VPS
  2. les droits d'exécution ont été enlevés sur presque tous les scripts présent dans /etc/cron.daily

Je croyais être tranquille pour Heartbleed avec une mise à jour de sécurité automatique quotidienne, mais du coup le script de mise à jour ne se lance pas à cause du point 2. Je n'ai pas encore
J'ai remonté le soucis à l'hébergeur qui ne compte pas changer sa VM de base. Apparemment ce n'est pas un gros problème selon eux (et la VM est un modèle standard/officiel pour OpenVZ).

Normalement il semblerait que les scripts ne font que des choses secondaires mais je ne suis pas sûr.

Est-ce que cela est selon vous un problème de sécurité et que je devrais pousser pour qu'ils corrigent ?
Pour ma part j'ai corrigé le problème localement sur ma machine, donc c'est surtout pour ceux qui ne sont pas au courant que c'est embêtant.

Merci !

  • # Pas un problème de sécurité

    Posté par  . Évalué à 4. Dernière modification le 29 avril 2014 à 22:07.

    Je croyais être tranquille pour Heartbleed avec une mise à jour de sécurité automatique quotidienne

    Des mises à jour de sécurité, même automatiques et même quotidiennes, ne suffisent pas à « être tranquille ».

    Heartbleed en est justement un bon exemple : la mise à jour du paquet libssl1.0.0 chez Debian se charge bien de redémarrer automatiquement les principaux services potentiellement concernés, mais ça s’arrête là. Il reste encore à l’administrateur à révoquer et remplacer les certificats dont les clefs privées ont potentiellement fuité — le genre de tâches qu’un gestionnaire de paquets ne peut pas faire à sa place.

    Est-ce que cela est selon vous un problème de sécurité et que je devrais pousser pour qu'ils corrigent ?

    Je ne vois aucun intérêt à empêcher l’exécution des scripts de /etc/cron.daily, et c’est certainement quelque chose qui devrait être corrigé d’après moi.

    Mais ça ne pose pas pour autant de problème de sécurité. Ça empêche le déclenchement des mises à jour automatiques, d’accord, mais celles-ci ne sont de toute façon pas activées par défaut sous Debian et l’administrateur devra donc toujours faire quelque chose pour les activer (et j’ajouterai que les mises à jour automatiques ne sont pas une feature de sécurité).

    Le plus gros problème que je vois, c’est que la rotation quotidienne des journaux ne se fera pas (c’est normalement piloté par le script /etc/cron.daily/logrotate). Si l’administrateur ne s’en aperçoit pas, tout semblera fonctionner correctement, jusqu’au jour où les journaux seront trop volumineux…

    • [^] # Re: Pas un problème de sécurité

      Posté par  . Évalué à 2.

      Des mises à jour de sécurité, même automatiques et même quotidiennes, ne suffisent pas à « être tranquille ».

      Heartbleed en est justement un bon exemple : la mise à jour du paquet libssl1.0.0 chez Debian se charge bien de redémarrer automatiquement les principaux services potentiellement concernés, mais ça s’arrête là. Il reste encore à l’administrateur à révoquer et remplacer les certificats dont les clefs privées ont potentiellement fuité — le genre de tâches qu’un gestionnaire de paquets ne peut pas faire à sa place.

      J'en suis bien conscient que ce n'est pas la panacée mais je n'avais pas précisé le contexte (un peu hors-sujet, je ne voulais pas vous embêter avec cela).
      Je me place dans le contexte de serveurs perso avec sites web perso non critiques. Donc en particulier l'admin système (moi) a un autre boulot et n'est pas 24h/24 devant son écran ou bien à portée d'internet (vacances à l'autre bout du monde…).
      J'ai donc choisi d'avoir des Debian stable mis à jour automatiquement qui me semble un bon compromis entre sécurité et charge de travail/disponibilité (ce qui n'empêche pas de suivre d'un oeil les problèmes de sécurité).

      Pour Heartbleed, j'ai été mis au courant vers 7h du matin et j'ai suivi d'un oeil intéressé ce qui se passait en ne touchant pas à mes Debian (de tests) pour voir comment cela allait se comporter.
      Une Debian installé à la mano a bien été mis à jour comme prévu le matin même, mais les services n'ont pas été redémarrés comme tu le mentionnes. Cependant la seconde mis à jour (le jour suivant) a bien redémarré les services.
      La Debian fourni par Iniz avec laquelle je jouais depuis quelques jours n'a pas été mis à jour à cause du problème mentionné.

      Donc au final en suivant l'affaire pendant 24h, j'en ai beaucoup appris en tant qu'admin du dimanche :

      • Délai entre 24 et 48h avant mis à jour de sécurité (premier patch en urgence + retour sur le premier patch + deuxième patch)
      • Les Debian pré-installées sont parfois bien bidouillées par l'hébergeur
      • J'ai depuis activé la notification par email pour les mis à jour (je ne sais pas combien de temps je vais supporter ce truc cependant…)
      • Des opérations manuelles sont parfois à prévoir (ce que tu mentionnes)

      Là je suis l'affaire du problème de sécurité sur flash pour voir comment cela va être géré (j'utilise le flash de Windows à travers Wine/Pipelight).

      Je ne vois aucun intérêt à empêcher l’exécution des scripts de /etc/cron.daily, et c’est certainement quelque chose qui devrait être corrigé d’après moi.

      Je pense aussi mais si ce n'est pas un problème de sécurité ils ne vont pas le faire (pas rentable pour eux je suppose).

      Mais ça ne pose pas pour autant de problème de sécurité. Ça empêche le déclenchement des mises à jour automatiques, d’accord, mais celles-ci ne sont de toute façon pas activées par défaut sous Debian et l’administrateur devra donc toujours faire quelque chose pour les activer (et j’ajouterai que les mises à jour automatiques ne sont pas une feature de sécurité).

      Pour simplifier j'avais 2 Debian dont l'option de mis à jour a été demandée (option activée):

      • La première a été mis à jour, libssl a été patché (bon ok les certifs SSL et les mots de passe n'ont pas été changé)
      • La deuxième n'a pas été mis à jour, libssl n'est pas patchée

      Au final même si on peut dire que c'est de la responsabilité de l'admin de s'assurer que sa machine et ses services marchent bien, j'ai bien un problème de sécurité à cause de leur "bogue".

      L'analogie est un peu osée, mais si je prends une voiture avec l'option entretien automatique et que l'entretien n'est pas fait. Cela devient un problème de sécurité le jour où les freins ne marchent plus.

      Le plus gros problème que je vois, c’est que la rotation quotidienne des journaux ne se fera pas (c’est normalement piloté par le script /etc/cron.daily/logrotate). Si l’administrateur ne s’en aperçoit pas, tout semblera fonctionner correctement, jusqu’au jour où les journaux seront trop volumineux…

      J'ai pas mal de choses dans /etc/cron.daily mais je ne m'y connais pas suffisamment pour comprendre tout ce que cela fait.
      En tout cas j'ai remis tous les droits d'exécution et tout fonctionne bien maintenant.
      Si vous êtes utilisateur de OpenVZ et de Debian, jetez un oeil !

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.