Consommation script BASH

Salut à tous,

Voilà j'ai conçu un script shell pour serveur Linux qui veille sur la sécurité en scannant les fichiers hébergés, ce script en BASH tourne à l'aide d'une boucle infinie.

J'aimerais donc savoir si les répercutions sur les performances du serveur sont importantes ? Un shell BASH c'est connu pour être gourmand en ressources ?

Je pense qu'un script en python est plus approprié mais bon...

Salut Havoc , et bravo pour l'initiative,

Si tu veux mon avis , certes je n'ai pas testé ton script donc je donne juste un avis de principe:

Il vaut mieux que le script ne soit pas à boucle infinie, et qu'au lieu de ça il soit lancé périodiquement par cron job.

Bonne courage.

Salut Havoc , et bravo pour l'initiative,

Si tu veux mon avis , certes je n'ai pas testé ton script donc je donne juste un avis de principe:

Il vaut mieux que le script ne soit pas à boucle infinie, et qu'au lieu de ça il soit lancé périodiquement par cron job.

Bonne courage.

Oui j'ai pensé à cron justement ! Même si pour l'instant j'ai bricolé en utilisant une boucle infinie et un sleep pour une exécution périodique.

En faite mon script détecte les backdoors PHP du style C99Shell et DxShell et les supprimes automatiquement, ce qui n'arrange pas nos hackers locaux

Le truc, c'est que personnellement j'aurais préféré que le script se lance automatiquement à chaque upload de fichier via formulaire ou FTP. Comme les script des hebergeurs qui ajoutent de la pub aux pages uploadées.

Bonjour !

Un SHELL poura créer des problemes, surtout s'il est pas bien programmé,

Il poura detecter les Backdoors, mais aussi il poura mettre des problemes au niveau des scripts clients.

Solution : Faudra reconfigurer le php.ini en désactivant le shell_exec, sur desable function = maintenant les Backdoors sont inutiles.

ça réduit la consommation des resources du script SHELL. mieux qu'utiliser des resources.

ps : j'aimerai bien voir ce SHELL

Bonjour !

 

Un SHELL poura créer des problemes, surtout s'il est pas bien programmé,

Il poura detecter les Backdoors, mais aussi il poura mettre des problemes au niveau des scripts clients.

 

 

Solution : Faudra reconfigurer le php.ini en désactivant le shell_exec, sur desable function = maintenant les Backdoors sont inutiles.

 

ça réduit la consommation des resources du script SHELL. mieux qu'utiliser des resources.

 

 

ps : j'aimerai bien voir ce SHELL

Oui il créera surement des problèmes au scripts clients si ces derniers sont des C99Shell & Co

Pour ce qui est de cette phrase :

Solution : Faudra reconfigurer le php.ini en désactivant le shell_exec, sur desable function = maintenant les Backdoors sont inutiles

Il faut un paramétrage bien plus pointu pour se protéger et encore cela n'est pas toujours parfait.

Une vraie protection cela passe par :

- La désactivation d'un certains nombres de paramètres de PHP.

- Installer ET CONFIGURER le mod_security pour apache car la config initiale ne suffit pas.

- Configurer correcteur son serveur web et toutes les applications installées, ...etc.

- Améliorer la sécurisation de PHP à l'aide de systèmes tels que Suhosin (je pense qu'il n'y a aucun hosteur algérien qui s'en sert).

- Vérifier systématiquement le bulletins d'informations sur les nouvelles failles découvertes et se mettre à jour si besoin.

- Vérifier le continu du serveur... Hé oui ! Pour garantir la sécurité de son serveur l'hebergeur doit vérifier les applications web exploitées par ses clients et leur signaler les éventuelles failles de sécurités qu'elles pourraient contenir, c'est d'ailleurs une ligne de défense très importante et le principal trou de sécurité.

Normalement on sécurise un serveur autour d'une application web alors quand c'est de l'hebergement mutualisé cela devient délicat de sécuriser sans restreindre les possibilités offertes aux clients et risquer de causer des dysfonctonnement de leur application web.

- Faire des audits de sécurité ! Hé oui, se tester c'est le meilleur moyen de vérifier son niveau, il existe même des tests gratuits et sérieux.

Bref... Si tu crois que ce simple paramètre de PHP.INI résout le problème c'est totalement faux. La sécurité informatique cela ne s'improvise pas.

PS/ Pour le script, je finie son développement en suite on verra s'il est publiable ou pas.

Bonjour,

On a pas parlé de la sécurisation des serveurs,

On a parlé du script shell, la solution est de modifier le php.ini, sur desable function.

Cordialement,

Bonjour,

 

On a pas parlé de la sécurisation des serveurs,

On a parlé du script shell, la solution est de modifier le php.ini, sur desable function.

 

 

Cordialement,

On parle de backdoor PHP (C99Shell est un des plus connu) et la solution que tu as avancé n'est qu'illusoire (ou très incomplète).

Moi je pense à un monitoring du système de fichiers. Genre SI quelqu'un ajoute un fichier dans le /www/ alors faire un scan. Mais pour le faire il faudra installer iNotify (Patch kernel :S) donc ça devient plus qu'un script, et puis utiliser pyinotify.

Et les backdoors (BDS) leur système consiste a quoi alors.

Et les backdoors (BDS) leur système consiste a quoi alors.

Tu penses que le paramètre shell_exec empêche de parcourir les répertoires avec un backdoor PHP comme C99 ?

Le hacker peut très bien se contenter de lire tes scripts PHP et de récupérer les login et mots de passe de BD...etc. Il peut aussi uploader des fichiers.

Ce qui constitue toujours une menace critique.

Tu as tout un paramétrage supplémentaire à faire, déjà faudrait limiter l'accès aux fichiers des autres comptes clients en activant "open_basedir", installer le module "mod_security" et désactiver les autres fonctions sensibles (si en on a pas besoin) comme exec() et system()...etc.

Bref, en se disant que le paramètre "shell_exec" te protèges des danger d'un backdoor PHP c'est totalement faux, l'execution de commandes à distance n'est pas l'unique danger.

Tu penses que le paramètre shell_exec empêche de parcourir les répertoires avec un backdoor PHP comme C99 ?

Le hacker peut très bien se contenter de lire tes scripts PHP et de récupérer les login et mots de passe de BD...etc. Il peut aussi uploader des fichiers.

Ce qui constitue toujours une menace critique.

Tu as tout un paramétrage supplémentaire à faire, déjà faudrait limiter l'accès aux fichiers des autres comptes clients en activant "open_basedir", installer le module "mod_security" et désactiver les autres fonctions sensibles (si en on a pas besoin) comme exec() et system()...etc.

Bref, en se disant que le paramètre "shell_exec" te protèges des danger d'un backdoor PHP c'est totalement faux, l'execution de commandes à distance n'est pas l'unique danger.

C'est déja fait. si vous parlez de l'hébergeur.

On est sortie du sujet : Consommation script BASH !!

Why ?

On est sortie du sujet : Consommation script BASH !!

 

Why ?

C'est toi qui pose cette question ?

Petit rappel :

Solution : Faudra reconfigurer le php.ini en désactivant le shell_exec, sur desable function = maintenant les Backdoors sont inutiles.

C'est déja fait. si vous parlez de l'hébergeur.

Je ne parle pas de l'hebergeur... son serveur est déjà très bavard, on a pu s'en apercevoir hier quand il était encore hors-service.

il était pas en HS, mais le compte forumdz était en permission 700

vous avez vu la page de limite d'accès, normalement vous avez une idée entre serveur en hs et un compte en permission 700.

Mais bon on a du et pu remarquer votre comportement.

c'est un point marquer sur notre base de donnée.

Cordialement,

il était pas en HS, mais le compte forumdz était en permission 700

 

vous avez vu la page de limite d'accès, normalement vous avez une idée entre serveur en hs et un compte en permission 700.

 

Mais bon on a du et pu remarquer votre comportement.

 

c'est un point marquer sur notre base de donnée.

 

 

Cordialement,

Bon comme c'est mon thread, je vais me permettre de faire du hors-sujet (mes excuses aux membres).

Alors arrêtez la mauvaise foi, une erreur 403 ne relevant pas de la volonté du client c'est une cas d'hors-service. Toute situation où le site client est inaccessible est une situation d'hors-service, que cela soit causé par une panne ou par une opération de maintenance (mise à jour...etc.).