Jump to content

Consommation script BASH


Guest HAVOC

Recommended Posts

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...

Link to post
Share on other sites

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. :)

Link to post
Share on other sites
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 :D

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.

Link to post
Share on other sites

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

Link to post
Share on other sites
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 :D

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
Cela ne te protège pas des dangers d'un C99, désactiver le paramètre shell_exec ne rend pas les backdoors php inoffensifs.

 

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.

Link to post
Share on other sites
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).

Link to post
Share on other sites
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.

Link to post
Share on other sites
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.

Link to post
Share on other sites
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. :rolleyes:

Link to post
Share on other sites

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,

Link to post
Share on other sites
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.).

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.



  • Posts

    • @sonic584 on l'a deja constanté à plusieurs reprises....quand des stats sont CATASTROPHIQUE, ca ne peut venir que de chez eux !!!!!! travaux, dechirure, configuration pourrie etc... logique non ?
    • Bonjour, Depuis quelque jours les stats de mes parents sont catastrophiques, des marge snr toutes pourries, beaucoup d'erreurs... J'ai essayé de changer le type de synchro en gdmt, mais la le débit est bridé à environs 2M, alors que dorénavant ils ont 4! Svp avez vous des conseils à me donner pour améliorer un chwiya ces stats? en sachant qu'il ont un Dlink2790U? (Dlink qui est bcp plus sensible que ces homologues TP Link) Merci d'avance PS: La ligne est toute pourrie, mais pas trop éloignée du dslam (moins de 500M) La seconde image c'est les stats en GDMT
    • @fourwinds c'est rapide cette fois. Dis tu avais (avant promo ramadan de 1 ou 2 mois ) profité des bonus e-paiement ou recharges idoom ? je demande, car AT m'a dit que zaama en 6 mois on ne peut pas avoir plus d'un certain nombre de bonus... du coup j'avais profité entre janvier et mars de 3 bonus (l'affaire des 6 jours)...et je flippe a "ne pas avoir DROIT" au bonus ramadan
    • @Kooldib  je crois que c'est fichu amigo; mais bon j'ai deja dit des centaines de fois que le modem joue un role dans les stats...j'ai essayé 4 : 2 etaient identiques en stats et 2 etaient differents...a la fin j'ai revendu 2...rendu celui qu'on ma preté et gardé le meilleur... je le répète : le meilleur chez moi ne veut pas dire le meilleur chez toi ! donc si tu es deseperé...prends le risque et achetes/empreuntes 4 modems...
    • @Kooldib j'ai posté une reponse dans le bon topic... ici c'est discussion 20 megas  
×
×
  • Create New...