Mon hypothèse est aussi valable que la tienne: C'est parce que les script kiddie ne sont pas intéressés à se mesurer à Linux en raison des trop grandes difficultés à faire des virus, trojan et autres saloperies du genre.
Gere des serveurs sur Internet et tu verras que les dites saloperies existent bel et bien. Que les scripts kiddies sont tres interesses par les Linux et que si tu fais pas TRES attention, tu as de fortes chances d'en attirer pletore.
On 11/19/10 1:33 AM, Dellara wrote:
Mon hypothèse est aussi valable que la tienne: C'est parce que les
script kiddie ne sont pas intéressés à se mesurer à Linux en raison des
trop grandes difficultés à faire des virus, trojan et autres saloperies
du genre.
Gere des serveurs sur Internet et tu verras que les dites saloperies
existent bel et bien. Que les scripts kiddies sont tres interesses par
les Linux et que si tu fais pas TRES attention, tu as de fortes chances
d'en attirer pletore.
Mon hypothèse est aussi valable que la tienne: C'est parce que les script kiddie ne sont pas intéressés à se mesurer à Linux en raison des trop grandes difficultés à faire des virus, trojan et autres saloperies du genre.
Gere des serveurs sur Internet et tu verras que les dites saloperies existent bel et bien. Que les scripts kiddies sont tres interesses par les Linux et que si tu fais pas TRES attention, tu as de fortes chances d'en attirer pletore.
Doug713705
Le 18/11/2010 21:18 dans fr.comp.os.linux.debats Stéphan Peccini nous expliquait:
perl -e 'while(1){fork;}'
La derniere fois que j'ai teste, j'ai perdu la main immediatement.
$ man ulimit
Sans aller jusque là, j'ai essayé et c'est vrai que la machine s'est mise au ralenti mais je n'ai pas eu de difficulté à arrêter le processus après avoir changé de fenêtre et être revenu sur celle où j'avais lancé la commande ;
Le fameux patch du noyau de 224 lignes est vraiment très efficace.
En // : make -j 64 du noyau, 60 copies de fichiers de 650 Go vers /dev/null et la fameuse fork bomb du dessus, les trois dans trois terminaux. La machine a sa charge qui monte à plus de 750 et ça continue et elle reste totalement réactive.
Alors comme ça tu as trouvé de quoi utiliser tes 4 coeurs ? Ca va faire plaisir à Péhache ;-) -- @+ Doug - Linux user #307925 - Slackware64 roulaize ;-) Usenet-fr ? Mais qu'est-ce que c'est ? Comment ça marche ? Pour en savoir plus : http://usenet-fr.dougwise.org/
Le 18/11/2010 21:18 dans fr.comp.os.linux.debats Stéphan Peccini nous
expliquait:
perl -e 'while(1){fork;}'
La derniere fois que j'ai teste, j'ai perdu la main immediatement.
$ man ulimit
Sans aller jusque là, j'ai essayé et c'est vrai que la machine s'est mise
au ralenti mais je n'ai pas eu de difficulté à arrêter le processus après
avoir changé de fenêtre et être revenu sur celle où j'avais lancé la
commande ;
Le fameux patch du noyau de 224 lignes est vraiment très efficace.
En // : make -j 64 du noyau, 60 copies de fichiers de 650 Go vers /dev/null
et la fameuse fork bomb du dessus, les trois dans trois terminaux. La
machine a sa charge qui monte à plus de 750 et ça continue et elle reste
totalement réactive.
Alors comme ça tu as trouvé de quoi utiliser tes 4 coeurs ?
Ca va faire plaisir à Péhache ;-)
--
@+
Doug - Linux user #307925 - Slackware64 roulaize ;-)
Usenet-fr ? Mais qu'est-ce que c'est ? Comment ça marche ?
Pour en savoir plus : http://usenet-fr.dougwise.org/
Le 18/11/2010 21:18 dans fr.comp.os.linux.debats Stéphan Peccini nous expliquait:
perl -e 'while(1){fork;}'
La derniere fois que j'ai teste, j'ai perdu la main immediatement.
$ man ulimit
Sans aller jusque là, j'ai essayé et c'est vrai que la machine s'est mise au ralenti mais je n'ai pas eu de difficulté à arrêter le processus après avoir changé de fenêtre et être revenu sur celle où j'avais lancé la commande ;
Le fameux patch du noyau de 224 lignes est vraiment très efficace.
En // : make -j 64 du noyau, 60 copies de fichiers de 650 Go vers /dev/null et la fameuse fork bomb du dessus, les trois dans trois terminaux. La machine a sa charge qui monte à plus de 750 et ça continue et elle reste totalement réactive.
Alors comme ça tu as trouvé de quoi utiliser tes 4 coeurs ? Ca va faire plaisir à Péhache ;-) -- @+ Doug - Linux user #307925 - Slackware64 roulaize ;-) Usenet-fr ? Mais qu'est-ce que c'est ? Comment ça marche ? Pour en savoir plus : http://usenet-fr.dougwise.org/
Stéphan Peccini
Doug713705 wrote:
Alors comme ça tu as trouvé de quoi utiliser tes 4 coeurs ?
Je vais essayer de voir avec make -j 1024 en // de la fork bomb.
Bon, trèves de plaisanteries, je vais regarder ce que l'on peut faire avec la deuxième solution sans patch, celle où il suffit de lancer dans le .bashrc : mkdir -m 0700 /dev/cgroup/cpu/user/$$ echo $$ > /dev/cgroup/cpu/user/$$/tasks pour obtenir le même résultat que le patch en ayant juste mis quelques lignes dans rc.local pour préparer le terrain.
Le premier avantage est de ne pas avoir à gérer de patch sur le noyau alors que celui-ci pourrait n'être intégré que dans la 2.6.38.
De plus le patch, en l'état actuel, ne permet de regrouper les processus ensemble que sur le seul critère du tty ; donc tout ce qui est lancé depuis X est associé au même tty (enfin, si j'ai bien compris le principe du patch dans ce que j'ai lu) ; ce que reproduisent les deux lignes dans le .bashrc. Mais peut on aller plus loin pour réussir à regrouper sur des critères d'application (ce que semblent montrer les deux lignes puisque c'est le processus qui est la base) et non de tty ? Peut on mettre plusieurs processus dans un même cgroup en donnant plusieurs pid à tasks ? Si quelqu'un a déjà des idées ...
-- Stéphan Peccini Le blog : <URL:http://pyrenees.peccini.fr> Les photos : <URL:http://photonature.fr>
Doug713705 wrote:
Alors comme ça tu as trouvé de quoi utiliser tes 4 coeurs ?
Je vais essayer de voir avec make -j 1024 en // de la fork bomb.
Bon, trèves de plaisanteries, je vais regarder ce que l'on peut faire avec
la deuxième solution sans patch, celle où il suffit de lancer dans le
.bashrc :
mkdir -m 0700 /dev/cgroup/cpu/user/$$
echo $$ > /dev/cgroup/cpu/user/$$/tasks
pour obtenir le même résultat que le patch en ayant juste mis quelques
lignes dans rc.local pour préparer le terrain.
Le premier avantage est de ne pas avoir à gérer de patch sur le noyau alors
que celui-ci pourrait n'être intégré que dans la 2.6.38.
De plus le patch, en l'état actuel, ne permet de regrouper les processus
ensemble que sur le seul critère du tty ; donc tout ce qui est lancé depuis
X est associé au même tty (enfin, si j'ai bien compris le principe du patch
dans ce que j'ai lu) ; ce que reproduisent les deux lignes dans le .bashrc.
Mais peut on aller plus loin pour réussir à regrouper sur des critères
d'application (ce que semblent montrer les deux lignes puisque c'est le
processus qui est la base) et non de tty ? Peut on mettre plusieurs
processus dans un même cgroup en donnant plusieurs pid à tasks ? Si
quelqu'un a déjà des idées ...
--
Stéphan Peccini
Le blog : <URL:http://pyrenees.peccini.fr>
Les photos : <URL:http://photonature.fr>
Alors comme ça tu as trouvé de quoi utiliser tes 4 coeurs ?
Je vais essayer de voir avec make -j 1024 en // de la fork bomb.
Bon, trèves de plaisanteries, je vais regarder ce que l'on peut faire avec la deuxième solution sans patch, celle où il suffit de lancer dans le .bashrc : mkdir -m 0700 /dev/cgroup/cpu/user/$$ echo $$ > /dev/cgroup/cpu/user/$$/tasks pour obtenir le même résultat que le patch en ayant juste mis quelques lignes dans rc.local pour préparer le terrain.
Le premier avantage est de ne pas avoir à gérer de patch sur le noyau alors que celui-ci pourrait n'être intégré que dans la 2.6.38.
De plus le patch, en l'état actuel, ne permet de regrouper les processus ensemble que sur le seul critère du tty ; donc tout ce qui est lancé depuis X est associé au même tty (enfin, si j'ai bien compris le principe du patch dans ce que j'ai lu) ; ce que reproduisent les deux lignes dans le .bashrc. Mais peut on aller plus loin pour réussir à regrouper sur des critères d'application (ce que semblent montrer les deux lignes puisque c'est le processus qui est la base) et non de tty ? Peut on mettre plusieurs processus dans un même cgroup en donnant plusieurs pid à tasks ? Si quelqu'un a déjà des idées ...
-- Stéphan Peccini Le blog : <URL:http://pyrenees.peccini.fr> Les photos : <URL:http://photonature.fr>
Tonton Th
On 11/19/2010 05:50 AM, Stéphan Peccini wrote:
De plus le patch, en l'état actuel, ne permet de regrouper les processus ensemble que sur le seul critère du tty ; donc tout ce qui est lancé depuis X est associé au même tty (enfin, si j'ai bien compris le principe du patch dans ce que j'ai lu) ;
Je crois que c'est plus sioux que ça, j'ai lu quelques explications dans linuxfr tout à l'heure...
-- Ma coiffeuse est formidable - http://sonia.buvette.org/
On 11/19/2010 05:50 AM, Stéphan Peccini wrote:
De plus le patch, en l'état actuel, ne permet de regrouper les processus
ensemble que sur le seul critère du tty ; donc tout ce qui est lancé depuis
X est associé au même tty (enfin, si j'ai bien compris le principe du patch
dans ce que j'ai lu) ;
Je crois que c'est plus sioux que ça, j'ai lu quelques explications
dans linuxfr tout à l'heure...
--
Ma coiffeuse est formidable - http://sonia.buvette.org/
De plus le patch, en l'état actuel, ne permet de regrouper les processus ensemble que sur le seul critère du tty ; donc tout ce qui est lancé depuis X est associé au même tty (enfin, si j'ai bien compris le principe du patch dans ce que j'ai lu) ;
Je crois que c'est plus sioux que ça, j'ai lu quelques explications dans linuxfr tout à l'heure...
-- Ma coiffeuse est formidable - http://sonia.buvette.org/
Stéphan Peccini
Tonton Th wrote:
On 11/19/2010 05:50 AM, Stéphan Peccini wrote:
De plus le patch, en l'état actuel, ne permet de regrouper les processus ensemble que sur le seul critère du tty ; donc tout ce qui est lancé depuis X est associé au même tty (enfin, si j'ai bien compris le principe du patch dans ce que j'ai lu) ;
Je crois que c'est plus sioux que ça, j'ai lu quelques explications dans linuxfr tout à l'heure...
Tu peux me dire où car en relisant je ne vois pas. Il est indiqué :
« Le patch de Mike propose de créer automatiquement un cgroup par TTY »
« Sans les cgroups autogroupon a pour un make -j64 et un firefox un VLC, en simplifiant 66 process en tout.
Chaque tâche aura 1/66ème du temps processeur (à priorité égale)
Avec les cgroups, il y a 2 groupes de process qui sont créés: un pour le make -j64 et un pour les applications graphique (firefox/vlc). Chaque cgroups a droit à 50% du proc, donc en somme le make -j64 n'utilisera pas plus de 50% de cpu ce qui laisse assez à vlc/firefox de quoi tourner correcrtement avec 1/2 du temps processeur comparé au 1/66ème présenté ci- dessus. »
Sinon, j'ai ma réponse ; on peut affecter bien évidemment plusieurs processus à tasks.
-- Stéphan Peccini Le blog : <URL:http://pyrenees.peccini.fr> Les photos : <URL:http://photonature.fr>
Tonton Th wrote:
On 11/19/2010 05:50 AM, Stéphan Peccini wrote:
De plus le patch, en l'état actuel, ne permet de regrouper les processus
ensemble que sur le seul critère du tty ; donc tout ce qui est lancé
depuis X est associé au même tty (enfin, si j'ai bien compris le principe
du patch dans ce que j'ai lu) ;
Je crois que c'est plus sioux que ça, j'ai lu quelques explications
dans linuxfr tout à l'heure...
Tu peux me dire où car en relisant je ne vois pas. Il est indiqué :
« Le patch de Mike propose de créer automatiquement un cgroup par TTY »
« Sans les cgroups autogroupon a pour un make -j64 et un firefox un VLC, en
simplifiant 66 process en tout.
Chaque tâche aura 1/66ème du temps processeur (à priorité égale)
Avec les cgroups, il y a 2 groupes de process qui sont créés: un pour le
make -j64 et un pour les applications graphique (firefox/vlc).
Chaque cgroups a droit à 50% du proc, donc en somme le make -j64 n'utilisera
pas plus de 50% de cpu ce qui laisse assez à vlc/firefox de quoi tourner
correcrtement avec 1/2 du temps processeur comparé au 1/66ème présenté ci-
dessus. »
Sinon, j'ai ma réponse ; on peut affecter bien évidemment plusieurs
processus à tasks.
--
Stéphan Peccini
Le blog : <URL:http://pyrenees.peccini.fr>
Les photos : <URL:http://photonature.fr>
De plus le patch, en l'état actuel, ne permet de regrouper les processus ensemble que sur le seul critère du tty ; donc tout ce qui est lancé depuis X est associé au même tty (enfin, si j'ai bien compris le principe du patch dans ce que j'ai lu) ;
Je crois que c'est plus sioux que ça, j'ai lu quelques explications dans linuxfr tout à l'heure...
Tu peux me dire où car en relisant je ne vois pas. Il est indiqué :
« Le patch de Mike propose de créer automatiquement un cgroup par TTY »
« Sans les cgroups autogroupon a pour un make -j64 et un firefox un VLC, en simplifiant 66 process en tout.
Chaque tâche aura 1/66ème du temps processeur (à priorité égale)
Avec les cgroups, il y a 2 groupes de process qui sont créés: un pour le make -j64 et un pour les applications graphique (firefox/vlc). Chaque cgroups a droit à 50% du proc, donc en somme le make -j64 n'utilisera pas plus de 50% de cpu ce qui laisse assez à vlc/firefox de quoi tourner correcrtement avec 1/2 du temps processeur comparé au 1/66ème présenté ci- dessus. »
Sinon, j'ai ma réponse ; on peut affecter bien évidemment plusieurs processus à tasks.
-- Stéphan Peccini Le blog : <URL:http://pyrenees.peccini.fr> Les photos : <URL:http://photonature.fr>
Tonton Th
On 11/19/2010 07:08 AM, Stéphan Peccini wrote:
De plus le patch, en l'état actuel, ne permet de regrouper les processus ensemble que sur le seul critère du tty ; donc tout ce qui est lancé depuis X est associé au même tty (enfin, si j'ai bien compris le principe du patch dans ce que j'ai lu) ;
Je crois que c'est plus sioux que ça, j'ai lu quelques explications dans linuxfr tout à l'heure...
Tu peux me dire où car en relisant je ne vois pas. Il est indiqué :
Bah, il n'y a pas de vraiment "où", mais les divers trucs expliqués m'ont aidé à me faire une idée plus précise de la chose. Et ça va me conduire direct à quelques expérimentations dans mon contexte personnel d'utilisation des linuquses.
Sinon, j'ai ma réponse ; on peut affecter bien évidemment plusieurs processus à tasks.
Please explain that.
-- Ma coiffeuse est formidable - http://sonia.buvette.org/
On 11/19/2010 07:08 AM, Stéphan Peccini wrote:
De plus le patch, en l'état actuel, ne permet de regrouper les processus
ensemble que sur le seul critère du tty ; donc tout ce qui est lancé
depuis X est associé au même tty (enfin, si j'ai bien compris le principe
du patch dans ce que j'ai lu) ;
Je crois que c'est plus sioux que ça, j'ai lu quelques explications
dans linuxfr tout à l'heure...
Tu peux me dire où car en relisant je ne vois pas. Il est indiqué :
Bah, il n'y a pas de vraiment "où", mais les divers trucs expliqués
m'ont aidé à me faire une idée plus précise de la chose. Et ça va
me conduire direct à quelques expérimentations dans mon contexte
personnel d'utilisation des linuquses.
Sinon, j'ai ma réponse ; on peut affecter bien évidemment plusieurs
processus à tasks.
Please explain that.
--
Ma coiffeuse est formidable - http://sonia.buvette.org/
De plus le patch, en l'état actuel, ne permet de regrouper les processus ensemble que sur le seul critère du tty ; donc tout ce qui est lancé depuis X est associé au même tty (enfin, si j'ai bien compris le principe du patch dans ce que j'ai lu) ;
Je crois que c'est plus sioux que ça, j'ai lu quelques explications dans linuxfr tout à l'heure...
Tu peux me dire où car en relisant je ne vois pas. Il est indiqué :
Bah, il n'y a pas de vraiment "où", mais les divers trucs expliqués m'ont aidé à me faire une idée plus précise de la chose. Et ça va me conduire direct à quelques expérimentations dans mon contexte personnel d'utilisation des linuquses.
Sinon, j'ai ma réponse ; on peut affecter bien évidemment plusieurs processus à tasks.
Please explain that.
-- Ma coiffeuse est formidable - http://sonia.buvette.org/
Kevin Denis
Le 18-11-2010, Dellara a écrit :
Mon hypothèse est aussi valable que la tienne: C'est parce que les script kiddie ne sont pas intéressés à se mesurer à Linux en raison des trop grandes difficultés à faire des virus, trojan et autres saloperies du genre.
Un script kiddie, il ne sait pas ce qu'il fait. Le jour ou il cliquera sur un script qui attaquera du linux, alors il attaquera du linux.
La question, c'est pourquoi l'auteur du script n'en fait pas pour du linux? C'est pour une affaire de surface d'attaque. Pourquoi aller attaquer un truc utilisé par trois péquins? Tiens, il y a des virus dans Haïku? Il est plus sûr?
Si on reprend les serveurs apache+PHP, il a été écrit des phpshells: http://1.bp.blogspot.com/_oGUvVXIO2bc/TI8vza8Sq3I/AAAAAAAAAC0/FhaM_usYoew/s1600/php-shell.jpg
Pourquoi ces scripts existent? Parcequ'ils ont une très forte chance d'être utilisés car y a beaucoup de serveurs web utilisant le tryptique Apache+mySQL+PHP. Dans l'exemple, de plus, on est sur du linux. -- Kevin
Le 18-11-2010, Dellara <paul.pygeon@gmail.com> a écrit :
Mon hypothèse est aussi valable que la tienne: C'est parce que les
script kiddie ne sont pas intéressés à se mesurer à Linux en raison des
trop grandes difficultés à faire des virus, trojan et autres saloperies
du genre.
Un script kiddie, il ne sait pas ce qu'il fait. Le jour ou il cliquera
sur un script qui attaquera du linux, alors il attaquera du linux.
La question, c'est pourquoi l'auteur du script n'en fait pas pour du
linux? C'est pour une affaire de surface d'attaque. Pourquoi aller
attaquer un truc utilisé par trois péquins? Tiens, il y a des virus dans
Haïku? Il est plus sûr?
Si on reprend les serveurs apache+PHP, il a été écrit des phpshells:
http://1.bp.blogspot.com/_oGUvVXIO2bc/TI8vza8Sq3I/AAAAAAAAAC0/FhaM_usYoew/s1600/php-shell.jpg
Pourquoi ces scripts existent? Parcequ'ils ont une très forte chance
d'être utilisés car y a beaucoup de serveurs web utilisant le
tryptique Apache+mySQL+PHP. Dans l'exemple, de plus, on est sur du
linux.
--
Kevin
Mon hypothèse est aussi valable que la tienne: C'est parce que les script kiddie ne sont pas intéressés à se mesurer à Linux en raison des trop grandes difficultés à faire des virus, trojan et autres saloperies du genre.
Un script kiddie, il ne sait pas ce qu'il fait. Le jour ou il cliquera sur un script qui attaquera du linux, alors il attaquera du linux.
La question, c'est pourquoi l'auteur du script n'en fait pas pour du linux? C'est pour une affaire de surface d'attaque. Pourquoi aller attaquer un truc utilisé par trois péquins? Tiens, il y a des virus dans Haïku? Il est plus sûr?
Si on reprend les serveurs apache+PHP, il a été écrit des phpshells: http://1.bp.blogspot.com/_oGUvVXIO2bc/TI8vza8Sq3I/AAAAAAAAAC0/FhaM_usYoew/s1600/php-shell.jpg
Pourquoi ces scripts existent? Parcequ'ils ont une très forte chance d'être utilisés car y a beaucoup de serveurs web utilisant le tryptique Apache+mySQL+PHP. Dans l'exemple, de plus, on est sur du linux. -- Kevin
Hugues
ST a suggéré :
On 11/18/10 6:36 PM, Hugues wrote:
Avoir acces ou pas au compte root n'a aucune sorte d'importance. Il a deja ete demontre qu'il est tres facile de faire de degats, meme au niveau systeme, sans les droits root.
Ah bon ? Je n'ai vu aucune démonstration de ce type.
C'est parce que tu ne sais pas lire.
while(1){fork;}
ce n'est pas un virus. et on t'a déjà donné la réponse ici : man ulimit.
Tu n'en as jamais vu. Se pourrait-il que la terre soit plate parce que tu ne l'as jamais vu ronde ? Non, tu acceptes le postulat qu'elle est ronde parce que des gens l'ont verifie et te le disent.
"Des gens".
Moi, je te dis que j'ai vu des Linux infectes par des trucs dont la methode de reproduction et d'infectation rentre dans la definition du virus.
"Toi".
Tu saisis la différence ?
-- Hugues Hiegel [http://www.hiegel.fr/~hugues/]
ST <st@unices.org> a suggéré :
On 11/18/10 6:36 PM, Hugues wrote:
Avoir acces ou pas au compte root n'a aucune sorte d'importance. Il a
deja ete demontre qu'il est tres facile de faire de degats, meme au
niveau systeme, sans les droits root.
Ah bon ? Je n'ai vu aucune démonstration de ce type.
C'est parce que tu ne sais pas lire.
while(1){fork;}
ce n'est pas un virus.
et on t'a déjà donné la réponse ici : man ulimit.
Tu n'en as jamais vu. Se pourrait-il que la terre soit plate parce que
tu ne l'as jamais vu ronde ? Non, tu acceptes le postulat qu'elle est
ronde parce que des gens l'ont verifie et te le disent.
"Des gens".
Moi, je te dis que j'ai vu des Linux infectes par des trucs dont la
methode de reproduction et d'infectation rentre dans la definition du
virus.
Avoir acces ou pas au compte root n'a aucune sorte d'importance. Il a deja ete demontre qu'il est tres facile de faire de degats, meme au niveau systeme, sans les droits root.
Ah bon ? Je n'ai vu aucune démonstration de ce type.
C'est parce que tu ne sais pas lire.
while(1){fork;}
ce n'est pas un virus. et on t'a déjà donné la réponse ici : man ulimit.
Tu n'en as jamais vu. Se pourrait-il que la terre soit plate parce que tu ne l'as jamais vu ronde ? Non, tu acceptes le postulat qu'elle est ronde parce que des gens l'ont verifie et te le disent.
"Des gens".
Moi, je te dis que j'ai vu des Linux infectes par des trucs dont la methode de reproduction et d'infectation rentre dans la definition du virus.
"Toi".
Tu saisis la différence ?
-- Hugues Hiegel [http://www.hiegel.fr/~hugues/]
Hugues
ST a suggéré :
Meme Mac OS X qui prend peut etre 10% du parc ne souffre pas d'infections
Ah tiens, et pourquoi tu aurais raison concernant Mac OS X, et pas moi concernant Linux ?
(quant à tes 10%, ils sont vachement optimistes)
-- Hugues Hiegel [http://www.hiegel.fr/~hugues/]
ST <st@unices.org> a suggéré :
Meme Mac OS X qui prend peut etre 10% du parc ne souffre pas
d'infections
Ah tiens, et pourquoi tu aurais raison concernant Mac OS X, et pas moi
concernant Linux ?
