Auteur Sujet: Application des patchs de sécurité sous Linux  (Lu 416 fois)

0 Membres et 1 Invité sur ce sujet

vivien

  • Administrateur
  • *
  • Messages: 29 187
    • Twitter LaFibre.info
Application des patchs de sécurité sous Linux
« le: 14 novembre 2017 à 19:22:53 »
J'ai trouvé un server HP-UX avec 2100 jours de uptime sans reboot dans un DC, un record  :D
Faut pas être regardant pour les mises à jour de sécurité.

Perso je reboot régulièrement pour les mises à jour de sécurité, j'ai par contre travaillé a réduire la durée de reboot d'un serveur Dell et il faut que je réalise un petit tutoriel, j'arrive à diviser par 4 le temps de boot avec des option du BIOS.

Hugues

  • AS57199 MilkyWan
  • Expert
  • *
  • Messages: 6 267
  • Lyon & Paris
    • MilkyWan
Application patchs de sécurité
« Réponse #1 le: 14 novembre 2017 à 19:30:56 »
Canonical Livepatch + needrestart, et vive l'uptime

vivien

  • Administrateur
  • *
  • Messages: 29 187
    • Twitter LaFibre.info
Application patchs de sécurité
« Réponse #2 le: 14 novembre 2017 à 19:36:32 »
Une solution native à Ubuntu / Debian :

sed -i -e "s/\/\/Unattended-Upgrade::Automatic-Reboot \"false\"/Unattended-Upgrade::Automatic-Reboot \"true\"/g" /etc/apt/apt.conf.d/50unattended-upgrades

Cela effectue un reboot de nuit (entre 6h25 et 6h55), si les mises à jour de sécurité l'exigent.
Bien entendu, il est possible de fixer une heure pour le reboot.

Les autres options :
$ cat /etc/apt/apt.conf.d/50unattended-upgrades
// Automatically upgrade packages from these (origin:archive) pairs
//
// Note that in Ubuntu security updates may pull in new dependencies
// from non-security sources (e.g. chromium). By allowing the release
// pocket these get automatically pulled in.
Unattended-Upgrade::Allowed-Origins {
        "${distro_id}:${distro_codename}";
"${distro_id}:${distro_codename}-security";
// Extended Security Maintenance; doesn't necessarily exist for
// every release and this system may not have it installed, but if
// available, the policy for updates is such that unattended-upgrades
// should also install from here by default.
"${distro_id}ESM:${distro_codename}";
// "${distro_id}:${distro_codename}-updates";
// "${distro_id}:${distro_codename}-proposed";
// "${distro_id}:${distro_codename}-backports";
};

// List of packages to not update (regexp are supported)
Unattended-Upgrade::Package-Blacklist {
// "vim";
// "libc6";
// "libc6-dev";
// "libc6-i686";
};

// This option will controls whether the development release of Ubuntu will be
// upgraded automatically.
Unattended-Upgrade::DevRelease "false";

// This option allows you to control if on a unclean dpkg exit
// unattended-upgrades will automatically run
//   dpkg --force-confold --configure -a
// The default is true, to ensure updates keep getting installed
//Unattended-Upgrade::AutoFixInterruptedDpkg "false";

// Split the upgrade into the smallest possible chunks so that
// they can be interrupted with SIGTERM. This makes the upgrade
// a bit slower but it has the benefit that shutdown while a upgrade
// is running is possible (with a small delay)
//Unattended-Upgrade::MinimalSteps "false";

// Install all unattended-upgrades when the machine is shutting down
// instead of doing it in the background while the machine is running
// This will (obviously) make shutdown slower
//Unattended-Upgrade::InstallOnShutdown "true";

// Send email to this address for problems or packages upgrades
// If empty or unset then no email is sent, make sure that you
// have a working mail setup on your system. A package that provides
// 'mailx' must be installed. E.g. "user@example.com"
//Unattended-Upgrade::Mail "root";

// Set this value to "true" to get emails only on errors. Default
// is to always send a mail if Unattended-Upgrade::Mail is set
//Unattended-Upgrade::MailOnlyOnError "true";

// Do automatic removal of new unused dependencies after the upgrade
// (equivalent to apt-get autoremove)
//Unattended-Upgrade::Remove-Unused-Dependencies "false";

// Automatically reboot *WITHOUT CONFIRMATION*
//  if the file /var/run/reboot-required is found after the upgrade
//Unattended-Upgrade::Automatic-Reboot "false";

// If automatic reboot is enabled and needed, reboot at the specific
// time instead of immediately
//  Default: "now"
//Unattended-Upgrade::Automatic-Reboot-Time "02:00";

// Use apt bandwidth limit feature, this example limits the download
// speed to 70kb/sec
//Acquire::http::Dl-Limit "70";

// Enable logging to syslog. Default is False
// Unattended-Upgrade::SyslogEnable "false";

// Specify syslog facility. Default is daemon
// Unattended-Upgrade::SyslogFacility "daemon";

Hugues

  • AS57199 MilkyWan
  • Expert
  • *
  • Messages: 6 267
  • Lyon & Paris
    • MilkyWan
Application patchs de sécurité
« Réponse #3 le: 14 novembre 2017 à 19:37:25 »
Tu trouves que reboot c'est une solution toi ? :D

mattmatt73

  • Expert.
  • Client Bbox fibre "câble"
  • *
  • Messages: 5 735
  • vancia (69)
Application patchs de sécurité
« Réponse #4 le: 14 novembre 2017 à 20:12:48 »
Question de padawan : comment font les sites à très hautes disponibilités pour garder des serveurs à jour sans couper pendant les reboot ?

Topologie actif/actif, frontal devant les serveurs distribuant la charge aux machines vivantes ?

Hugues

  • AS57199 MilkyWan
  • Expert
  • *
  • Messages: 6 267
  • Lyon & Paris
    • MilkyWan
Application patchs de sécurité
« Réponse #5 le: 14 novembre 2017 à 20:23:47 »
Oh y'a un paquet de technos pour ça, mais ouais c'est généralement un cluster, ça permet de tolérer les pannes mais aussi de scaler horizontalement

Leon

  • Client SFR sur réseau Numericable
  • Modérateur
  • *
  • Messages: 4 178
Application patchs de sécurité
« Réponse #6 le: 14 novembre 2017 à 20:30:18 »
Eh haute dispo, il y a aussi les mainframes, avec des procédures de maintenance et de mise à jour logicielle conçues pour maintenir le service H24 365j/an.
Les grosses baies de stockage (EMC²) et les gros routeurs de coeur de réseau sont également prévus avec ce genre de procédure. Dans le détail, je ne sais pas comment ça fonctionne, mais j'imagine qu'on profite de la redondance matérielle pour faire la mise à jour sur une carte, puis sur une autre, etc...

Leon.

vivien

  • Administrateur
  • *
  • Messages: 29 187
    • Twitter LaFibre.info
Application patchs de sécurité
« Réponse #7 le: 14 novembre 2017 à 20:40:29 »
Tu trouves que reboot c'est une solution toi ? :D
Il y a la solution de ne jamais rebooter, mais j'ai vu pas mal de souci le jour ou tu reboot, car la conf dans les fichiers ne correspond pas toujours à celle utilisée.

Bref, c'est deux philosophie différentes.

Il y en a une troisième dans certaines boites : Ne pas faire de mise à jour et mettre un firewall physique qui inspecte tout ce qui est adressé au serveur. C'est faire reposer la sécurité sur le firewall et non le serveur...

miky01

  • Expert. Réseau RESO-LIAin (01)
  • Client K-Net
  • *
  • Messages: 3 940
  • Farges (01)
Application patchs de sécurité
« Réponse #8 le: 14 novembre 2017 à 22:33:50 »
Eh haute dispo, il y a aussi les mainframes, avec des procédures de maintenance et de mise à jour logicielle conçues pour maintenir le service H24 365j/an.
Les grosses baies de stockage (EMC²) et les gros routeurs de coeur de réseau sont également prévus avec ce genre de procédure. Dans le détail, je ne sais pas comment ça fonctionne, mais j'imagine qu'on profite de la redondance matérielle pour faire la mise à jour sur une carte, puis sur une autre, etc...

Leon.

Dans les bays THD tu as toujours 2 controleurs qui ont chacun 2 banques pour le FW/OS, quant tu fais un update, c'est le controleur de backup qui bosse, et si tu cartonne le controleur principal, il redémare  sur son OS avec  la version précédante, en fait les MAJ se font en 2x sans interuptions, et tres souvent les bays sont en mirroir, et dans des salles ou site différent, pour les exigent, donc si par la faute a pas de chance tu la plante (ce qui reste des cas tres rare), ca tourne sur le miroir sans bretelles en attendant de resynchroniser le miroir.

Bon les incidents imprévus ca arrive toujours, comme la fois ou un tech qui a appuyé sur le champigon "arret d'urgence" en croyant que c'était le bouton pour ouvrir la porte du DC,  500 machines arretées....  ;D

butler_fr

  • Client Bbox adsl
  • Modérateur
  • *
  • Messages: 3 093
  • ADSL sur Marseille (13)
Application patchs de sécurité
« Réponse #9 le: 15 novembre 2017 à 09:22:23 »
joli!  ;D

ne pas mettre le champignon trop proche des portes la prochaine fois + gros panneau rouge clignotant ne pas toucher ^^

 

Mobile View