Question Comment arrêter et détecter la bombe à fourche


#include <stdlib.h>
#include <unistd.h>

int main()
{
   while(1)
      fork();
}

C'est le code d'une bombe à fourche.

Dans notre collège, nous nous connectons via le protocole de service client telnet i.e. Une centaine de systèmes sont connectés au serveur. Tout à coup, nous avons vu le serveur ralentir et, après un certain temps, il s'est écrasé. J'ai appris que Sombody a mis en œuvre une bombe à fourche.

Comment pouvons-nous détecter sur quel système la bombe est implémentée? Et comment pouvons-nous l'arrêter?

Une méthode consiste à limiter le nombre maximal de processus qu'un utilisateur peut posséder. Existe-t-il une méthode pour l'arrêter et savoir de quel système il a été implémenté?


13
2018-03-16 14:37


origine


Telnet? Sérieusement? Vous devriez vraiment utiliser SSH ... - ThiefMaster
Voir également Quelle est la meilleure façon de nettoyer après une bombe?. - Petr Pudlák
Voir également unix.stackexchange.com/q/64611/17609 - moooeeeep
eh bien, il a migré de SO mais une réponse pourrait être au niveau du noyau. certaines pièces ont été provisoirement réalisées mais aucune ne semble avoir été acceptée. Mon point est le suivant: comment le détecter: eh bien, tout le monde saura qu'il ne peut plus utiliser le système, alors le point de détection n'est peut-être pas le point clé. Comment récupérer? La réponse actuelle est reboot, je dirais: une façon de dire au noyau de ne lancer qu’un seul processus (celui que vous voulez nettoyer) et d’arrêter tous les autres. Cela pourrait être une fonctionnalité accessible uniquement dans la console système. - philippe lhardy


Réponses:


L'un des moyens consiste à limiter le nombre de processus qu'un utilisateur peut exécuter.

Connectez-vous simplement en tant que root et modifiez ce fichier pour ajouter des utilisateurs et configurer leur limite.

# vi /etc/security/limits.conf

Ajouter cette ligne au fichier

john hard nproc 10

Maintenant, l'utilisateur john ne peut créer que 10 processus.


16
2018-03-16 14:48



Je pense que vous devez redémarrer pour avoir les nouveaux paramètres dans /etc/security/limits.conf prendre effet. - Dan D.
Non, mais elles sont appliquées par PAM, elles ne s'appliquent donc qu'aux nouvelles connexions. - ThiefMaster


Pour arrêter une bombe à fourche, vous pouvez utiliser killall <name> tuer tous les processus de la bombe. Cependant, comme une bombe à fourche entraîne généralement une charge incroyablement élevée sur le système, vous risquez de ne pas pouvoir y accéder ou de l'exécuter. Donc, un redémarrage peut être nécessaire ou du moins beaucoup plus rapide.

Si chaque utilisateur possède son propre compte sur le système, vous pouvez simplement vérifier le répertoire personnel de chacun et rechercher l'exécutable. Les chances sont bonnes, il a également téléchargé le code source afin de le trouver ne devrait pas être trop difficile. Si c'était un compte partagé pour tous les étudiants, vous n'avez pas de chance. Surtout après que la session telnet ou ssh de l'utilisateur s'est terminée, vous n'avez aucune chance de savoir qui l'a démarré.

Cependant, au lieu de punir l'utilisateur qui a fait exploser cette bombe, vous devriez plutôt réparer la configuration du système pour désarmer les bombes à fourche. Vous pouvez définir des limites de processus par utilisateur en utilisant /etc/security/limits.conf et empêcher ainsi une bombe à fourche de devenir incontrôlable - par ex. seulement 50 processus une bombe à fourche ne fera pas beaucoup de dégâts.


14
2018-03-16 14:48



il est impossible de détecter à partir de quel système sa venue aa? - Rajesh M
@ user1670364: Ce que vous demandez n'est pas clair. Que voulez-vous dire par "sa venue"? Vous pouvez dire à quel utilisateur appartient le processus, que voulez-vous savoir d'autre? - David Schwartz
@DavidSchwartz Je veux dire qu'il est possible de détecter la bombe à fourche sur quel système elle est implémentée? - Rajesh M
@ user1670364: Si vous parlez du système qui exécute la bombe, c'est celui qui est lent. Si vous parlez de l'utilisateur responsable, c'est l'utilisateur qui possède les processus en cours d'exécution. - David Schwartz