Auteur Sujet: Statistiques du serveur de mise à jour Ubuntu par défaut pour la France (Lu 19041 fois)

vivien · « **Réponse #12 le:** 27 avril 2017 à 15:35:01 »

Canonical Livepatch Service est limité à 3 machines par identifiant.

Il ne gère pas le kernel des Hardware Enablement Stack... (je suis en Kernel 4.8 sur un LTS 16.04)

Bref c'est utile mais je ne l'utilise pas.

Hugues · « **Réponse #13 le:** 27 avril 2017 à 15:48:36 »

Pourquoi utiliser l'Hardware Enablement Stack ? Autant passer en non LTS dans ce cas...

vivien · « **Réponse #14 le:** 27 avril 2017 à 19:23:49 »

Pour que ceux qui nous lisent comprennent, il y a 3 type de cycles qu'il est possible de suivre chez Ubuntu :

- Ubuntu server LTS => On reste deux ans avec le même kernel (4.4 pour Ubuntu 16.04). Il y a un support de 5ans, on n'est pas obligé d'upgrader tout de suite à la sortie de la version suivante.

- Ubuntu server LTS avec Enablement Stacks => On profite des améliorations de performances des nouveaux Kernel, en changant automatiquement de Kernel tous les 6 mois. Ubuntu 16.04 et 16.04.1 utilise le kernel 4.4, Ubuntu 16.04.2 le kernel 4.8, Ubuntu 16.04.3 le kernel 4.10, Ubuntu 16.04.4 un kernel à définir. Le support reste de 5 ans et il est possible de supprimer facilement Enablement Stacks.
A noter que les kernel sont utilisés pendant 3 mois dans les version Ubuntu classiques avant d'être mis dans Enablement Stacks. Il ne devrait donc pas y avoir de gros bugs.

- Ubuntu server => Il est nécessaire d'upgrader le système d’exploitation tous les 6 mois. Le support d'une version se termine 3 mois après la sortie de la version suivante. Cela laisse très peu de marge de manœuvre pour décaler un upgrade. Il faut donc éviter ce type d'OS en prod.

Bref, j'utilise presque systématiquement Enablement Stacks sur mes serveurs, car cela permet de profiter des améliorations des nouveaux noyaux sans prendre le moindre risque. Par exemple pour ce forum, toujours pas compatible PHP7, j'aurais été embêté si j'étais obligé d'upgrader tous les 6 mois.

vivien · « **Réponse #15 le:** 27 avril 2017 à 19:32:45 »

Comment activer Enablement Stacks ?

Ubuntu et dérivé (avec interface graphique)

sudo apt install --install-recommends linux-generic-hwe-16.04 xserver-xorg-hwe-16.04

On passe alors dans le dernier noyau (le 4.8 actuellement, le 4.10 en juillet après avoir été utilisé 3 mois par Ubuntu 17.04) mais aussi dans la dernière pile graphique, celle de Ubuntu 16.10 actuellement (En juillet, ce sera celle d'Ubuntu 17.04) permettant des amélioration de performances.

Ubuntu Server (sans interface graphique)

sudo apt install --install-recommends linux-generic-hwe-16.04

Comment désactiver Enablement Stacks ?

Ubuntu et dérivé (avec interface graphique)

sudo apt purge linux-generic-hwe-16.04 xserver-xorg-hwe-16.04

Ubuntu Server (sans interface graphique)

sudo apt purge linux-generic-hwe-16.04

Hugues · « **Réponse #16 le:** 27 avril 2017 à 19:33:10 »

Ok, je comprends ton choix

Perso j'essaie d'être le plus à jour sur les serveurs non critiques, donc j'ai déjà une bonne partie en Zesty, même si la majorité reste en Xenial (avec du livepatch sur tous !)

vivien · « **Réponse #17 le:** 27 avril 2017 à 19:42:41 »

Je n'ai aucun serveur en Zesty (Ubuntu 17.04) par contre tous mes PC (interface graphique) pour mon utilisation sont en Zesty.
Les PC de mes connaissances par contre reste en LTS, une upgrade tous les 2 ans, c'est largement suffisant.

Pour le livepatch tu payes le service ?

(cliquez sur la miniature ci-dessous - le document est au format PDF)

Quand-est ce que Debian va sortir ça ? Cela permettrait de se différencier (aujourd'hui toutes les distrib que le proposent le font payer)

Hugues · « **Réponse #18 le:** 27 avril 2017 à 20:54:15 »

Citation de: vivien le 27 avril 2017 à 19:42:41

Pour le livepatch tu payes le service ?

*tousse* j'ai un très bon système d'alias mail *tousse*

vivien · « **Réponse #19 le:** 30 avril 2017 à 07:03:35 »

Citation de: vivien le 27 avril 2017 à 14:21:06

Je viens de rajouter deux mesures de protections supplèmentaires : (je suis preneur de vos autres idées)

# Temps pendant lequel le serveur va attendre certains évènements avant de considérer # qu'une requête a échoué. Lors de la lecture de données en provenance du client, # c'est le temps maximum jusqu'à l'arrivée d'un paquet TCP si le tampon est vide. # Défaut: TimeOut 60 # Réduire le TimeOut a 30 secondes, permet de limiter le temps maximum pendant # lequel Apache httpd va attendre des entrées/sorties, lors des attaques de slow DDOS. Timeout 30 # Spécifie le délai maximum après lequel le serveur va s'arrêter dans le cas d'un arrêt "en douceur" # Défaut: GracefulShutdownTimeout 0 => le serveur va attendre jusqu'à ce que toutes les requêtes en cours aient été traitées. # Réduire le GracefulShutdownTimeout a une heure (3600 secondes) permet de réduire certains attaques slow DDOS. # Réduire cette valeur en dessous d'une heure peut poser problème pour des clients avec du bas débit # Une connexion a 400 Kb/s (50 Ko/s) est en mesure de télécharger 180 Mo en une heure. GracefulShutdownTimeout 3600

Le gain du timeout à 30 secondes est impressionnant => plus de slow DDOS depuis sa mise en place le 27 en milieu de journée.

La valeur était de 300 secondes avant la modification.

vivien · « **Réponse #20 le:** 02 mai 2017 à 22:42:52 »

Nouvelles tentatives de mettre un Timeout 300 (en conservant GracefulShutdownTimeout 3600) :

No comment.

Je vais donc remettre :
- Timeout 30
- GracefulShutdownTimeout 3600

+ rajouter une nouvelle : KeepAliveTimeout 2
La valeur par défaut est de 5 secondes.

KeepAliveTimeout est la durée pendant laquelle le serveur va attendre une requête avant de fermer une connexion persistante

L'implèmentation des connexions persistantes dans HTTP/1.1 permet de faire plusieurs requêtes dans une même connexion TCP.

Avec KeepAliveTimeout 2, Apache va fermer 3 secondes plus tôt cette cette attente d'une nouvelle requête sur la même connexion TCP. Cela permet de libérer des ressources importantes, quand il y a de nombreux petit téléchargements effectués, comme les mises à jour qui sont checké char jour par tous les PC Ubuntu.

Si le serveur est très long pour enchaîner les requêtes, le seul impact sera l’obligation d'ouvrir une nouvelle connexion TCP. Ce cas devrait être très rare. Le Timeout restant lui à 30 secondes.

vivien · « **Réponse #21 le:** 09 janvier 2018 à 08:49:08 »

Nouveauté : il y a maintenant des statistiques temps réel sur le serveur.

=> Statistiques du serveur miroir Ubuntu "fr.archive.ubuntu.com"

J'ai essayé de donner une définition accessible au plus grand nombre des graphes.

vivien · « **Réponse #22 le:** 09 mai 2018 à 17:08:41 »

Statistiques de https://lafibre.info/ubuntu-stats/ le 9 mai 2018.

La hausse de trafic à partir de 0h26 est lié à la mise à jour des Kernel pour toutes les versions d'Ubuntu encore maintenu (excepté la nouvelle version 18.04 LTS qui avait déjà les correctifs et la version 18.10 en développement)

Le pic de 6h25 à 6h55 du matin (trafic moyen de près de 5 Gb/s pendant ces 30 minutes) puis de puis 7h25 à 7h55 est lié a des machines connectées 24h/24 : Par défaut elles vérifient les mises à jour (et pour certaines les télécharges et les installes, d'autres ne font que notifier de la présence de mises à jour sans les télécharger)

Environ 700 000 machines se connectent a ce serveur chaque jour pour récupérer les mises à jour de sécurité.

vivien · « **Réponse #23 le:** 09 mai 2018 à 20:13:47 »

La faille corrigé par la mise à jour de ce matin :

Windows, macOS, Linux et BSD partagent une même faille

Sécurité : Éditeurs de systèmes d'exploitation et d'hyperviseurs corrigent une faille de sécurité permettant à des pirates de crasher des systèmes ou de lire des données de la mémoire.
la rédaction de ZDNet

Windows, macOS, les principales distributions Linux, FreeBSD, VMware et Xen sur les processeurs AMD et Intel x86 sont affectés par un problème de sécurité causé par une mauvaise interprétation par les développeurs de la documentation de débogage des deux fournisseurs de processeurs.

Les éditeurs d'OS et d'hyperviseurs concernés ont publié mardi des correctifs pour une faille commune qui pourrait permettre à un attaquant authentifié de "lire des données sensibles en mémoire ou de contrôler des fonctions de bas niveau du système d'exploitation" selon le CERT.

Des exceptions mal gérées

Les correctifs sont disponibles auprès d'Apple, de DragonFly BSD, de FreeBSD, de Microsoft, de Red Hat, de SUSE Linux, d'Ubuntu, de VMware et de Xen. Dans le cas des distributions Linux, deux problèmes distincts affectent le noyau Linux et l'hyperviseur KVM du noyau. Des liens vers toutes les mises à jour disponibles sont disponibles dans l'avis du CERT.

Selon la description fournie par RedHat, la faille découle de la façon dont les systèmes d'exploitation et les hyperviseurs gèrent certaines fonctionnalités de débogage dans les processeurs modernes - dans le cas présent, la gestion des exceptions de débogage.

"Généralement, les exceptions sont levées à la limite de l'instruction, toutes les instructions avant celle causant l'exception sont autorisées à s'exécuter et celle causant l'exception est bloquée, de sorte que l'exécution peut reprendre une fois l'exception traitée" note RedHat.

"Dans quelques cas", un comportement inattendu peut se produire si certaines instructions telles que SYSCALL suivent les deux instructions d'exception MOV to SS ou POP to SS, précise le CERT.

Concernant un système d'exploitation Linux, la faille peut permettre à un attaquant de planter un système. Toutefois, la faille peut également permettre à un utilisateur invité KVM sans droits de "planter l'invité ou, potentiellement, d'augmenter ses privilèges."

Microsoft affirme que la vulnérabilité pourrait permettre à un attaquant d'exécuter du code arbitraire en mode noyau. "Pour exploiter cette vulnérabilité, un attaquant devrait d'abord se connecter au système. L'attaquant pourrait ensuite exécuter une application spécialement conçue pour prendre le contrôle d'un système affecté" souligne l'éditeur.

La faute à Intel et AMD ?

VMware signale que ses hyperviseurs ne sont pas affectés, au contraire d'autres de ses produits, potentiellement concernés, parmi lesquels VMware vCenter Server, VMware Data Protection et VMware vSphere Integrated Containers.

Le projet Xen indique que toutes les versions de Xen sont affectées, mais que la faille ne peut être exploitée que par des invités PV ou paravirtualisation. La virtualisation assistée par matériel (HVM) ne peut pas exploiter la faille.

Le CERT signale que ce problème semble avoir été causé par le fait que les développeurs du système d'exploitation ont mal géré ces exceptions.

Mais bien que les vulnérabilités ne soient pas dues au design des processeurs, l'interprétation erronée de l'exception était "due à l'interprétation d'une documentation existante potentiellement vague et à des conseils sur l'utilisation de ces instructions."

La vulnérabilité a été découverte par les chercheurs Nick Peterson d'Everdox Tech et Nemanja Mulasmajic de Triplefault.io qui présenteront leurs recherches lors de la BlackHat 2018.

"C'est une faille de sécurité sérieuse et un oubli de la part des fournisseurs de systèmes d'exploitation en raison d'une documentation floue et peut-être même incomplète sur les règles d'exception de l'instruction POP SS et de son interaction avec la sémantique des interruptions" commente le duo d'experts dans son rapport.

Source : ZD-Net, le 9 mai 2018 Par Liam Tung