Tag

kernel

Browsing

Voici un tutoriel qui vous permet de supprimer les kernels linux installés sur votre serveur/machine qui ne sont pas actuellement utilisés.

Cela est utile pour faire un peu de ménage sur la partition /boot, idéalement avant qu’elle ne soit complètement saturée. Sinon, je vous donne aussi l’astuce pour faire le ménage manuellement et retrouver APT complètement opérationnel.

Ce tutoriel a été testé sous Ubuntu Server 18.04 LTS, il est complètement transférable sous Ubuntu et Debian.

Cas de figure 1: /boot n’est pas plein à 100% et apt est opérationnel

1. On vérifie la version actuelle du kernel

uname -r

Cela nous donne la version du noyau sous laquelle tourne notre machine:

4.15.0-46-generic

2. On supprime les vieux kernels

2.a. On liste les vieux kernels

sudo dpkg --list 'linux-image*'|awk '{ if ($1=="ii") print $2}'|grep -v `uname -r`

You will get the list of images something like below:

linux-image-4.15.0-45-generic

2.b. On supprime les vieux kernels (un par un)

sudo apt purge linux-image-4.15.0-45-generic

Une fois que les vieux kernels sont supprimés, on supprime également les paquets qui seront maintenant obsolètes:

sudo apt autoremove

Et on finit par la mise à jour de la liste des noyaux de GRUB:

sudo update-grub

Voilà, il ne vous reste plus qu’à rebooter votre machine ou votre serveur. Il ne reste que le dernier kernel.

Cas de figure 2 : apt est indisponible car /boot est plein à 100%

NOTE: cette partie du tutoriel n’est valable que si et seulement si vous ne pouvez utiliser APT parce que la partition /boot est pleine à 100%.

1. Listez les images de kernel

Obtenez la liste des images de kernels et faites la liste des kernels que vous pouvez supprimer car ils ne sont plus utilisés. Cette commande vous montre les kernels installés à l’exception de celui qui est en cours d’utilisation:

sudo dpkg --list 'linux-image*'|awk '{ if ($1=="ii") print $2}'|grep -v `uname -r`

Voici le résultat de la commande, la liste des kernels installés mais inutilisés:

linux-image-3.19.0-59-generic
linux-image-3.19.0-61-generic
linux-image-3.19.0-65-generic
linux-image-extra-3.19.0-59-generic
linux-image-extra-3.19.0-61-generic
linux-image-extra-3.19.0-65-generic

2. Préparez la suppression

Vous devez préparer la commande qui va supprimer tous les kernels inutilisés en utilisant la brace expansion pour vous simplifier la vie. Je vous conseille d’écrire la commande dans un éditeur de texte et de bien la vérifier avant de la lancer dans le terminal.

N’oubliez pas d’exclure le kernel actuel ainsi que les deux kernels les plus récents pour pallier tout problème:

sudo rm -rf /boot/*-3.19.0-{59,61,65}-*

3. Nettoyez APT et ses messages d’avertissement à propos d’une installation partielle

sudo apt-get -f install

4. Autoremove

Enfin, on lance la commande autoremove pour supprimer les paquets relatifs aux vieilles images de kernel qui ont été rendues orphelines par le nettoyage manuel de /boot :

sudo apt autoremove

5. Mise à jour de GRUB

sudo update-grub

6. APT est opérationnel

Vous pouvez de nouveau utiliser APT et mettre à jour, installer et supprimer les paquets de votre distribution:

sudo apt update

Au début du mois de février, l’université de Graz et Google Project Zero ont annoncé avoir découvert deux failles de sécurité importantes s’appuyant sur les mécanismes de fonctionnement interne des processeurs.

Serveur dédié : mise à jour du kernel OVH pour combler les failles Spectre et Meltdown photo

Trois vulnérabilités permettant d’accéder à de la mémoire privilégiée ont été publiées, qui ont pour point commun d’exploiter les mécanismes d’exécution spéculative et les timings des caches mémoires.

Meltdown

La première faille, Meltdown (CVE-2017-5754), permet de bypasser les mécanismes d’isolation mémoire entre mémoire classique (utilisée par les applications) et mémoire kernel (utilisée par le noyau du système d’exploitation, et protégée normalement par des mécanismes hardware dans le CPU).

Meltdown est une attaque side channel permanent;qui s’attaque à une faille de certains processeurs OOO (Out Of Order, la plupart des processeurs performants modernes depuis le Pentium Pro) qui, dans leur mécanismes d’exécution spéculatifs, peuvent non seulement lire des données mémoires protégées mais aussi exécuter des instructions sur ces données mémoires.

Concrètement, avec Meltdown, il est possible de lire tout type de mémoire à partir d’un process malicieux, y compris côté serveur de bypasser toutes les protections de type VM/Hyperviseur/Docker. Meltdown touche spécifiquement les architectures d’Intel et ARM.

Spectre

En parallèle à Meltdown, une autre faille a été dévoilée baptisée Spectre. permanent;Pour Spectre, la situation est plus compliquée. Il s’agit toujours d’une variation sur le même thème, à savoir tenter d’exploiter les mécanismes d’exécution spéculative des processeurs. Tous les processeurs modernes sont concernés a différents niveau et l’on retrouve, y compris chez un même constructeur, des différences d’une architecture à l’autre en fonction des mécanismes précis de fonctionnement de chaque génération.

Le papier décrit deux attaques distinctes. La première, connue sous le nom de CVE-2017-5753 (bounds check bypass) permet à un processus d’accéder, dans certains conditions un peu plus complexes, à la mémoire d’un autre processus. Contrairement à Meltdown dont l’exploitation est triviale, il faut ici connaître les spécificités du programme que l’on attaque pour réussir à l’exploiter.

Le groupe Google Project Zero a montré que cette attaque était exploitable aussi bien sur les CPU Intel, AMD (FX et APU), et ARM (un Cortex A57 à été testé). Si tous les processeurs sont exploitables, c’est que tous les modèles OOO modernes reposent, dans les grandes lignes, sur l’algorithme de Tomasulo, du nom de l’ingénieur qui l’a développé en 1967 chez IBM.

Virtuellement, tous les systèmes (du serveur au smartphone) sont vulnérables à cette attaque pour laquelle des PoC existent même en Javascript (pour bypasser les barrières des VM qui isolent le code Javascript de vos différents onglets), ce qui la rend assez grave. Des méthodes de mitigations, aussi bien au niveau des compilateurs, des navigateurs, et des systèmes d’exploitations sont en cours de développement et des patchs sont attendus rapidement pour limiter le problème.

Vous pouvez retrouver les détails techniques des failles Spectre et Meltdown chez OVH.

Mon machine est-elle touchée par ces failles?

Il vous suffit de tester votre processeur avec le script Spectre & Meltdown Checker:

curl -L https://meltdown.ovh -o spectre-meltdown-checker.sh
chmod +x spectre-meltdown-checker.sh
sh ./spectre-meltdown-checker.sh

Résultat avant la mise à jour du kernel:

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking count of LFENCE opcodes in kernel:  NO 
> STATUS:  VULNERABLE  (only 46 opcodes found, should be >= 70, heuristic to be improved when official patches become available)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
*   Hardware (CPU microcode) support for mitigation:  NO 
*   Kernel support for IBRS:  NO 
*   IBRS enabled for Kernel space:  NO 
*   IBRS enabled for User space:  NO 
* Mitigation 2
*   Kernel compiled with retpoline option:  NO 
*   Kernel compiled with a retpoline-aware compiler:  NO 
> STATUS:  VULNERABLE  (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI):  NO 
* PTI enabled and active:  NO 
> STATUS:  VULNERABLE  (PTI is needed to mitigate the vulnerability)

Mise à jour du kernel OVH

Sur la Kimsufi, c’est le kernel OVH 4.9.87 qui intégre tous les correctifs Meltdown et Spectre, ainsi que la mise à jour du microcode pour les puces Intel.

Il suffit de suivre le tutoriel pour mettre à jour le noyau OVH.

Après mise à jour du noyau et redémarrage du serveur, les failles semblent maintenant comblées:

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking whether we're safe according to the /sys interface:  YES  (kernel confirms that the mitigation is active)
> STATUS:  NOT VULNERABLE  (Mitigation: __user pointer sanitization)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Checking whether we're safe according to the /sys interface:  YES  (kernel confirms that the mitigation is active)
> STATUS:  NOT VULNERABLE  (Mitigation: Full generic retpoline)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Checking whether we're safe according to the /sys interface:  YES  (kernel confirms that the mitigation is active)
> STATUS:  NOT VULNERABLE  (Mitigation: PTI)

Voilà, mettez vos noyaux à jour, c’est important.

Linux Mint Debian EditionLinux Mint Debian Edition (LMDE) est vraiment très stable et fonctionne avec des paquets éprouvés mais pas vraiment à jour. Si vous avez du matériel récent, il est possible qu’il ne soit pas détecté – c’est le cas du pavé tactile de mon ordinateur portable – à cause du noyau linux qui laggue un peu.

A l’heure où j’écris ces lignes, Linux Mint Debian Edition utilise le kernel 3.16 alors que le dernier en date est le 4.6.3… voyons comment on peut le mettre à jour.

Le kernel Liquorix

Linux Mint : mettre à jour le noyau linux avec le kernel liquorix photo 1Liquorix vient remplacer le noyau linux de votre distribution. C’est un noyau à jour, avec des configurations supplémentaires pour les ordinateurs de travail, le multimédia et les jeux vidéos.

Installation de Liquorix

On passe root :

sudo -i

On édite le fichier sources.list d’apt :

nano /etc/apt/sources.list

et on y ajoute :

# liquorix kernel
deb http://liquorix.net/debian sid main

On sauvegarde le fichier, on met à jour les paquets et on installe le keyring de Liquorix :

apt-get update && apt-get install '^liquorix-([^-]+-)?keyring.?'

On peut voir quels sont les derniers noyaux ajoutés sur le dépôt liquorix:

apt search liquorix

Ensuite, il vous suffit d’installer le dernier kernel en date:

apt-get install linux-image-liquorix-amd64 linux-headers-liquorix-amd64

Et on reboote la machine pour activer les changements. Le pavé tactile est miraculeusement actif après installation de ce kernel.

Ce noyau est stable et complémente très bien Linux Mint. Recommandé.

J’ai lamentablement fait planter le serveur en voulant mettre le kernel à jour…

Heureusement, il existe le mode rescue chez OVH qui permet d’installer un linux provisoire sur le serveur et d’initier une connexion SSH pour que l’on puisse réparer le système.

Si jamais cela vous arrive, voici la marche à suivre.

Passage en mode rescue depuis le manager OVH

lifesaver

1. Aller sur le manager OVH > Dedicated > Infrastructure > clic sur votre serveur > clic sur l’onglet Server Status.

Sommaire de la série Monter un serveur dédié de A à Z

  1. Serveur dédié : installation d’Apache, PHP, MySQL et Webmin
  2. Serveur dédié : créer la base de données MySQL et importer WordPress
  3. Serveur dédié : créer et activer un Virtual Host sous Apache
  4. Serveur dédié : changer les DNS du nom de domaine et le faire pointer vers le serveur
  5. Serveur dédié : sécurisation des services avec iptables et fail2ban
  6. Serveur dédié : sécurisation de la couche TCP/IP
  7. Serveur dédié : création d’un serveur mail Postfix (sécurisé avec Saslauthd et certificat SSL) et Courier (accès POP et IMAP) utilisant une base MySQL d’utilisateurs/domaines virtuels
  8. Serveur dédié : sécuriser Apache 2 avec ModSecurity
  9. Serveur dédié : CHMOD récursif sur des fichiers ou répertoires en ligne de commande
  10. Serveur dédié : installer APC comme système de cache et configurer Varnish comme reverse-proxy pour Apache pour améliorer les performances
  11. Serveur dédié : afficher la véritable IP derrière un reverse-proxy comme Varnish
  12. Serveur dédié : intégrer SSH à WordPress pour mettre à jour le core, les plugins et les thèmes
  13. Serveur dédié : installer la dernière version d’APC par SVN
  14. Serveur dédié : analyse des performances du serveur
  15. Serveur dédié : mettre à jour le noyau Debian de la Kimsufi
  16. Serveur dédié : sauvegarde automatique des fichiers avec Backup Manager sur le serveur de sauvegarde OVH
  17. Serveur dédié : configurer la limite mémoire pour PHP et Suhosin
  18. Bash : supprimer tous les fichiers et sous-répertoires d’un répertoire
  19. Serveur dédié : impossible de se connecter à un port distant
  20. Rsync: rapatrier les fichiers du serveur à la maison
  21. Bash : réparer les tables MySQL en cas de crash
  22. Serveur dédié : création d’une seedbox avec Transmission
  23. Serveur dédié : des paquets LAMP à jour sous Debian
  24. Serveur dédié : mise à jour vers Debian 7 Wheezy
  25. Serveur dédié : activer X11 forwarding pour SSH
  26. Serveur dédié : optimiser toutes les images JPG et PNG avec OptiPNG et JpegOptim
  27. Postfix : résoudre l’erreur “fatal: www-data(33): message file too big”
  28. Serveur dédié : mise en place de l’IPv6
  29. WordPress : accorder les bonnes permissions aux fichiers et dossiers avec chown et chmod
  30. WordPress : héberger les images sur un sous-domaine
  31. Serveur dédié : ajouter l’authentification SPF, Sender-ID et DKIM à Postfix et Bind9 avec opendkim
  32. Apache : lorsque le domaine seul (sans WWW) renvoie une erreur 403
  33. Serveur dédié : sécuriser Apache avec HTTPS (HTTP avec la couche TLS/SSL) en Perfect Forward Secrecy
  34. Serveur dédié : passer WordPress en HTTPS (TLS/SSL)
  35. Serveur dédié : configurer Webmin en TLS avec un certificat SSL
  36. Serveur dédié : configurer Transmission pour accéder au WebUI via TLS-SSL
  37. Serveur dédié : installer et configurer Varnish 4
  38. Serveur dédié : passage au mod FastCGI et PHP-FPM avec Apache MPM Worker
  39. Récupérer un serveur Kimsufi après un plantage de kernel avec le mode rescue OVH
  40. Serveur dédié : configurer Postfix et Courier pour utiliser TLS-SSL en Perfect Forward Secrecy
  41. Serveur dédié : retirer Varnish, devenu inutile avec HTTPS
  42. Serveur dédié : installer la dernière version d’OpenSSL sous Debian
  43. Serveur dédié : activer l’IP canonique du serveur sous Apache
  44. Serveur dédié : mise à jour vers PHP 5.6
  45. MySQL : convertir les tables MyISAM au format InnoDB
  46. Serveur dédié : optimiser toutes les images GIF avec GIFsicle
  47. Serveur dédié : migration de MySQL vers MariaDB
  48. BASH : lister, bloquer et débloquer des adresses IP avec iptables
  49. Serveur dédié : produire une meilleure réserve d’entropie avec haveged
  50. Serveur dédié : mettre en place DNSSEC pour sécuriser les DNS du domaine
  51. Serveur dédié : mise en place du protocole DANE
  52. 8 règles d’or pour bien déployer DNSSEC et DANE
  53. Serveur dédié : installer PHP7 FPM avec FastCGI sous Debian
  54. Serveur dédié : réduire les connexions TIME_WAIT des sockets et optimiser TCP
  55. Fail2Ban: protéger Postfix contre les attaques DoS de types AUTH, UNKNOWN et EHLO
  56. Serveur dédié : mettre à jour Apache et configurer le mod_http2 pour HTTP/2
  57. Serveur dédié : ajouter le domaine à la liste HSTS preload
  58. Serveur dédié : ajouter l’authentification DMARC à Postfix et BIND
  59. Serveur dédié : à la recherche de l’inode perdue ou comment résoudre le problème “no space left on device”
  60. Serveur dédié : installer NginX avec support HTTP2 et certificat SSL, PHP, MariaDB sous Debian

Aujourd’hui, on met à jour le noyau linux de notre installation Debian sur notre Kimsufi.

Un noyau à jour, c’est toujours mieux pour bénéficier des derniers patchs/améliorations/correctifs de sécurité du noyau.

OVH compile ses propres noyaux, offrant différentes options. Nous choisirons le noyau avec GRS : grsecurity est un correctif de sécurité pour le noyau incluant PaX, un système de contrôle d’accès à base de rôles et différents moyen de renforcer la sécurité générale du noyau.

Téléchargement du dernier noyau linux chez OVH

Une fois loggés en SSH, on se place dans le répertoire /boot :

cd /boot

On regarde ensuite la liste des noyaux linux modifiés par OVH pour les Kimsufi : ftp://ftp.ovh.net/made-in-ovh/bzImage/.

On récupère 2 fichiers : le fichier bzImage et le fichier System.map associé. Pour mon serveur, je prends les versions -grs-ipv6-64 : certaines mesures de sécurité sont incluses dans le noyau made in OVH (-grs), avec support de l’ipv6 sur un système 64 bits.

Nous prenons donc la dernière version du noyau ici : ftp://ftp.ovh.net/made-in-ovh/bzImage/latest-experimental/:

wget ftp://ftp.ovh.net/made-in-ovh/bzImage/latest-experimental/System.map-4.1.7-xxxx-grs-ipv6-64
wget ftp://ftp.ovh.net/made-in-ovh/bzImage/latest-experimental/bzImage-4.1.7-xxxx-grs-ipv6-64
wget ftp://ftp.ovh.net/made-in-ovh/bzImage/latest-experimental/config-4.1.7-xxxx-grs-ipv6-64

Sommaire de la série Monter un serveur dédié de A à Z

  1. Serveur dédié : installation d’Apache, PHP, MySQL et Webmin
  2. Serveur dédié : créer la base de données MySQL et importer WordPress
  3. Serveur dédié : créer et activer un Virtual Host sous Apache
  4. Serveur dédié : changer les DNS du nom de domaine et le faire pointer vers le serveur
  5. Serveur dédié : sécurisation des services avec iptables et fail2ban
  6. Serveur dédié : sécurisation de la couche TCP/IP
  7. Serveur dédié : création d’un serveur mail Postfix (sécurisé avec Saslauthd et certificat SSL) et Courier (accès POP et IMAP) utilisant une base MySQL d’utilisateurs/domaines virtuels
  8. Serveur dédié : sécuriser Apache 2 avec ModSecurity
  9. Serveur dédié : CHMOD récursif sur des fichiers ou répertoires en ligne de commande
  10. Serveur dédié : installer APC comme système de cache et configurer Varnish comme reverse-proxy pour Apache pour améliorer les performances
  11. Serveur dédié : afficher la véritable IP derrière un reverse-proxy comme Varnish
  12. Serveur dédié : intégrer SSH à WordPress pour mettre à jour le core, les plugins et les thèmes
  13. Serveur dédié : installer la dernière version d’APC par SVN
  14. Serveur dédié : analyse des performances du serveur
  15. Serveur dédié : mettre à jour le noyau Debian de la Kimsufi
  16. Serveur dédié : sauvegarde automatique des fichiers avec Backup Manager sur le serveur de sauvegarde OVH
  17. Serveur dédié : configurer la limite mémoire pour PHP et Suhosin
  18. Bash : supprimer tous les fichiers et sous-répertoires d’un répertoire
  19. Serveur dédié : impossible de se connecter à un port distant
  20. Rsync: rapatrier les fichiers du serveur à la maison
  21. Bash : réparer les tables MySQL en cas de crash
  22. Serveur dédié : création d’une seedbox avec Transmission
  23. Serveur dédié : des paquets LAMP à jour sous Debian
  24. Serveur dédié : mise à jour vers Debian 7 Wheezy
  25. Serveur dédié : activer X11 forwarding pour SSH
  26. Serveur dédié : optimiser toutes les images JPG et PNG avec OptiPNG et JpegOptim
  27. Postfix : résoudre l’erreur “fatal: www-data(33): message file too big”
  28. Serveur dédié : mise en place de l’IPv6
  29. WordPress : accorder les bonnes permissions aux fichiers et dossiers avec chown et chmod
  30. WordPress : héberger les images sur un sous-domaine
  31. Serveur dédié : ajouter l’authentification SPF, Sender-ID et DKIM à Postfix et Bind9 avec opendkim
  32. Apache : lorsque le domaine seul (sans WWW) renvoie une erreur 403
  33. Serveur dédié : sécuriser Apache avec HTTPS (HTTP avec la couche TLS/SSL) en Perfect Forward Secrecy
  34. Serveur dédié : passer WordPress en HTTPS (TLS/SSL)
  35. Serveur dédié : configurer Webmin en TLS avec un certificat SSL
  36. Serveur dédié : configurer Transmission pour accéder au WebUI via TLS-SSL
  37. Serveur dédié : installer et configurer Varnish 4
  38. Serveur dédié : passage au mod FastCGI et PHP-FPM avec Apache MPM Worker
  39. Récupérer un serveur Kimsufi après un plantage de kernel avec le mode rescue OVH
  40. Serveur dédié : configurer Postfix et Courier pour utiliser TLS-SSL en Perfect Forward Secrecy
  41. Serveur dédié : retirer Varnish, devenu inutile avec HTTPS
  42. Serveur dédié : installer la dernière version d’OpenSSL sous Debian
  43. Serveur dédié : activer l’IP canonique du serveur sous Apache
  44. Serveur dédié : mise à jour vers PHP 5.6
  45. MySQL : convertir les tables MyISAM au format InnoDB
  46. Serveur dédié : optimiser toutes les images GIF avec GIFsicle
  47. Serveur dédié : migration de MySQL vers MariaDB
  48. BASH : lister, bloquer et débloquer des adresses IP avec iptables
  49. Serveur dédié : produire une meilleure réserve d’entropie avec haveged
  50. Serveur dédié : mettre en place DNSSEC pour sécuriser les DNS du domaine
  51. Serveur dédié : mise en place du protocole DANE
  52. 8 règles d’or pour bien déployer DNSSEC et DANE
  53. Serveur dédié : installer PHP7 FPM avec FastCGI sous Debian
  54. Serveur dédié : réduire les connexions TIME_WAIT des sockets et optimiser TCP
  55. Fail2Ban: protéger Postfix contre les attaques DoS de types AUTH, UNKNOWN et EHLO
  56. Serveur dédié : mettre à jour Apache et configurer le mod_http2 pour HTTP/2
  57. Serveur dédié : ajouter le domaine à la liste HSTS preload
  58. Serveur dédié : ajouter l’authentification DMARC à Postfix et BIND
  59. Serveur dédié : à la recherche de l’inode perdue ou comment résoudre le problème “no space left on device”
  60. Serveur dédié : installer NginX avec support HTTP2 et certificat SSL, PHP, MariaDB sous Debian

Deuxième gros souci avec Ubuntu Karmic Koala : le son qui est coupé, saccadé ou qui grésille. Très difficilement supportable…

alsaSi vous lisez ce site depuis quelques temps, je vais finir par donner l’impression qu’Ubuntu ou mon système sont instables alors qu’il n’en est rien !

Le problème : le son se coupe ou est saccadé

Mais revenons à mon mouton : je mets à jour Ubuntu en 9.10 (Karmic). Un reboot, deux reboots, tout fonctionne. Je lance une vidéo Youtube, le son est bon. Je lance un fichier son en même temps : Totem se fige au démarrage et le son n’est pas lu. J’essaie avec VLC, même histoire.

Donc on ne peut lire un son flash et un son sur le PC simultanément. Les haut-parleurs “claquent” également de temps en temps (très désagréable). Le son grésille à certains moments sans que l’on sache pourquoi (sous Wine et en natif sous Ubuntu).