[Serveurs] redémarrage périodique ?

Support Debian
#1

Bonjour,

Un article récent sur ServerWatch explique la nécessité de redémarrer périodiquement son serveur Active Directory.

C’est évidemment pour des serveurs Windows, et il y a même un bout de code (en powershell) pour savoir depuis combien de temps les précieux contrôleurs de domaine AD n’ont pas été redémarrés.

Parmi les raisons invoquées pour justifier cette nécessité de redémarrer les contrôleurs de domaine tous les mois, on trouve le problème des fuites mémoire (ben voyons!) et le fait que Microsoft envoie chaque mois des correctifs de sécurité qui pratiquement requièrent un redémarrage pour être correctement appliqués.

Comme la plupart des conseils trouvés sur serverwatch on ne va pas au fond des choses, on ne cherche pas à trouver l’origine des problèmes, on en est bien incapable, et on se rabat sur des recettes bricolées de contournement.

Dans le cas d’un serveur Debian, offrant un service critique du genre authentification (via LDAP par exemple), est-ce que vous prévoyez un redémarrage systématique tous les x jours dudit serveur ?
Est-ce que vous avez installé le paquet needrestart? (190k sur disque ).

Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة

F. Petitjean
Ingénieur civil du Génie Maritime.

« Celui qui, parti de rien, n’est arrivé nulle part n’a de merci à dire à personne !! »
Pierre Dac

#2

Hello,

Un restart est nécessaire uniquement en cas de MAJ de kernel ou de la lib C qui est le langage principal du kernel. On peut faire la même chose pour le perl et le C++ car il y en a un petit peu mais c’est tellement mineur…

En dehors de ça pas besoin de reboot, il faut juste bien monitorer ça machine notamment sur les sémaphores où on peut avoir quelques problème si on a tendance à utiliser le kill -9.

Dans tout les cas si tu mets correctement à jours ton OS, il faut s’attendre à un reboot tout les mois. Le mieux est de faire une belle tâche planifier avec un bon ordonnanceur pour préparer un rollback , faire sa maj, restarter et vérifier correctement ses services et si KO un petit mail ou sms si besoin :slight_smile:

#3

Oui.

Pardon ? Le noyau n’utilise pas la libc, il est autonome, et il n’est pas nécessaire de redémarrer le système après une mise à jour de la libc.

Par contre il faut redémarrer tous les processus (services, démons, applications…) qui utilisent des fichiers provenant d’un paquet (notamment les bibliothèques partagées, pas seulement la libc) qui vient d’être mis à jour. C’est là que les outils comme checkrestart ou needrestart sont utiles pour détecter ces processus. Parfois, notamment dans le cas de la libc, il y en a tellement qu’il est plus simple de redémarrer le système.

#4

D’où sortez-vous cela ? On n’est pas sur serverwatch ici :wink:

fp2x@halc9:~$ uptime
 15:07:10 up 110 days,  5:25,  1 user,  load average: 0,00, 0,01, 0,05
fp2x@halc9:~$

Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة

F. Petitjean
Ingénieur civil du Génie Maritime.

« Il semble que la perfection soit atteinte, non quand il n’y a
plus rien à ajouter mais quand il n’y a plus rien à retrancher »
Saint-Exupéry -Terre des hommes , chapitre III , L’avion.

#5

Je suppose que @TrashHard veut dire que les mises à jour de sécurité des paquets “importants” (noyau, libc) amènent à redémarrer en moyenne une fois par mois. De fait, si je compte bien, sur les 10 premiers mois de 2016 il y a eu environ 10 mises à jour de sécurité (en comptant les DSA et les “point release”) du noyau et/ou de la libc pour Jessie, donc l’ordre de grandeur est correct.

#6

C’est une moyenne, chaque patch du kernel nécessite un reboot, et on a une MAJ de kernel ± tout les mois donc ça semble logique :slight_smile:

C’est bien votre serveur n’est pas patché et est vulnérable à la dernière dirty cow Linux corrigé qui date même pas… d’un moi ^^ https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5195

J’ai pas dis que c’était obligatoire… Encore heureux. Mais un système fiable et sécurisé doit être patché et rebooté régulièrement à mon sens. Même si il y a pas de patch qui nécessite un reboot, c’est un bon moyen de vérifier que le serveur restart correctement et de ne pas laisser des fichiers systemd modifiés qui ne sont pas testés après un patch ou un vieux fichier indispensable stocké en RAM pendant des tests qui n’a jamais été bougé :slight_smile:

Et vus que maintenant on tourne quasiment que sur de la VM les restart prennent 5-10m, donc il ne faut pas se priver :slight_smile:

#7

Je connaissais un admin sys qui se faisait une fierté de ne redémarrer ses serveur qu’une fois par an … en été quand il y avait le moins de monde possible. Mais ça date de bien 15 ans, donc j’espère qu’il a d’autre pratique maintenant

#8

Il faut tout de même pondérer, les patch et application de mise à jour de sécurité n’est plus que conseillé que lorsque la machine est atteignable depuis l’extérieur.

Si nous consentons qu’une machine, par exemple, un contrôleur de domaine, n’est joignable que depuis un LAN sécurisé et non accessible depuis l’extérieur le patchage et le redémarrage n’est pas obligatoire tout de même.

Après l’utilisation de service redondé améliore grandement la simplification de la maintenance.
Il est en effet plus aisée de programmer les mise à jour te les redémarrage nécessaire lorsque qu’un serveur actant en slave habituellement peu prendre le relai le temps de la maintenance :wink:

1 J'aime
#9

Tu veux dire par exemple comme les machines sur lesquelles tournait le logiciel WinCC de contrôle des automates de pilotage des centrifugeuses d’enrichissement de l’uranium de Natanz visé par le ver Stuxnet ?

“Atteignable de l’extérieur”, c’est vague.

#10

Toi comme moi ne sait pas de quels façon le ver à été implanté de toute façon :wink:

Si l’on considère une machine sur un vlan privé à moins que l’infrastructure réseau soit compromise je ne vois pas comment cette machine peu se retrouver atteinte par une connexion extérieur à moins d’une faille dans l’infrastructure réseau … mais là je pense que le patch de sécurité non appliquée serait le cadet des soucis de l’administrateur réseau.

Néanmoins j’admets que atteignable de l’extérieur soit vague sans rentrer dans les détails pour un néophyte, mais pour un administrateur avisée je pense que cela reste compréhensible, non ?

#11

Si je me souviens bien, l’hypothèse privilégiée est que le ver a été introduit via une clé USB infectée.

Un ordinateur ou un réseau n’est jamais complètement isolé, sinon il ne sert à rien. Il y a forcément des entrées/sorties avec l’extérieur qui peuvent être la cible d’un vecteur d’attaque. Cela peut être une console, un port USB, un périphérique… Si une machine n’est pas accessible physiquement, elle communique forcément avec d’autres machines de son réseau privé, et une de ces machines communique forcément avec l’extérieur d’une façon ou d’une autre.

#12

Remarque judicieuse. Pouvez-vous nous écrire et compiler un logiciel malveillant basé sur cette vulnérabilité pour un système antique d’architecture

fp2x@halc9:/var/yp$ lscpu
Architecture:          ppc64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Big Endian
CPU(s):                4
On-line CPU(s) list:   0-3
Thread(s) per core:    1
Core(s) per socket:    2
Socket(s):             2
NUMA node(s):          2
Model:                 IBM,7028-6C4
L1d cache:             32K
L1i cache:             64K
L2 cache:              1440K
L3 cache:              32768K
NUMA node0 CPU(s):     0,1
NUMA node1 CPU(s):     2,3
fp2x@halc9:/var/yp$ uname -a
Linux halc9 3.2.0-4-powerpc64 #1 SMP Debian 3.2.78-1 ppc64 GNU/Linux
fp2x@halc9:/var/yp$

Et dans ce paquet cadeau, n’oubliez aucun binaire spécifique :slight_smile: Cette machine n’est pas accessible directement depuis l’extérieur, le redémarrage prend au moins 10 minutes (ah la technologie IBM ).

Pour vous donnez une idée, il y a encore deux disques qui datent du temps où on fonctionnait sous AIX

 fp2x@halc9:/var/yp$ sudo fdisk -l /dev/sdb
GNU Fdisk 1.2.4
Copyright (C) 1998 - 2006 Free Software Foundation, Inc.
This program is free software, covered by the GNU General Public License.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

No Implementation: Support for adding partitions to AIX disk labels is not
implemented yet.
No Implementation: Support for adding partitions to AIX disk labels is not
implemented yet.
No Implementation: Support for reading AIX disk labels is is not implemented yet.

Extrait de rapport SMART

fp2x@halc9:/var/yp$ sudo smartctl -a /dev/sda | less

=== START OF INFORMATION SECTION ===
Vendor:               IBM
Product:              IC35L146UCDY10-0
Revision:             S21T
User Capacity:        146 814 976 000 bytes [146 GB]
Logical block size:   512 bytes
Rotation Rate:        10000 rpm
...
Manufactured in week 49 of year 2002
Specified cycle count over device lifetime:  10000
Accumulated start-stop cycles:  135
Elements in grown defect list: 0

Un des gros avantages de Debian est son support d’architectures très complet. Ce n’est pas le cas de distributions commerciales comme Süse. A partie de la version 12, la SLES n’est disponible pour les powerpc qu’en architecture ppc64el et n’est donc même pas installable sur ces machines (deux modèles IBM,7028-6C4 ).

Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة

F. Petitjean
Ingénieur civil du Génie Maritime.

« C’est terrible d’allonger la vie en prolongeant seulement la vieillesse. »
– Professeur Choron

#13

C’est certainement possible puisque la faille n’est pas spécifique à une architecture et a été activement exploitée.

Oui, comme les machines infectées par Stuxnet dont je parlais plus haut.

1 J'aime