# uname -a

Switch

Mot-clé -

Fil des billets

mercredi 14 octobre 2020

Redémarrer une machine lorsqu'un programme l'étouffe inopinément (Debian 10)

Par Mathieu le mercredi 14 octobre 2020, 12:40 - Hacks

Admettons que vous ayez une machine avec un programme bugué. Typiquement, un logiciel métier avec une fuite de mémoire, qui va pour une raison inconnue saturer la mémoire vive et provoquer son propre crash ou le crash des autres services sur la machine.

Vous pourriez lui mettre une limite de mémoire via /etc/security/limits.conf mais ça ne fera que planter le programme (segmentation fault) pour protéger les autres, et dans le cas d'un logiciel métier cela veut dire prendre ensuite d'autres actions, manuelles ou automatiques, via un système de monitoring approprié.

C'est vrai, le monitoring est la bonne solution quand on suit un logiciel aussi critique qu'un logiciel métier, mais dans le cas d'un logiciel qui doit "juste tourner", d'une équipe de maintenance réduite ou n'ayant pas la possibilité d'astreintes, une solution simple pour s'assurer que la machine tourne même en cas d'incident, c'est de redémarrer la machine lors d'un incident. Pour cela, on peut utiliser le programme watchdog.

Cela doit être fait avec motivations et circonspection, une analyse "post-mortem" doit suivre chaque reboot, dans le cas d'une tentative d'élévation de privilèges par Buffer Overflow, rien ne dit que l'attaque n'a pas réussie même si le système a redémarré.

Watchdog : Configuration

Watchdog s'installe via les paquets :

apt install watchdog

Il y a ensuite deux choses à configurer : les règles pour déclencher le reboot, et le mode de chargement du programme ("no actions" ou actif).

Dans mon cas, je voulais redémarrer si le serveur avait moins de 20% de RAM disponible, ce serveur tourne en permanence à 50% de consommation de RAM et n'est jamais sensé dépasser, ou alors c'est signe d'un problème, d'où le reboot à déclencher.

La configuration de watchdog se trouve dans /etc/watchdog.conf et fournit deux valeurs à régler : min-memory et allocatable-memory . Attention, ces valeurs sont à renseigner en taille de page RAM.

Pour identifier la taille des pages sur le système, utilisez la commande :

getconf PAGESIZE

Ensuite, un simple calcul permet d'identifier la valeur à mettre dans min-memory et allocatable-memory. Par exemple, pour un PAGESIZE de 4096 (4 kB), 2 GB (2048 MB) de RAM et 20% de ce total :

( 20 % * 2048 * 1000 ) / 4096

Une fois min-memory et allocatable-memory configurés, il convient de tester le trigger avant de le démarrer;

Les options de lancement se trouvent dans /etc/default/watchdog . Modifier watchdog_options pour y renseigner :

watchdog_options="-v --no-action"

Désactivez Watchdog du démarrage automatique, puis démarrez-le :

systemctl disable watchdog
service watchdog start

Vous en verrez la trace dans les logs via service watchdog status ou journalctl -f .

Watchdog : Activation

Si les essais sont concluants, retournez dans /etc/default/watchdog pour activer le module noyau. Cela évitera que Watchdog se fasse tuer par un processus quelconque (oom-killer par exemple) :

watchdog_module="softdog"

Si vous ne voulez laisser aucune chance pour éviter le reboot (par exemple si oom-killer a réussi à baisser la consommation de ram sous le seuil acceptable et que le reboot n'est plus nécessaire), rajoutez nowayout :

watchdog_module="softdog nowayout"

Attention, une fois chargé en nowayout, le module noyau restera actif même si watchdog est stoppé (légitimement ou non), le seul moyen de le retirer est de retirer softdog des modules noyau (via rmmod), ou de rebooter.

Activez ensuite watchdog :

systemctl enable watchdog
service watchdog start

watchdog doit être visible dans les modules noyau chargés :

lsmod | grep softdog

Sources

 

mercredi 10 juin 2015

Linux : déterminer la taille réelle d'un fichier creux

Par Mathieu le mercredi 10 juin 2015, 18:12 - Hacks

Pour référence, et parce que c’est parfois utile de connaître la taille réelle d’un fichier creux.

Pour afficher la taille déclarée :

$ ls -lh nomdufichier
-rw-r--r-- 1 root root 401G Jun 10 18:09 nomdufichier

Pour afficher la taille réelle :

$ du -h nomdufichier
60G    nomdufichier

Rappel : un fichier creux est un fichier dont la taille déclarée pour le système est différente de la taille effective sur le disque. C’est particulièrement utile pour créer des fichiers à écriture aléatoire (par exemple des fichiers téléchargés par P2P), ou des disques de machines virtuelles (qcow2, vmdk).

Un fichier creux s’obtient en déclarant un index de fin de fichier plus grand que la taille effectivement “remplie” par le fichier sur le disque.

lundi 25 novembre 2013

Un serveur au régime : faites tourner un serveur complet dans un mouchoir de poche

Par Mathieu le lundi 25 novembre 2013, 07:15 - Hacks

Introduction

Ce n’est pas la période pour les régimes et pourtant aujourd’hui, dans un billet volontairement cryptique aux non-initiés, je vais vous dévoiler les quelques secrets qui permettent à des nerds invétérés de donner vie à des machines ridiculement pauvres en RAM. Pour la beauté du geste, mais pas que.

Je me souviens que l’on s’est souvent moqué de moi quand je disais qu’avec 512 mégas de RAM on pouvait faire tourner un serveur complet mail+ftp+web+sql. En remplaçant quelques programmes, vous pouvez parfaitement faire tourner votre application web standalone, un noeud de CDN performant, un miroir FTP, ou un relais mail.

Cet article va simplement vous présenter des alternatives, et terminer avec quelques astuces plus générales. Le but est de remplacer notre célèbre LAMP par des solutions moins gourmandes en mémoire.

Remplacer Apache

Pour remplacer Apache, nous avons le choix entre Nginx et Lighttpd (Lighty).

Lighttpd est le serveur le plus léger au monde. Sa structure est très simple, et l’impact d’une connexion en mémoire est très faible.

Nginx est un serveur qui consomme un peu plus au démarrage, mais qui utilise une gestion intelligente de ses connexions ouvertes pour optimiser son impact mémoire.

Inconvénients : oubliez les .htaccess, préparez-vous à faire un peu de configuration pour remplacer votre “a2enmod php5”, et changez vos habitudes pour redémarrer les services.

Remplacer MySQL

Ce n’est pas facile de remplacer MySQL, tellement le nombre de programme qui en dépendent est conséquent. Cependant, si c’est possible, n’hésitez pas une seconde, voici les deux alternatives “lowcost” possibles :

SQLite : une base SQLite est simplement un fichier qui est chargé en mémoire au moment où l’on veut lire dedans. Pas de démon résident, pas d’impact lorsque la base est inactive. Par contre, préparez vous à attendre un peu si votre base est conséquente : lire des données en n’utilisant que le cache disque,  ça peut prendre du temps.

PostgreSQL : PostgreSQL est un peu le nouveau MySQL, mais en mieux. de faible impact mémoire au démarrage, doté de plus de fonctionnalités que MySQL et proposant de meilleures performances, il reste encore marginal mais a tout pour concurrencer les équivalents propriétaires comme Oracle. On peut l’utiliser dans un environnement limité, en configurant correctement les limites dans sa configuration.

Remplacer ProFTPd

Si vous proposez un hébergement, vous proposerez certainement un serveur FTP.

Si les utilisateurs du serveur sont des utilisateurs “de confiance” (ie : que vous connaissez), vous pouvez leur laisser utiliser le serveur SFTP fourni par le serveur SSH (à activer dans la configuration). De très faible impact mémoire, pour une meilleure sécurité et moins de configuration, le protocole SFTP est supporté par la majorité des clients FTP. C’est LA solution des flemmards pour mettre en place un serveur FTP.

Sinon, vous pouvez vous rabattre sur un VSFTPd, qui en plus de vous combler au niveau impact mémoire, vous comblera au niveau rapidité. Il gère aussi le FTPS.

Remplacer Postfix

Si vous n’utilisez pas la réception des mails et que vous ne faites que de l’envoi (avec ou sans smarthost), Exim vous comblera au moins autant que Postfix, vous proposant même sous Debian une interface de configuration “pour les nuls” : dpkg-reconfigure exim4-config.

Éviter la catastrophe

En cas de gonflement inattendu de la mémoire, et lorsque celle-ci commence à manquer, le système d’exploitation commence à sacrifier des programmes pour libérer de la RAM. C’est dommage, on aimerait éviter d’en arriver à de telles extrémités sur un serveur de production.

La solution est assez simple, bien qu’imparfaite : il suffit de rajouter de la SWAP. La SWAP est un fichier d’échange placé sur le disque dur, lorsque il n’y a plus de mémoire en RAM, une partie de la RAM est déchargée (ie copiée) sur la SWAP, pour laisser de la place aux programmes “actifs”. Bien entendu, cette mémoire déchargée devra être rechargée dès lors qu’un programme a besoin d’un bloc mémoire qui a été placé en SWAP, ralentissant le traitement à la vitesse des temps d’accès disque (pas cool).

Faire dormir tout le monde

Ce qui est pénible avec les serveurs, c’est la quantité de RAM qui est là, utilisée en permanence, pour finalement un seul pic d’utilisation. Si on pouvait récupérer la RAM des programmes qui n’interagissent pas avec l’extérieur, et ne les lancer que quand on en a besoin ? Inetd est fait pour ça !

Inetd c’est un “super démon” qui va écouter sur les ports demandés à la place des programmes, et qui va lancer les programmes pour traiter l’événement, dès lors qu’une connexion est ouverte sur un de ses ports d’écoute. On peut donc imaginer avoir un Lighttpd non lancé qui se fait réveiller lorsque Inetd reçoit une connexion sur le port 80. Lighttpd traite alors la requête et s’arrête immédiatement après, laissant la place pour d’autres programmes.

L’inconvénient ici vient des temps de traitement forcément plus longs qu’avec des démons résidents (démarrer le programme prend du temps).

Conclusion

Voilà, c’est à peu près tout, j’espère qu’avec ces petits changements dans votre configuration, vous aurez quelques pistes pour alléger votre serveur, si jamais l’expérience vous tente. ;)

mardi 5 novembre 2013

Cinq étapes pour créer un cheval de troie sous GNU/Linux

Par Mathieu le mardi 5 novembre 2013, 23:41 - Hacks

Contrairement à ce qu'on dit, créer des logiciels malveillants sous Linux est d'une simplicité enfantine. La sécurité d'un système ne repose pas sur le nombre de barrière qu'il peut vous placer mais sur la capacité des utilisateurs à avoir du recul sur leur machine.

Voici donc les cinq étapes pour créer un petit cheval de troie sur Linux. Rien d'exceptionnel, beaucoup d'autres l'ont fait avant moi, cet article est entièrement à but pédagogique.

1. Installation

C'est sans doute sur ce point que l'on pourrait imaginer les systèmes Linux plus fiables que les systèmes Windows : dans la plupart des cas les logiciels malveillant sous Linux sont installés par l'utilisateur, et non à son insu. Pas beaucoup de possibilités pour injecter dans des 0day présents sur des programmes Linux, ils sont rapidement patchés. Quoique.

Non, l'installation viendra certainement de l'utilisateur. On l'aidera un peu ceci dit. Le type d'installation déterminera le champ d'action et la capacité de dissimulation du trojan. Même si on ne peut pas vraiment parler de rootkit pour un programme lancé en zone utilisateur, on peut faire un excellent cheval de troie ou un keylogger sympa avec de simples privilèges utilisateur.

Que vous prêtiez votre session l'espace de dix minutes ou que vous cliquiez benoîtement sur un joli fichier-image-qui-en-est-pas-un, le résultat sera plus ou moins le même : le programme s'installera, première étape franchie.

Où il s'installera ? Ça dépend. S'il est root, le programme prendra ses aises dans les coin reculés de /proc ou /lib, là où vous n'irez pas le chercher. S'il est utilisateur, il se chargera quelque part dans un .machinchose, les fichiers cachés présents dans votre dossier utilisateur.

2. Démarrage

Avoir un fichier malveillant sur son ordinateur (à des fins purement scientifiques), ça arrive à tout le monde. Mais que celui-ci devienne létal en se lançant avec votre session, ça c'est une autre affaire. Comme sous Windows, il n'y a aucune difficulté à lancer un programme avec la session ou dans les services.

Pour les services, un petit patch dans /etc/rc.d/ ou /etc/rc.local et vous êtes partis pour la rigolade.

Pour les programmes utilisateur, une petite retouche dans .xsessionrc, le .login, ou le fichier de démarrage de votre environnement (gnome, kde, etc) fera amplement l'affaire.

3. Dissimulation

Un trojan, si on le trouve  c'est pas drôle, alors il faut le cacher un peu. Les fichiers cachés c'est bien pour un utilisateur lambda, mais pour un administrateur système il faudra trouver mieux. Quoique.

Les programmes qui se dissimulent le mieux sont des programmes qui se sont installés en root. Forcément, pour ce genre de programme, patcher le noyau pour se rendre invisible, modifier la commande "top" ou recompiler et installer ses propres paquets patchés est l'enfance de l'art, mais un programme utilisateur peut lui aussi installer sa petite mécanique secrète.

Par exemple, il peut modifier le PATH de l'utilisateur pour remplacer les programmes systèmes par les siens (genre ps, top, ou les outils de diagnostique réseau), trafiquant alors les sorties des programmes légitimes pour se rendre invisible.

4. Collecte d'informations

Là on pourrait penser que le système le plus sécurisé du monde empêche les application illégitimes de collecter des informations. En fait non.

Si vous êtes root, vous avez de toute façon accès à toutes les entrées et sorties que vous voulez.

Si vous êtes un programme utilisateur, vous avez accès aux informations que l'utilisateur soumet, ce qui et déjà largement suffisant pour lui voler ses mots de passe. Outre aller farfouiller dans les .config et les .mozilla, le gentil programme peut aussi profiter du mécanisme vieillissant fourni par le serveur graphique X, et capturer n'importe quelle frappe de touche en silence (si, si...).

5. Communication avec l'extérieur

Créer un tunnel réseau sous Linux est enfantin en utilisant un langage de haut niveau comme Python. Pour les autres, quelques read avec des socket fera amplement l'affaire. Le point délicat ici est le chiffrement. C'est toujours délicat d'implémenter une couche SSL sur les programmes. Une alternative est l'alternance entre un masque jetable et un décalage de bits, chacun d'une taille suffisante pour tromper le newbie qui snifferait des trames réseau à la recherche de ce qui fuite.

Conclusion

La création de programmes malveillant sous GNU/Linux est accessible à un élève de seconde année de licence Informatique, c'est à dire pratiquement n'importe qui. N'oubliez pas que ce que vous pouvez faire sur votre ordinateur, n'importe quel programme qui s'exécute avec vos droits d’utilisateur peut lui aussi le faire (skype ?).