Jusqu'à hier j'utilisais outpost firewall 2009.
Je suis repassé au firewall de XP.
J'aimerais savoir si ce firewall est de bonne qualité?
Je sais qu'il ne filtre pas les données sortantes mais il parait que ce
n'est pas important, est ce vrai?
Faut il que je repasse à outpost firewall?
Les plus paranoïaques pouvent parfaitement créer un compte utilisateur par application/programme et n'accorder le droit d'écriture sur les binaires qu'à cet utilisateur. On fait un petit coup de shadowing sur le mot de passe et il faut impérativement casser root pour pouvoir corrompre autre chose que les données,
Je ne sais pas pour vous, mais chez moi les binaires appartiennent à root, et il n'est pas question de laisser qui que ce soit d'autre y toucher.
A mon sens c'est un erreur. Chez moi aucun binaires pouvant servir de point d'entrée, n'appartient à root, sauf lorsqu'il est totalment impossible de faire autrement. Et si les *BSD de la maison ne faisaient pas tourner que des serveurs, je ferais la même chose pour les applications tels que firefox, qui constituent elles aussi un point d'entrée potentiel. Les donner à root revient à faciliter la tache de l'attaquant, puisque s'il arrive à exploiter une faille il se retrouvera immédiatement maître sur le système. A titre d'exemple, s'il existe une faille dans firefox au niveau XMLHTTPRequest qui permettrait de lire/écrire sur le disque, le fait que firefox appartienne à lui-même n'empèche pas la faille d'être exploitée mais limite l'utilité de son exploitation. A l'inverse la même faille avec firefox en root permet d'installer un trojan et de modifier les scripts rc.d pour s'assurer qu'il sera toujours à l'écoute.
ce qui limite suffisement les risques pour pouvoir dormir plus que tranquillement lorsque l'on n'est qu'un utilisateur qui ne s'est pas mis la mafia ou un cracker à dos.
on peut aussi mettre ses partitions de programmes en lecture seule, c'est encore plus simple (ça complique un peu les mises à jour, par contre)
Ce n'est pas on peu aussi, c'est on doit aussi ;)
Bastien Durel n'était pas loin de dire :
Les plus paranoïaques pouvent parfaitement créer un compte utilisateur
par application/programme et n'accorder le droit d'écriture sur les
binaires qu'à cet utilisateur. On fait un petit coup de shadowing sur le
mot de passe et il faut impérativement casser root pour pouvoir
corrompre autre chose que les données,
Je ne sais pas pour vous, mais chez moi les binaires appartiennent à
root, et il n'est pas question de laisser qui que ce soit d'autre y
toucher.
A mon sens c'est un erreur. Chez moi aucun binaires pouvant servir de
point d'entrée, n'appartient à root, sauf lorsqu'il est totalment
impossible de faire autrement. Et si les *BSD de la maison ne faisaient
pas tourner que des serveurs, je ferais la même chose pour les
applications tels que firefox, qui constituent elles aussi un point
d'entrée potentiel. Les donner à root revient à faciliter la tache de
l'attaquant, puisque s'il arrive à exploiter une faille il se
retrouvera immédiatement maître sur le système.
A titre d'exemple, s'il existe une faille dans firefox au niveau
XMLHTTPRequest qui permettrait de lire/écrire sur le disque, le fait
que firefox appartienne à lui-même n'empèche pas la faille d'être
exploitée mais limite l'utilité de son exploitation. A l'inverse la
même faille avec firefox en root permet d'installer un trojan et de
modifier les scripts rc.d pour s'assurer qu'il sera toujours à
l'écoute.
ce qui limite suffisement les
risques pour pouvoir dormir plus que tranquillement lorsque l'on n'est
qu'un utilisateur qui ne s'est pas mis la mafia ou un cracker à dos.
on peut aussi mettre ses partitions de programmes en lecture seule, c'est
encore plus simple (ça complique un peu les mises à jour, par contre)
Les plus paranoïaques pouvent parfaitement créer un compte utilisateur par application/programme et n'accorder le droit d'écriture sur les binaires qu'à cet utilisateur. On fait un petit coup de shadowing sur le mot de passe et il faut impérativement casser root pour pouvoir corrompre autre chose que les données,
Je ne sais pas pour vous, mais chez moi les binaires appartiennent à root, et il n'est pas question de laisser qui que ce soit d'autre y toucher.
A mon sens c'est un erreur. Chez moi aucun binaires pouvant servir de point d'entrée, n'appartient à root, sauf lorsqu'il est totalment impossible de faire autrement. Et si les *BSD de la maison ne faisaient pas tourner que des serveurs, je ferais la même chose pour les applications tels que firefox, qui constituent elles aussi un point d'entrée potentiel. Les donner à root revient à faciliter la tache de l'attaquant, puisque s'il arrive à exploiter une faille il se retrouvera immédiatement maître sur le système. A titre d'exemple, s'il existe une faille dans firefox au niveau XMLHTTPRequest qui permettrait de lire/écrire sur le disque, le fait que firefox appartienne à lui-même n'empèche pas la faille d'être exploitée mais limite l'utilité de son exploitation. A l'inverse la même faille avec firefox en root permet d'installer un trojan et de modifier les scripts rc.d pour s'assurer qu'il sera toujours à l'écoute.
ce qui limite suffisement les risques pour pouvoir dormir plus que tranquillement lorsque l'on n'est qu'un utilisateur qui ne s'est pas mis la mafia ou un cracker à dos.
on peut aussi mettre ses partitions de programmes en lecture seule, c'est encore plus simple (ça complique un peu les mises à jour, par contre)
Ce n'est pas on peu aussi, c'est on doit aussi ;)
Erwan David
Stephane Catteau écrivait :
A mon sens c'est un erreur. Chez moi aucun binaires pouvant servir de point d'entrée, n'appartient à root, sauf lorsqu'il est totalment impossible de faire autrement. Et si les *BSD de la maison ne faisaient pas tourner que des serveurs, je ferais la même chose pour les applications tels que firefox, qui constituent elles aussi un point d'entrée potentiel. Les donner à root revient à faciliter la tache de l'attaquant, puisque s'il arrive à exploiter une faille il se retrouvera immédiatement maître sur le système.
Sauf que le propriétaire du binaire n'a aucun lien avec l'utilisateur sous lequel il tourne. Il vaut mieux d'ailleurs que l'utilisateur qui faut tourner un binaire ne puisse pas le modifier...
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
A mon sens c'est un erreur. Chez moi aucun binaires pouvant servir de
point d'entrée, n'appartient à root, sauf lorsqu'il est totalment
impossible de faire autrement. Et si les *BSD de la maison ne faisaient
pas tourner que des serveurs, je ferais la même chose pour les
applications tels que firefox, qui constituent elles aussi un point
d'entrée potentiel. Les donner à root revient à faciliter la tache de
l'attaquant, puisque s'il arrive à exploiter une faille il se
retrouvera immédiatement maître sur le système.
Sauf que le propriétaire du binaire n'a aucun lien avec l'utilisateur
sous lequel il tourne. Il vaut mieux d'ailleurs que l'utilisateur qui
faut tourner un binaire ne puisse pas le modifier...
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
A mon sens c'est un erreur. Chez moi aucun binaires pouvant servir de point d'entrée, n'appartient à root, sauf lorsqu'il est totalment impossible de faire autrement. Et si les *BSD de la maison ne faisaient pas tourner que des serveurs, je ferais la même chose pour les applications tels que firefox, qui constituent elles aussi un point d'entrée potentiel. Les donner à root revient à faciliter la tache de l'attaquant, puisque s'il arrive à exploiter une faille il se retrouvera immédiatement maître sur le système.
Sauf que le propriétaire du binaire n'a aucun lien avec l'utilisateur sous lequel il tourne. Il vaut mieux d'ailleurs que l'utilisateur qui faut tourner un binaire ne puisse pas le modifier...
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Fabien LE LEZ
On Sun, 28 Mar 2010 19:32:41 +0200, Stephane Catteau :
Les donner à root revient à faciliter la tache de l'attaquant,
En quoi ?
On Sun, 28 Mar 2010 19:32:41 +0200, Stephane Catteau
<steph.nospam@sc4x.net>:
Les donner à root revient à faciliter la tache de
l'attaquant,
On Sun, 28 Mar 2010 19:32:41 +0200, Stephane Catteau :
Les donner à root revient à faciliter la tache de l'attaquant,
En quoi ?
debug this fifo
Stephane Catteau wrote:
A mon sens c'est un erreur. Chez moi aucun binaires pouvant servir de point d'entrée, n'appartient à root, sauf lorsqu'il est totalment impossible de faire autrement.
euh, même si il appartient à root, tant qu'il n'est pas setuid(root) je ne vois pas trop le danger...
Stephane Catteau wrote:
A mon sens c'est un erreur. Chez moi aucun binaires pouvant servir de
point d'entrée, n'appartient à root, sauf lorsqu'il est totalment
impossible de faire autrement.
euh, même si il appartient à root, tant qu'il n'est pas setuid(root)
je ne vois pas trop le danger...
A mon sens c'est un erreur. Chez moi aucun binaires pouvant servir de point d'entrée, n'appartient à root, sauf lorsqu'il est totalment impossible de faire autrement.
euh, même si il appartient à root, tant qu'il n'est pas setuid(root) je ne vois pas trop le danger...
Bastien Durel
Le Sun, 28 Mar 2010 19:32:41 +0200, Stephane Catteau a écrit :
Bastien Durel n'était pas loin de dire :
Je ne sais pas pour vous, mais chez moi les binaires appartiennent à root, et il n'est pas question de laisser qui que ce soit d'autre y toucher.
A mon sens c'est un erreur. Chez moi aucun binaires pouvant servir de point d'entrée, n'appartient à root, sauf lorsqu'il est totalment impossible de faire autrement.
Le fait qu'ils appartiennent à root ne veut pas dire que c ést root que les execute. root fait tourner cron, racoon, sshd, ou qmail-lspawn ; pasqu'il n'y a pas moyen de faire autrement, mais les autres serveurs tournent sous des utilisateurs différents et n'ayant pas le droit d'écrire leurs binaires.
Et si les *BSD de la maison ne faisaient pas tourner que des serveurs, je ferais la même chose pour les applications tels que firefox, qui constituent elles aussi un point d'entrée potentiel. Les donner à root revient à faciliter la tache de l'attaquant, puisque s'il arrive à exploiter une faille il se retrouvera immédiatement maître sur le système.
firefox ne tourne jamais que sous bastien, qui n'as pas le droit de faire grand chose, si ce n'est monter les disques amovibles ou toucher à la carte son.
A titre d'exemple, s'il existe une faille dans firefox au niveau XMLHTTPRequest qui permettrait de lire/écrire sur le disque, le fait que firefox appartienne à lui-même n'empèche pas la faille d'être exploitée mais limite l'utilité de son exploitation. A l'inverse la même faille avec firefox en root permet d'installer un trojan et de modifier les scripts rc.d pour s'assurer qu'il sera toujours à l'écoute.
ouvrir firefox en temps que root ce n'est pas très recommandé, aussi ;)
ce qui limite suffisement les risques pour pouvoir dormir plus que tranquillement lorsque l'on n'est qu'un utilisateur qui ne s'est pas mis la mafia ou un cracker à dos.
on peut aussi mettre ses partitions de programmes en lecture seule, c'est encore plus simple (ça complique un peu les mises à jour, par contre)
Ce n'est pas on peu aussi, c'est on doit aussi ;)
-- Bastien
Le Sun, 28 Mar 2010 19:32:41 +0200, Stephane Catteau a écrit :
Bastien Durel n'était pas loin de dire :
Je ne sais pas pour vous, mais chez moi les binaires appartiennent à
root, et il n'est pas question de laisser qui que ce soit d'autre y
toucher.
A mon sens c'est un erreur. Chez moi aucun binaires pouvant servir de
point d'entrée, n'appartient à root, sauf lorsqu'il est totalment
impossible de faire autrement.
Le fait qu'ils appartiennent à root ne veut pas dire que c ést root que
les execute.
root fait tourner cron, racoon, sshd, ou qmail-lspawn ; pasqu'il n'y a
pas moyen de faire autrement, mais les autres serveurs tournent sous des
utilisateurs différents et n'ayant pas le droit d'écrire leurs binaires.
Et si les *BSD de la maison ne faisaient
pas tourner que des serveurs, je ferais la même chose pour les
applications tels que firefox, qui constituent elles aussi un point
d'entrée potentiel. Les donner à root revient à faciliter la tache de
l'attaquant, puisque s'il arrive à exploiter une faille il se retrouvera
immédiatement maître sur le système.
firefox ne tourne jamais que sous bastien, qui n'as pas le droit de faire
grand chose, si ce n'est monter les disques amovibles ou toucher à la
carte son.
A titre d'exemple, s'il existe une faille dans firefox au niveau
XMLHTTPRequest qui permettrait de lire/écrire sur le disque, le fait que
firefox appartienne à lui-même n'empèche pas la faille d'être exploitée
mais limite l'utilité de son exploitation. A l'inverse la même faille
avec firefox en root permet d'installer un trojan et de modifier les
scripts rc.d pour s'assurer qu'il sera toujours à l'écoute.
ouvrir firefox en temps que root ce n'est pas très recommandé, aussi ;)
ce qui limite suffisement les
risques pour pouvoir dormir plus que tranquillement lorsque l'on n'est
qu'un utilisateur qui ne s'est pas mis la mafia ou un cracker à dos.
on peut aussi mettre ses partitions de programmes en lecture seule,
c'est encore plus simple (ça complique un peu les mises à jour, par
contre)
Le Sun, 28 Mar 2010 19:32:41 +0200, Stephane Catteau a écrit :
Bastien Durel n'était pas loin de dire :
Je ne sais pas pour vous, mais chez moi les binaires appartiennent à root, et il n'est pas question de laisser qui que ce soit d'autre y toucher.
A mon sens c'est un erreur. Chez moi aucun binaires pouvant servir de point d'entrée, n'appartient à root, sauf lorsqu'il est totalment impossible de faire autrement.
Le fait qu'ils appartiennent à root ne veut pas dire que c ést root que les execute. root fait tourner cron, racoon, sshd, ou qmail-lspawn ; pasqu'il n'y a pas moyen de faire autrement, mais les autres serveurs tournent sous des utilisateurs différents et n'ayant pas le droit d'écrire leurs binaires.
Et si les *BSD de la maison ne faisaient pas tourner que des serveurs, je ferais la même chose pour les applications tels que firefox, qui constituent elles aussi un point d'entrée potentiel. Les donner à root revient à faciliter la tache de l'attaquant, puisque s'il arrive à exploiter une faille il se retrouvera immédiatement maître sur le système.
firefox ne tourne jamais que sous bastien, qui n'as pas le droit de faire grand chose, si ce n'est monter les disques amovibles ou toucher à la carte son.
A titre d'exemple, s'il existe une faille dans firefox au niveau XMLHTTPRequest qui permettrait de lire/écrire sur le disque, le fait que firefox appartienne à lui-même n'empèche pas la faille d'être exploitée mais limite l'utilité de son exploitation. A l'inverse la même faille avec firefox en root permet d'installer un trojan et de modifier les scripts rc.d pour s'assurer qu'il sera toujours à l'écoute.
ouvrir firefox en temps que root ce n'est pas très recommandé, aussi ;)
ce qui limite suffisement les risques pour pouvoir dormir plus que tranquillement lorsque l'on n'est qu'un utilisateur qui ne s'est pas mis la mafia ou un cracker à dos.
on peut aussi mettre ses partitions de programmes en lecture seule, c'est encore plus simple (ça complique un peu les mises à jour, par contre)
Ce n'est pas on peu aussi, c'est on doit aussi ;)
-- Bastien
Yliur
> on peut aussi mettre ses partitions de programmes en lecture seule, > c'est encore plus simple (ça complique un peu les mises à jour, par > contre)
Ce n'est pas on peu aussi, c'est on doit aussi ;)
Pourquoi ? Si tout ce qui est dessus appartient à root, je ne vois pas ce qu'apporte le fait de les mettre en lecture seule. Pour les modifier il faudrait avoir les droits de root, ce qui autorise à les remonter en lecture/écriture.
> on peut aussi mettre ses partitions de programmes en lecture seule,
> c'est encore plus simple (ça complique un peu les mises à jour, par
> contre)
Ce n'est pas on peu aussi, c'est on doit aussi ;)
Pourquoi ? Si tout ce qui est dessus appartient à root, je ne vois pas
ce qu'apporte le fait de les mettre en lecture seule. Pour les modifier
il faudrait avoir les droits de root, ce qui autorise à les remonter en
lecture/écriture.
> on peut aussi mettre ses partitions de programmes en lecture seule, > c'est encore plus simple (ça complique un peu les mises à jour, par > contre)
Ce n'est pas on peu aussi, c'est on doit aussi ;)
Pourquoi ? Si tout ce qui est dessus appartient à root, je ne vois pas ce qu'apporte le fait de les mettre en lecture seule. Pour les modifier il faudrait avoir les droits de root, ce qui autorise à les remonter en lecture/écriture.
Bastien Durel
Le Mon, 05 Apr 2010 00:13:34 +0200, Yliur a écrit :
Pourquoi ? Si tout ce qui est dessus appartient à root, je ne vois pas ce qu'apporte le fait de les mettre en lecture seule. Pour les modifier il faudrait avoir les droits de root, ce qui autorise à les remonter en lecture/écriture.
Pas forcément, si on utilise grsecurity avec kernel.grsecurity.romount_protect Et puis, il y a des failles qui permettent d'écrire à un emplacement arbitraire sans pour autant détourner le flot d'execution.
Le Mon, 05 Apr 2010 00:13:34 +0200, Yliur a écrit :
Pourquoi ? Si tout ce qui est dessus appartient à root, je ne vois pas
ce qu'apporte le fait de les mettre en lecture seule. Pour les modifier
il faudrait avoir les droits de root, ce qui autorise à les remonter en
lecture/écriture.
Pas forcément, si on utilise grsecurity avec
kernel.grsecurity.romount_protect
Et puis, il y a des failles qui permettent d'écrire à un emplacement
arbitraire sans pour autant détourner le flot d'execution.
Le Mon, 05 Apr 2010 00:13:34 +0200, Yliur a écrit :
Pourquoi ? Si tout ce qui est dessus appartient à root, je ne vois pas ce qu'apporte le fait de les mettre en lecture seule. Pour les modifier il faudrait avoir les droits de root, ce qui autorise à les remonter en lecture/écriture.
Pas forcément, si on utilise grsecurity avec kernel.grsecurity.romount_protect Et puis, il y a des failles qui permettent d'écrire à un emplacement arbitraire sans pour autant détourner le flot d'execution.
Stephane Catteau
Erwan David n'était pas loin de dire :
Sauf que le propriétaire du binaire n'a aucun lien avec l'utilisateur sous lequel il tourne.
Vi, j'ai réalisé ça (un bon moment) après avoir écrit. Du coup j'ai cherché d'où je tirais cette connerie, j'ai retrouvé une vieille todo list de sept ans et une URL qui pointe sur un site disparu :/ Autant c'était lié à une faille précise elle-même liée à un machin chose bien précis que j'utilisais à l'époque et en bon bourin que je suis j'ai suivi ma todo list aveuglément pendant des années, pour rien.
Rassurez-moi, je suis pas le seul à qui ça arrive des anneries pareilles, hein ? ;)
Erwan David n'était pas loin de dire :
Sauf que le propriétaire du binaire n'a aucun lien avec l'utilisateur
sous lequel il tourne.
Vi, j'ai réalisé ça (un bon moment) après avoir écrit. Du coup j'ai
cherché d'où je tirais cette connerie, j'ai retrouvé une vieille todo
list de sept ans et une URL qui pointe sur un site disparu :/
Autant c'était lié à une faille précise elle-même liée à un machin
chose bien précis que j'utilisais à l'époque et en bon bourin que je
suis j'ai suivi ma todo list aveuglément pendant des années, pour rien.
Rassurez-moi, je suis pas le seul à qui ça arrive des anneries
pareilles, hein ? ;)
Sauf que le propriétaire du binaire n'a aucun lien avec l'utilisateur sous lequel il tourne.
Vi, j'ai réalisé ça (un bon moment) après avoir écrit. Du coup j'ai cherché d'où je tirais cette connerie, j'ai retrouvé une vieille todo list de sept ans et une URL qui pointe sur un site disparu :/ Autant c'était lié à une faille précise elle-même liée à un machin chose bien précis que j'utilisais à l'époque et en bon bourin que je suis j'ai suivi ma todo list aveuglément pendant des années, pour rien.
Rassurez-moi, je suis pas le seul à qui ça arrive des anneries pareilles, hein ? ;)
Fabien LE LEZ
On Fri, 09 Apr 2010 16:50:38 +0200, Stephane Catteau :
Rassurez-moi, je suis pas le seul à qui ça arrive des anneries pareilles, hein ? ;)
Nan, ce genre de conneries est même catalogué en plusieurs sous-genres, au moins en programmation : http://en.wikipedia.org/wiki/Category:Anti-patterns
Je crois que dans le cas qui nous occupe ici, tu te rapproches du "cargo cult" : http://en.wikipedia.org/wiki/Cargo_cult_programming
On Fri, 09 Apr 2010 16:50:38 +0200, Stephane Catteau
<steph.nospam@sc4x.net>:
Rassurez-moi, je suis pas le seul à qui ça arrive des anneries
pareilles, hein ? ;)
Nan, ce genre de conneries est même catalogué en plusieurs
sous-genres, au moins en programmation :
http://en.wikipedia.org/wiki/Category:Anti-patterns
Je crois que dans le cas qui nous occupe ici, tu te rapproches du
"cargo cult" :
http://en.wikipedia.org/wiki/Cargo_cult_programming
On Fri, 09 Apr 2010 16:50:38 +0200, Stephane Catteau :
Rassurez-moi, je suis pas le seul à qui ça arrive des anneries pareilles, hein ? ;)
Nan, ce genre de conneries est même catalogué en plusieurs sous-genres, au moins en programmation : http://en.wikipedia.org/wiki/Category:Anti-patterns
Je crois que dans le cas qui nous occupe ici, tu te rapproches du "cargo cult" : http://en.wikipedia.org/wiki/Cargo_cult_programming
Stephane Catteau
Fabien LE LEZ n'était pas loin de dire :
Rassurez-moi, je suis pas le seul à qui ça arrive des anneries pareilles, hein ? ;)
Nan, [...]
Je me sens un peu moins stupide, mais il va falloir que je rajoute, "vérifier la validité de chaque point" en tête de ma todo-list. Parce que là c'était sans réelle conséquence, mais autant il y a/aura des petits trucs qui ne posent/posaient aucuns problèmes à l'époque où ils ont été ajoutés, mais qui ouvrent/ouvriront une brèche dans le futur.
Fabien LE LEZ n'était pas loin de dire :
Rassurez-moi, je suis pas le seul à qui ça arrive des anneries
pareilles, hein ? ;)
Nan, [...]
Je me sens un peu moins stupide, mais il va falloir que je rajoute,
"vérifier la validité de chaque point" en tête de ma todo-list. Parce
que là c'était sans réelle conséquence, mais autant il y a/aura des
petits trucs qui ne posent/posaient aucuns problèmes à l'époque où ils
ont été ajoutés, mais qui ouvrent/ouvriront une brèche dans le futur.
Rassurez-moi, je suis pas le seul à qui ça arrive des anneries pareilles, hein ? ;)
Nan, [...]
Je me sens un peu moins stupide, mais il va falloir que je rajoute, "vérifier la validité de chaque point" en tête de ma todo-list. Parce que là c'était sans réelle conséquence, mais autant il y a/aura des petits trucs qui ne posent/posaient aucuns problèmes à l'époque où ils ont été ajoutés, mais qui ouvrent/ouvriront une brèche dans le futur.
