Jump to content
Règlement du forum ×
IPTV et arnaques ×

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

    • selem ahlikoum que pensez vous de cette technique qu'on m'a conseillé en france pour me connecter en algérie   Si tu as toujours un appart en France c'est hyper simple avec wireguard. Tu actives le port forward sur ta box (orange, sfr etc...) pour le port wireguard (51820) Tu branches un serveur VPN sur ta box (je conseille un Glinet Brume2, hyper simple a mettre en place) Tu prends un routeur exclusivement connecté sur le serveur VPN en tant que client (je suggéres un glinet Berylax, encore une fois configurable en quelques clics) Tu connectes ton PC du taf sur ton routeur client et voila ton trafic sort en France depuis ton appart ou que tu sois dans le monde
    • Bonjour, A noter que cette carte existe depuis des années sur ForumDZ à cette adresse dans l'onglet "Carte de couverture mobile" : https://www.forumdz.com/debit/ Vous pouvez également y faire un speedtest
    • Bonsoir laliche; Comme toujours des sujets intéressants.  
    • Les données proviennent de l’application nPerf, téléchargeable sur smartphone. Les utilisateurs de l’application effectuent des mesures en conditions réelles, contribuant ainsi à la création d’une base de données collaborative. Plus il y a d’utilisateurs de l’application nPerf, plus les données collectées seront nombreuses et précises. La participation de chacun est donc essentielle pour enrichir la carte et offrir une meilleure représentation des débits mobiles en Algérie. Fiabilité et précision Les mesures sont réalisées sur les terminaux des utilisateurs et la précision de la géolocalisation dépend de la qualité du signal GPS. Des règles de filtrage strictes sont appliquées pour garantir la fiabilité des données publiées : Couverture réseau: Seules les mesures avec une précision de géolocalisation inférieure à 50 mètres sont conservées. Débits mobiles: Seules les mesures avec une précision de géolocalisation inférieure à 200 mètres sont prises en compte.
    • Sur votre modem vous avez accès à deux réseaux Wi-Fi : un à 5 GHz et un autre à 2.4 GHz. Le réseau à 5 GHz permet d'éviter bon nombre d'interférences avec d'autres appareils électroniques et bénéficie d'un débit plus élevé. Sachez cependant que celui-ci bénéficie d'une portée bien plus courte que le 2.4 GHz. Il est donc plus utile de vous en servir lorsque vous êtes proches de votre modem. Chaque réseau Wi-Fi occupe une bande de fréquences particulière. Cette bande peut déjà être occupée par d'autres appareils électroniques comme un four micro-ondes, la box de vos voisins, un baby phone,…Dans ces conditions, vous pourriez donc améliorer la qualité de votre réseau en changer de canal en modifiant celui-ci dans la configuration et les paramètres de votre modem. Chaque opérateur dispose d'un processus particulier, mais cette manipulation est généralement assez simple. L'application Wifi Analyzer permet de trouver les canaux non encombrés dans votre voisinage  
×
×
  • Create New...