Programme en tache de fond après arret script
Fermé
theclem35
-
6 févr. 2012 à 23:06
kevin76110 Messages postés 4273 Date d'inscription vendredi 14 août 2009 Statut Membre Dernière intervention 27 mars 2013 - 7 févr. 2012 à 21:23
kevin76110 Messages postés 4273 Date d'inscription vendredi 14 août 2009 Statut Membre Dernière intervention 27 mars 2013 - 7 févr. 2012 à 21:23
A voir également:
- Taches de fond de la protection du systeme microsoft
- Restauration du système - Guide
- Désinstaller microsoft edge - Guide
- Installer microsoft store - Guide
- Windows 11 barre des taches a gauche - Guide
- Changer la couleur de la barre des taches - Guide
6 réponses
mamiemando
Messages postés
33079
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
23 avril 2024
7 749
6 févr. 2012 à 23:38
6 févr. 2012 à 23:38
Tu te rends compte que tu nous demande un coup de main pour écrire un script qui sert à sniffer des mots de passe ? :-) Tu n'as pas l'impression que c'est vaguement hors charte ?
Hors charte ? Non je ne pense pas.
J'écris un bash dans le cadre de mon projet tuteuré de deuxième année universitaire, portant sur la sécurité des réseaux 802.11
Il est vrai que c'est pas très heureux d'avoir laissé les commentaires, mais si ca peut vous aider à avoir une bonne compréhension de ce petit script, afin de pouvoir me dire comment se fait-il qu'il me reste quelques tshark d'ouvert après avoir fermé toutes les consoles!
Bien entendu je travaille sur des réseaux où j'ai tous les droits, etc... etc... (Il fallait le préciser tout de même, même si on s'en doute)
J'écris un bash dans le cadre de mon projet tuteuré de deuxième année universitaire, portant sur la sécurité des réseaux 802.11
Il est vrai que c'est pas très heureux d'avoir laissé les commentaires, mais si ca peut vous aider à avoir une bonne compréhension de ce petit script, afin de pouvoir me dire comment se fait-il qu'il me reste quelques tshark d'ouvert après avoir fermé toutes les consoles!
Bien entendu je travaille sur des réseaux où j'ai tous les droits, etc... etc... (Il fallait le préciser tout de même, même si on s'en doute)
jisisv
Messages postés
3645
Date d'inscription
dimanche 18 mars 2001
Statut
Modérateur
Dernière intervention
15 janvier 2017
934
7 févr. 2012 à 11:51
7 févr. 2012 à 11:51
<cite>Tu te rends compte...</cite>
Le propos n'est pas de juger la finalité du projet mais de résoudre un problème de gestions de processus. Le problème serait du même acabit s'il s'agissait de gérer par réseau un parc de machines à café, de caméra de surveillance (on ne pourrait pas poser de question non plus parce qu'on ne sait pas si ce sont les caméras du requérant , par ce qu'il est susceptible de filer sa voisine, la banque d'à côté...)
Dans le même ordre d'idées, il est dit dans la charte que l'on n'aide pas à TROUVER les mots de passe. Soit. Mais c'est le B.A.BA de supprimer un mot de passe Unix, et fait partie de la base de connaissances de tout administrateur.
N'oublions pas que accès physique sur un PC = accès total (modulo cryptage)
Y en a marre des vierges effarouchées.
Au plus les méthodes standards d'intrusion seront connues (bien que tout à fait publiques) au moins on aura de questions débiles récurrentes au sujet de mots de passe admin et C-ie. Cela responsabilisera les utilisateurs lambda.
Le propos n'est pas de juger la finalité du projet mais de résoudre un problème de gestions de processus. Le problème serait du même acabit s'il s'agissait de gérer par réseau un parc de machines à café, de caméra de surveillance (on ne pourrait pas poser de question non plus parce qu'on ne sait pas si ce sont les caméras du requérant , par ce qu'il est susceptible de filer sa voisine, la banque d'à côté...)
Dans le même ordre d'idées, il est dit dans la charte que l'on n'aide pas à TROUVER les mots de passe. Soit. Mais c'est le B.A.BA de supprimer un mot de passe Unix, et fait partie de la base de connaissances de tout administrateur.
N'oublions pas que accès physique sur un PC = accès total (modulo cryptage)
Y en a marre des vierges effarouchées.
Au plus les méthodes standards d'intrusion seront connues (bien que tout à fait publiques) au moins on aura de questions débiles récurrentes au sujet de mots de passe admin et C-ie. Cela responsabilisera les utilisateurs lambda.
mamiemando
Messages postés
33079
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
23 avril 2024
7 749
7 févr. 2012 à 19:29
7 févr. 2012 à 19:29
Je suis entièrerement d'accord avec toi, mais une fois j'ai eu le malheur d'expliquer comment on faisait sauter un mot de passe linux avec un live CD et je me suis fait taper sur les doigts, même si comme tu le dis c'est le B.A-BA quand on a accès physiquement à la machine. Mais à la limite, ça on s'en fiche :-)
Pour moi il y a des raisons plus essentielles :
- Même si le problème posé est un problème de processus, tu sais très bien qu'on va forcément avoir un boulet qui va se greffer sur ce sujet quand il sera résolu pour demander comment sniffer un mot de passe.
- Si le problème est un problème de processus (cas de figure qui peut se poser dans d'autres contexte que celui-ci), pourquoi ne pas poser la question en tant que telle afin qu'elle ait une chance de servir à quelqu'un d'autre ?
- Et même si ici ça n'a rien à voir, il y a toute cette vague de fond de débutants sous linux qui installent backtrack pour péter des wifi et ça me fatigue de voir qu'ils ne sont mêmes pas fichus de chercher 30s sur google. Déjà en soi, la finalité m'énerve, mais en plus vouloir mettre la charrue avant les boeufs pour faire son hacker en herbe, ça a tendance à m'exaspérer. Tu noteras que le sujet initial était posé de manière suffisamment ambigüe pour qu'on ne sache pas si theclem35 faisait partie ou non de cette catégorie de personne.
- Par rapport à ta remarque sur "les méthodes standards d'intrusion seront connues" oui elles sont connues, de même que leur réponse (ssl, ssh, smtps, imaps, gpg, etc...) et pourtant encore aujourd'hui nombre de mots de passe circulent en clair. Est-ce pour autant une raison d'encourager et aider des gens qui tentent ces méthodes d'intrusions, personnellement je ne pense pas, car je ne crois pas que ça fera avancer les choses.
Bref j'espère que tu ne me classes pas dans les vierges effarouchées, et clem35, j'espère que tu comprends que tu aurais du poser ton problème autrement ;-)
Par rapport à ton problème initial, il faut te demander si la commande est détachée (lancée en arrière plan) ou lancée en tant que démon. Sous linux a priori, quand un processus parent meurt, tous ces processus fils meurent sauf s'ils sont détachés.
Accessoirement, je trouve que c'est un mauvais choix d'invoquer gnome-terminal qui rend ton script dépendant de gnome. Pour moi, il serait plus logique de lancer tes taches en parallèles et de leur faire écrire leurs informations dans un fichier de log, que tu examineras ensuite avec tes différents terminaux avec la commande :
Du coup, tes différentes commandes devront être détachées du script shell que tu lances (et ainsi du shell depuis lequel tu les lances) par exemple grâce à la commande nohup. Idéalement l'idée serait de packager tout ça sous la forme de 4 démons bien propres.
Google, "tshark daemon" et la réponse tombe...
http://microrants.blogspot.com/2007/03/init-script-for-tshark.html
Bonne chance
Pour moi il y a des raisons plus essentielles :
- Même si le problème posé est un problème de processus, tu sais très bien qu'on va forcément avoir un boulet qui va se greffer sur ce sujet quand il sera résolu pour demander comment sniffer un mot de passe.
- Si le problème est un problème de processus (cas de figure qui peut se poser dans d'autres contexte que celui-ci), pourquoi ne pas poser la question en tant que telle afin qu'elle ait une chance de servir à quelqu'un d'autre ?
- Et même si ici ça n'a rien à voir, il y a toute cette vague de fond de débutants sous linux qui installent backtrack pour péter des wifi et ça me fatigue de voir qu'ils ne sont mêmes pas fichus de chercher 30s sur google. Déjà en soi, la finalité m'énerve, mais en plus vouloir mettre la charrue avant les boeufs pour faire son hacker en herbe, ça a tendance à m'exaspérer. Tu noteras que le sujet initial était posé de manière suffisamment ambigüe pour qu'on ne sache pas si theclem35 faisait partie ou non de cette catégorie de personne.
- Par rapport à ta remarque sur "les méthodes standards d'intrusion seront connues" oui elles sont connues, de même que leur réponse (ssl, ssh, smtps, imaps, gpg, etc...) et pourtant encore aujourd'hui nombre de mots de passe circulent en clair. Est-ce pour autant une raison d'encourager et aider des gens qui tentent ces méthodes d'intrusions, personnellement je ne pense pas, car je ne crois pas que ça fera avancer les choses.
Bref j'espère que tu ne me classes pas dans les vierges effarouchées, et clem35, j'espère que tu comprends que tu aurais du poser ton problème autrement ;-)
Par rapport à ton problème initial, il faut te demander si la commande est détachée (lancée en arrière plan) ou lancée en tant que démon. Sous linux a priori, quand un processus parent meurt, tous ces processus fils meurent sauf s'ils sont détachés.
Accessoirement, je trouve que c'est un mauvais choix d'invoquer gnome-terminal qui rend ton script dépendant de gnome. Pour moi, il serait plus logique de lancer tes taches en parallèles et de leur faire écrire leurs informations dans un fichier de log, que tu examineras ensuite avec tes différents terminaux avec la commande :
tail -f /le/chemin/vers/le/fichier/de/log
Du coup, tes différentes commandes devront être détachées du script shell que tu lances (et ainsi du shell depuis lequel tu les lances) par exemple grâce à la commande nohup. Idéalement l'idée serait de packager tout ça sous la forme de 4 démons bien propres.
Google, "tshark daemon" et la réponse tombe...
http://microrants.blogspot.com/2007/03/init-script-for-tshark.html
Bonne chance
kevin76110
Messages postés
4273
Date d'inscription
vendredi 14 août 2009
Statut
Membre
Dernière intervention
27 mars 2013
872
7 févr. 2012 à 21:23
7 févr. 2012 à 21:23
<hs>
comment on sniffe un mot de passe ???
*retourne à son code php*
</hs>
comment on sniffe un mot de passe ???
*retourne à son code php*
</hs>
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Merci pour cette piste.
Je vais donc essayer de lancer mes tshark en processus fils de mon script et de les faire ecrire dans un pipe nommé.
Ensuite, si j'ai bien compris, j'ouvrirai mes différents terminaux en lisant chaque pipe.
Ainsi, lorsque j'arrete mon script, tous les tshark devraient se stopper ?
Le problème à l'heure actuelle, c'est que mon script me sert juste à lancer les commandes et se stoppe immédiatement une fois le dernier tshark ouvert.
Il faudrait donc que je le garde actif ?
Désolé pour ces questions, mais ma compréhension en matière de bash, de demons et a fortiori de multithreads, est assez jeune!
Je vais donc essayer de lancer mes tshark en processus fils de mon script et de les faire ecrire dans un pipe nommé.
Ensuite, si j'ai bien compris, j'ouvrirai mes différents terminaux en lisant chaque pipe.
Ainsi, lorsque j'arrete mon script, tous les tshark devraient se stopper ?
Le problème à l'heure actuelle, c'est que mon script me sert juste à lancer les commandes et se stoppe immédiatement une fois le dernier tshark ouvert.
Il faudrait donc que je le garde actif ?
Désolé pour ces questions, mais ma compréhension en matière de bash, de demons et a fortiori de multithreads, est assez jeune!
mamiemando
Messages postés
33079
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
23 avril 2024
7 749
7 févr. 2012 à 20:37
7 févr. 2012 à 20:37
Ensuite, si j'ai bien compris, j'ouvrirai mes différents terminaux en lisant chaque pipe.
C'est pas vraiment des pipes (|) ce sont juste des "tail" qui "écoutent" ce qui écrit dans chaque fichier qu'on leur passe en paramètre et qui le réécrivent sur la sortie standard.
Ainsi, lorsque j'arrete mon script, tous les tshark devraient se stopper ?
Si tu regardes le lien que je t'ai donné, le but est de lancer une instance de tshark et de la stopper. Donc en supposant que tu architectures ton code sur le même principe (ie des démons qui écrivent dans des logs), il suffira de stopper ces démons pour arrêter les tsharks.
Il faudrait donc que je le garde actif ?
Tout dépend de ce que tu veux faire. Mais on peut raisonnablement imaginer que tu veuilles faire tourner ton script au dela de la durée de vie de ton shell ou de ta session, du moins c'est plus souple que ce que tu proposes. Et pour cela, la seule manière de faire, c'est de lancer ces processus sous forme de démons.
Désolé pour ces questions, mais ma compréhension en matière de bash, de demons et a fortiori de multithreads, est assez jeune!
Il n'y a pas grand chose à comprendre honnêtement. Lance la commande :
... tu verras qui est processus père de qui.
Tu peux voir un démon comme un programme qui tourne en arrière plan, indépendamment des sessions des utilisateurs. C'est exactement ce qui se passe pour les serveurs (ssh, apache, mysql...) que tu peux installer sous linux.
Ici il n'est pas vraiment question de multi-thread (un thread serait un processus fils engendré par un processus père et attaché à ce processus père, typiquement grâce à un fork), par exemple pour paralléliser des traitements. Ce serait par exemple le cas d'un serveur de base de donné qui va dédier un thread à chaque requête en cours.
Ce n'est pas ce que je te propose puisque tu as plusieurs démons, lancés au travers d'un script shell. Quand ce script shell prend fin, le démon tourne toujours. C'est exactement ce qui se passe au démarrage de linux, par exemple quand tu lances "/etc/init.d/ssh start" (= "service ssh start"). Beaucoup des lignes que tu vois au démarrages de linux correspondent à ce qu'écrivent ces différents scripts ("starting sshd server" par exemple).
Le script shell /etc/init.d/ssh lance un démon (/usr/sbin/sshd) qui tourne en arrière plan. sshd tournera jusqu'à ce qu'un "/etc/init.d/ssh stop" (= "service ssh stop") ait lieu. C'est par exemple ce qui se passe quand tu éteins linux, il éteint tous les services en cours de lancement. Ce sont d'ailleurs les lignes que tu vois apparaître au moment d'éteindre linux ("stopping sshd server" par exemple).
La piste que je te propose est de s'inspirer de ce schéma car c'est la plus souple : la mesure est indépendante de la durée de vie d'une session utilisateur ou d'un shell.
C'est pas vraiment des pipes (|) ce sont juste des "tail" qui "écoutent" ce qui écrit dans chaque fichier qu'on leur passe en paramètre et qui le réécrivent sur la sortie standard.
Ainsi, lorsque j'arrete mon script, tous les tshark devraient se stopper ?
Si tu regardes le lien que je t'ai donné, le but est de lancer une instance de tshark et de la stopper. Donc en supposant que tu architectures ton code sur le même principe (ie des démons qui écrivent dans des logs), il suffira de stopper ces démons pour arrêter les tsharks.
Il faudrait donc que je le garde actif ?
Tout dépend de ce que tu veux faire. Mais on peut raisonnablement imaginer que tu veuilles faire tourner ton script au dela de la durée de vie de ton shell ou de ta session, du moins c'est plus souple que ce que tu proposes. Et pour cela, la seule manière de faire, c'est de lancer ces processus sous forme de démons.
Désolé pour ces questions, mais ma compréhension en matière de bash, de demons et a fortiori de multithreads, est assez jeune!
Il n'y a pas grand chose à comprendre honnêtement. Lance la commande :
ps faux
... tu verras qui est processus père de qui.
Tu peux voir un démon comme un programme qui tourne en arrière plan, indépendamment des sessions des utilisateurs. C'est exactement ce qui se passe pour les serveurs (ssh, apache, mysql...) que tu peux installer sous linux.
Ici il n'est pas vraiment question de multi-thread (un thread serait un processus fils engendré par un processus père et attaché à ce processus père, typiquement grâce à un fork), par exemple pour paralléliser des traitements. Ce serait par exemple le cas d'un serveur de base de donné qui va dédier un thread à chaque requête en cours.
Ce n'est pas ce que je te propose puisque tu as plusieurs démons, lancés au travers d'un script shell. Quand ce script shell prend fin, le démon tourne toujours. C'est exactement ce qui se passe au démarrage de linux, par exemple quand tu lances "/etc/init.d/ssh start" (= "service ssh start"). Beaucoup des lignes que tu vois au démarrages de linux correspondent à ce qu'écrivent ces différents scripts ("starting sshd server" par exemple).
Le script shell /etc/init.d/ssh lance un démon (/usr/sbin/sshd) qui tourne en arrière plan. sshd tournera jusqu'à ce qu'un "/etc/init.d/ssh stop" (= "service ssh stop") ait lieu. C'est par exemple ce qui se passe quand tu éteins linux, il éteint tous les services en cours de lancement. Ce sont d'ailleurs les lignes que tu vois apparaître au moment d'éteindre linux ("stopping sshd server" par exemple).
La piste que je te propose est de s'inspirer de ce schéma car c'est la plus souple : la mesure est indépendante de la durée de vie d'une session utilisateur ou d'un shell.
