pour plus de securité, j'envisages de lancer apache sous un autre
utilisateur que root
pour pouvoir y acceder en local, je pensais à faire un petit prgm qui
serait lancé sous root, qui ecouterait le port 80 et qui referais
simplement tout ce qu'il recois sur un autre port en tant que client
mais en fait, c'est rien que du NAT, ca, non ?
est ce que par hasard le systeme permettrais pas ce genre de chose
nativement ?
--
si je dors : wakeonlan -i tDeContes.hd.free.fr 00:03:93:AF:45:AE
(seulement dans le 1/4 h où mon ordi est mis en veille,
donc je vous invite à réclamer à free : l'acces à arp -s,
ou la possibilité de rediriger le NAT sur l'adresse de broadcast :-) )
"don't put your PC out of the window, put windows out of your PC"
"petit Free qui devient grand, gêne les requins blancs"
In article (Dans l'article) , Laurent Wacrenier <lwa@ teaser . fr> wrote (écrivait) :
Thomas écrit:
au fait mettre apache en user est ce que ca augmente reellement bcp la sécurité ?
Ça augmente d'avantage les ennuis que la sécurité.
ah bon, pourquoi ???
Notement, parce que le propriétaire du processus maître doit avoir accès en écriture sur la table de synchronisation des fils.
Les processus d'apache qui accèdent aux documents n'ont pas le privilège root.
oui, mais si le processus "pere", qui ecoute sur le port 80, est tjr sous root, un pirate a la possibilité de devenir root, nan ? il ne peut pirater que les processus fils qui ne sont plus root ?
Si apache avait un quelquonque trou de sécurité et que tu ne le mettais pas à jour, le pirate attaquerait l'un des fils, lancerait un shell et trouverait un autre trou de sécurité sur on système pas à jour.
Thomas <fantome.forums.tDeContes@free.fr> écrit:
In article (Dans l'article) <slrnd3dj00.q7h.lwa@victor.teaser.fr>,
Laurent Wacrenier <lwa@ teaser . fr> wrote (écrivait) :
Thomas <fantome.forums.tDeContes@free.fr> écrit:
au fait mettre apache en user est ce que ca augmente reellement bcp la
sécurité ?
Ça augmente d'avantage les ennuis que la sécurité.
ah bon, pourquoi ???
Notement, parce que le propriétaire du processus maître doit avoir
accès en écriture sur la table de synchronisation des fils.
Les processus d'apache qui accèdent aux documents n'ont pas le
privilège root.
oui, mais si le processus "pere", qui ecoute sur le port 80, est tjr
sous root,
un pirate a la possibilité de devenir root, nan ? il ne peut pirater que
les processus fils qui ne sont plus root ?
Si apache avait un quelquonque trou de sécurité et que tu ne le
mettais pas à jour, le pirate attaquerait l'un des fils, lancerait un
shell et trouverait un autre trou de sécurité sur on système pas à
jour.
In article (Dans l'article) , Laurent Wacrenier <lwa@ teaser . fr> wrote (écrivait) :
Thomas écrit:
au fait mettre apache en user est ce que ca augmente reellement bcp la sécurité ?
Ça augmente d'avantage les ennuis que la sécurité.
ah bon, pourquoi ???
Notement, parce que le propriétaire du processus maître doit avoir accès en écriture sur la table de synchronisation des fils.
Les processus d'apache qui accèdent aux documents n'ont pas le privilège root.
oui, mais si le processus "pere", qui ecoute sur le port 80, est tjr sous root, un pirate a la possibilité de devenir root, nan ? il ne peut pirater que les processus fils qui ne sont plus root ?
Si apache avait un quelquonque trou de sécurité et que tu ne le mettais pas à jour, le pirate attaquerait l'un des fils, lancerait un shell et trouverait un autre trou de sécurité sur on système pas à jour.
VANHULLEBUS Yvan
Thomas writes:
In article (Dans l'article) , VANHULLEBUS Yvan wrote (écrivait) :
[.....]
Euh, je suis loin d'etre un expert en configuration de Apache, mais il me semble que, comme pour beaucoup de demons, il est possible de le configurer en "je demarre en root, je fais ce que j'ai a faire en root (lire ma conf, binder le port 80, etc...) puis je droppe definitivement ce droit".
euh, t'es sur que le droit est droppé *definitivement* ?
Non, ma phrase commencait par "je suis loin d'etre un expert en configuration de Apache" (et j'aurais pu au passage omettre "configuration de").
il parait que le processus qui ecoute sur le port 80 reste en root
C'est possible, bien que je ne comprenne pas la necessite technique (une fois qu'on a fait le bind, c'est pas la peine de rester root pour pouvoir lire dessus et accepter les connexions entrantes...).
est tu sur qu'un pirate ne *peut pas* avoir le droit de root, et qu'il ne peut *que* prendre la main sur un processus deja passé en utilisateur ?
Non plus.
Mais comme dit dans un autre post du thread, une fois qu'on a la main en tant qu'utilisateur, on peut toujours commencer a chercher une autre faille quelquepart dans le systeme, pour passer root....
Ca serait pas la premiere fois qu'une attaque combinerait l'exploitation de plusieurs failles pour finalement arriver root sur la machine......
Ca me parait plus simple, plus propre et plus logique que de faire demarrer apache sur un autre port juste pour contourner le probleme du bind sur le port 80....
pour ca y a apparement un forward qui marche parait il tres bien
J'ai pas dit que ca marchait pas, juste que ca me paraissait lourd et pas propre, comme facon de proceder....
Sinon, si tu veux vraiment faire dans le "compartimente", tu forwades vers une pile IP virtuelle (y'a des projets assez aboutis au moins sous FreeBSD, mais aussi sous Linux, me semble), voire vers une machine virtuelle, voire meme vers une autre machine bien reelle (quoique ca ne resoud pas le "probleme de root", dans les derniers cas, ca limite juste les consequences).
Ou alors tu installes tout sur un media en lecture seule, comme ca l'attaquant ne pourra rien faire de vraiment dangereux, et il suffira de rebooter pour que tout disparaisse.... jusqu'a ce qu'il reexploite la faille ou que tu aies mis a jour.
Bref, tout ca pour dire que Apache qui tourne en "non root" (d'une facon ou d'une autre), c'est bien, mais faut pas se baser uniquement sur ca pour assurer la securite.....
Le principe d'une DMZ (puisque c'est bien de ca qu'il s'agit, finalement), c'est de compartimenter ce qui est a risques (mais en essayant quand meme de reduire les risques le plus possible), pas de se dire "boh, ca c'est compartimente, alors je suis tranquille et je risque rien quand ca va peter".
A +
VANHU.
Thomas <fantome.forums.tDeContes@free.fr> writes:
In article (Dans l'article) <87wts9jcx9.fsf@actarus.zen.inc>,
VANHULLEBUS Yvan <vanhu@nospam_free.fr> wrote (écrivait) :
[.....]
Euh, je suis loin d'etre un expert en configuration de Apache, mais il
me semble que, comme pour beaucoup de demons, il est possible de le
configurer en "je demarre en root, je fais ce que j'ai a faire en root
(lire ma conf, binder le port 80, etc...) puis je droppe
definitivement ce droit".
euh, t'es sur que le droit est droppé *definitivement* ?
Non, ma phrase commencait par "je suis loin d'etre un expert en
configuration de Apache" (et j'aurais pu au passage omettre
"configuration de").
il parait que le processus qui ecoute sur le port 80 reste en root
C'est possible, bien que je ne comprenne pas la necessite technique
(une fois qu'on a fait le bind, c'est pas la peine de rester root pour
pouvoir lire dessus et accepter les connexions entrantes...).
est tu sur qu'un pirate ne *peut pas* avoir le droit de root, et qu'il
ne peut *que* prendre la main sur un processus deja passé en utilisateur
?
Non plus.
Mais comme dit dans un autre post du thread, une fois qu'on a la main
en tant qu'utilisateur, on peut toujours commencer a chercher une
autre faille quelquepart dans le systeme, pour passer root....
Ca serait pas la premiere fois qu'une attaque combinerait
l'exploitation de plusieurs failles pour finalement arriver root sur
la machine......
Ca me parait plus simple, plus propre et plus logique que de faire
demarrer apache sur un autre port juste pour contourner le probleme du
bind sur le port 80....
pour ca y a apparement un forward qui marche parait il tres bien
J'ai pas dit que ca marchait pas, juste que ca me paraissait lourd et
pas propre, comme facon de proceder....
Sinon, si tu veux vraiment faire dans le "compartimente", tu forwades
vers une pile IP virtuelle (y'a des projets assez aboutis au moins
sous FreeBSD, mais aussi sous Linux, me semble), voire vers une
machine virtuelle, voire meme vers une autre machine bien reelle
(quoique ca ne resoud pas le "probleme de root", dans les derniers
cas, ca limite juste les consequences).
Ou alors tu installes tout sur un media en lecture seule, comme ca
l'attaquant ne pourra rien faire de vraiment dangereux, et il suffira
de rebooter pour que tout disparaisse.... jusqu'a ce qu'il reexploite
la faille ou que tu aies mis a jour.
Bref, tout ca pour dire que Apache qui tourne en "non root" (d'une
facon ou d'une autre), c'est bien, mais faut pas se baser uniquement
sur ca pour assurer la securite.....
Le principe d'une DMZ (puisque c'est bien de ca qu'il s'agit,
finalement), c'est de compartimenter ce qui est a risques (mais en
essayant quand meme de reduire les risques le plus possible), pas de
se dire "boh, ca c'est compartimente, alors je suis tranquille et je
risque rien quand ca va peter".
In article (Dans l'article) , VANHULLEBUS Yvan wrote (écrivait) :
[.....]
Euh, je suis loin d'etre un expert en configuration de Apache, mais il me semble que, comme pour beaucoup de demons, il est possible de le configurer en "je demarre en root, je fais ce que j'ai a faire en root (lire ma conf, binder le port 80, etc...) puis je droppe definitivement ce droit".
euh, t'es sur que le droit est droppé *definitivement* ?
Non, ma phrase commencait par "je suis loin d'etre un expert en configuration de Apache" (et j'aurais pu au passage omettre "configuration de").
il parait que le processus qui ecoute sur le port 80 reste en root
C'est possible, bien que je ne comprenne pas la necessite technique (une fois qu'on a fait le bind, c'est pas la peine de rester root pour pouvoir lire dessus et accepter les connexions entrantes...).
est tu sur qu'un pirate ne *peut pas* avoir le droit de root, et qu'il ne peut *que* prendre la main sur un processus deja passé en utilisateur ?
Non plus.
Mais comme dit dans un autre post du thread, une fois qu'on a la main en tant qu'utilisateur, on peut toujours commencer a chercher une autre faille quelquepart dans le systeme, pour passer root....
Ca serait pas la premiere fois qu'une attaque combinerait l'exploitation de plusieurs failles pour finalement arriver root sur la machine......
Ca me parait plus simple, plus propre et plus logique que de faire demarrer apache sur un autre port juste pour contourner le probleme du bind sur le port 80....
pour ca y a apparement un forward qui marche parait il tres bien
J'ai pas dit que ca marchait pas, juste que ca me paraissait lourd et pas propre, comme facon de proceder....
Sinon, si tu veux vraiment faire dans le "compartimente", tu forwades vers une pile IP virtuelle (y'a des projets assez aboutis au moins sous FreeBSD, mais aussi sous Linux, me semble), voire vers une machine virtuelle, voire meme vers une autre machine bien reelle (quoique ca ne resoud pas le "probleme de root", dans les derniers cas, ca limite juste les consequences).
Ou alors tu installes tout sur un media en lecture seule, comme ca l'attaquant ne pourra rien faire de vraiment dangereux, et il suffira de rebooter pour que tout disparaisse.... jusqu'a ce qu'il reexploite la faille ou que tu aies mis a jour.
Bref, tout ca pour dire que Apache qui tourne en "non root" (d'une facon ou d'une autre), c'est bien, mais faut pas se baser uniquement sur ca pour assurer la securite.....
Le principe d'une DMZ (puisque c'est bien de ca qu'il s'agit, finalement), c'est de compartimenter ce qui est a risques (mais en essayant quand meme de reduire les risques le plus possible), pas de se dire "boh, ca c'est compartimente, alors je suis tranquille et je risque rien quand ca va peter".
A +
VANHU.
Kevin Denis
Le 15-03-2005, Thomas a écrit :
pour plus de securité, j'envisages de lancer apache sous un autre utilisateur que root
pour pouvoir y acceder en local, je pensais à faire un petit prgm qui serait lancé sous root, qui ecouterait le port 80 et qui referais simplement tout ce qu'il recois sur un autre port en tant que client
mais en fait, c'est rien que du NAT, ca, non ?
PAT plutot, non? Port Adress Translation.
est ce que par hasard le systeme permettrais pas ce genre de chose nativement ?
1. sous linux tu as iptables qui fait ca tres bien
sous Mac, il faudrait voir avec ipf sans doute.
2. Pourquoi ne pas donner l'adresse de ton site web sous la forme: http://mon.site.a.moi:8080/ et la, apache tourne bien en user sous le port 8080
-- Kevin
Le 15-03-2005, Thomas <fantome.forums.tDeContes@free.fr> a écrit :
pour plus de securité, j'envisages de lancer apache sous un autre
utilisateur que root
pour pouvoir y acceder en local, je pensais à faire un petit prgm qui
serait lancé sous root, qui ecouterait le port 80 et qui referais
simplement tout ce qu'il recois sur un autre port en tant que client
mais en fait, c'est rien que du NAT, ca, non ?
PAT plutot, non? Port Adress Translation.
est ce que par hasard le systeme permettrais pas ce genre de chose
nativement ?
1. sous linux tu as iptables qui fait ca tres bien
sous Mac, il faudrait voir avec ipf sans doute.
2. Pourquoi ne pas donner l'adresse de ton site web sous la forme:
http://mon.site.a.moi:8080/
et la, apache tourne bien en user sous le port 8080
pour plus de securité, j'envisages de lancer apache sous un autre utilisateur que root
pour pouvoir y acceder en local, je pensais à faire un petit prgm qui serait lancé sous root, qui ecouterait le port 80 et qui referais simplement tout ce qu'il recois sur un autre port en tant que client
mais en fait, c'est rien que du NAT, ca, non ?
PAT plutot, non? Port Adress Translation.
est ce que par hasard le systeme permettrais pas ce genre de chose nativement ?
1. sous linux tu as iptables qui fait ca tres bien
sous Mac, il faudrait voir avec ipf sans doute.
2. Pourquoi ne pas donner l'adresse de ton site web sous la forme: http://mon.site.a.moi:8080/ et la, apache tourne bien en user sous le port 8080
-- Kevin
Nicolas Le Scouarnec
Ca me parait plus simple, plus propre et plus logique que de faire demarrer apache sur un autre port juste pour contourner le probleme du bind sur le port 80.... pour ca y a apparement un forward qui marche parait il tres bien
Effectivement, mais j'ai autre chose pour te dissuader, dans apache, si on utilise des Virtual Host, il faut faire très attention a la configuration des ports d'écoutes et a l'interface d'écoute, ca devient vite une prise de tete quand on fait des forward et qu'on ne sait plus vraiment ce qu'on a configuré auparavant.
Sinon, le processus qui répond laisse tomber les droits root, il n'y a que le processus "maitre" qui doit continuer a tourner en root, mais il ne se charge que de relancer d'autres threads/processus.
-- Nicolas Le Scouarnec
Ca me parait plus simple, plus propre et plus logique que de faire
demarrer apache sur un autre port juste pour contourner le probleme du
bind sur le port 80....
pour ca y a apparement un forward qui marche parait il tres bien
Effectivement, mais j'ai autre chose pour te dissuader, dans apache, si
on utilise des Virtual Host, il faut faire très attention a la
configuration des ports d'écoutes et a l'interface d'écoute, ca devient
vite une prise de tete quand on fait des forward et qu'on ne sait plus
vraiment ce qu'on a configuré auparavant.
Sinon, le processus qui répond laisse tomber les droits root, il n'y a
que le processus "maitre" qui doit continuer a tourner en root, mais il
ne se charge que de relancer d'autres threads/processus.
Ca me parait plus simple, plus propre et plus logique que de faire demarrer apache sur un autre port juste pour contourner le probleme du bind sur le port 80.... pour ca y a apparement un forward qui marche parait il tres bien
Effectivement, mais j'ai autre chose pour te dissuader, dans apache, si on utilise des Virtual Host, il faut faire très attention a la configuration des ports d'écoutes et a l'interface d'écoute, ca devient vite une prise de tete quand on fait des forward et qu'on ne sait plus vraiment ce qu'on a configuré auparavant.
Sinon, le processus qui répond laisse tomber les droits root, il n'y a que le processus "maitre" qui doit continuer a tourner en root, mais il ne se charge que de relancer d'autres threads/processus.
-- Nicolas Le Scouarnec
Rakotomandimby (R12y) Mihamina
( Tue, 15 Mar 2005 12:45:15 +0100 ) Thomas :
au fait mettre apache en user est ce que ca augmente reellement bcp la sécurité ?
Tu peux le mettre en user et qui tourne sur 80. Apache sait se forker... -- En mal de support technique? http://supports.etud-orleans.fr/ Infogerance de serveur dedie http://aspo.rktmb.org/activites/infogerance (En louant les services de l'ASPO vous luttez contre la fracture numerique) Etudiants de l'Universite d'Orleans: http://www.etud-orleans.fr/
( Tue, 15 Mar 2005 12:45:15 +0100 ) Thomas :
au fait mettre apache en user est ce que ca augmente reellement bcp la
sécurité ?
Tu peux le mettre en user et qui tourne sur 80. Apache sait se forker...
--
En mal de support technique? http://supports.etud-orleans.fr/
Infogerance de serveur dedie http://aspo.rktmb.org/activites/infogerance
(En louant les services de l'ASPO vous luttez contre la fracture numerique)
Etudiants de l'Universite d'Orleans: http://www.etud-orleans.fr/
au fait mettre apache en user est ce que ca augmente reellement bcp la sécurité ?
Tu peux le mettre en user et qui tourne sur 80. Apache sait se forker... -- En mal de support technique? http://supports.etud-orleans.fr/ Infogerance de serveur dedie http://aspo.rktmb.org/activites/infogerance (En louant les services de l'ASPO vous luttez contre la fracture numerique) Etudiants de l'Universite d'Orleans: http://www.etud-orleans.fr/
Rakotomandimby (R12y) Mihamina
( Tue, 15 Mar 2005 12:10:57 +0100 ) Thomas :
Thomas Thomas Thomas...
Décidément tu es paranoiaque... sans conteste.
- Apache sait se lancer en root et se forke en autant de processes qu'indiqués (*), sous l'user indiqué (*)
- Si tu as entendu parler de ce genre de "technique" dans un document relatif à la sécurité des serveurs Web, alors, montre nous ce document, s'il te plait. Sinon, si c'est le fruit de ton imagination, sache que tu cours plus de risque que la moyenne, parceque ton "truc &astuce" que _tu_ as développé, tu l'a fait tout seul dans ton coin et n'a donc pas été mis à l'épreuve des commentaires de gens "spécialistes".... il sera plus facile pour un individu malveillant de contourner la sécurité de ton "système" que de contourner tous les efforts déployés par la centaine de developpeurs qui sont passé sur le code d'Apache.
(*) Dans son fichier de conf. -- En mal de support technique? http://supports.etud-orleans.fr/ Infogerance de serveur dedie http://aspo.rktmb.org/activites/infogerance (En louant les services de l'ASPO vous luttez contre la fracture numerique) Etudiants de l'Universite d'Orleans: http://www.etud-orleans.fr/
( Tue, 15 Mar 2005 12:10:57 +0100 ) Thomas :
Thomas Thomas Thomas...
Décidément tu es paranoiaque... sans conteste.
- Apache sait se lancer en root et se forke en autant de processes
qu'indiqués (*), sous l'user indiqué (*)
- Si tu as entendu parler de ce genre de "technique" dans un document
relatif à la sécurité des serveurs Web, alors, montre nous ce document,
s'il te plait. Sinon, si c'est le fruit de ton imagination, sache que tu
cours plus de risque que la moyenne, parceque ton "truc &astuce" que _tu_
as développé, tu l'a fait tout seul dans ton coin et n'a donc pas été
mis à l'épreuve des commentaires de gens "spécialistes".... il sera
plus facile pour un individu malveillant de contourner la sécurité de
ton "système" que de contourner tous les efforts déployés par la
centaine de developpeurs qui sont passé sur le code d'Apache.
(*) Dans son fichier de conf.
--
En mal de support technique? http://supports.etud-orleans.fr/
Infogerance de serveur dedie http://aspo.rktmb.org/activites/infogerance
(En louant les services de l'ASPO vous luttez contre la fracture numerique)
Etudiants de l'Universite d'Orleans: http://www.etud-orleans.fr/
- Apache sait se lancer en root et se forke en autant de processes qu'indiqués (*), sous l'user indiqué (*)
- Si tu as entendu parler de ce genre de "technique" dans un document relatif à la sécurité des serveurs Web, alors, montre nous ce document, s'il te plait. Sinon, si c'est le fruit de ton imagination, sache que tu cours plus de risque que la moyenne, parceque ton "truc &astuce" que _tu_ as développé, tu l'a fait tout seul dans ton coin et n'a donc pas été mis à l'épreuve des commentaires de gens "spécialistes".... il sera plus facile pour un individu malveillant de contourner la sécurité de ton "système" que de contourner tous les efforts déployés par la centaine de developpeurs qui sont passé sur le code d'Apache.
(*) Dans son fichier de conf. -- En mal de support technique? http://supports.etud-orleans.fr/ Infogerance de serveur dedie http://aspo.rktmb.org/activites/infogerance (En louant les services de l'ASPO vous luttez contre la fracture numerique) Etudiants de l'Universite d'Orleans: http://www.etud-orleans.fr/
cedric
Rakotomandimby (R12y) Mihamina wrote:
il sera plus facile pour un individu malveillant de contourner la sécurité de ton "système" que de contourner tous les efforts déployés par la centaine de developpeurs qui sont passé sur le code d'Apache.
Bof bof bof...
La plupart des attaques visent des systèmes biens précis. Si tu fait un truc maison, même objectivement moins solide, tu te met à l'abris de tous les scripts dirigés contre un type d'installation précis.
Alors, bof bof bof...
Rakotomandimby (R12y) Mihamina wrote:
il sera
plus facile pour un individu malveillant de contourner la sécurité de
ton "système" que de contourner tous les efforts déployés par la
centaine de developpeurs qui sont passé sur le code d'Apache.
Bof bof bof...
La plupart des attaques visent des systèmes biens précis. Si tu fait un
truc maison, même objectivement moins solide, tu te met à l'abris de
tous les scripts dirigés contre un type d'installation précis.
il sera plus facile pour un individu malveillant de contourner la sécurité de ton "système" que de contourner tous les efforts déployés par la centaine de developpeurs qui sont passé sur le code d'Apache.
Bof bof bof...
La plupart des attaques visent des systèmes biens précis. Si tu fait un truc maison, même objectivement moins solide, tu te met à l'abris de tous les scripts dirigés contre un type d'installation précis.
Alors, bof bof bof...
Rakotomandimby (R12y) Mihamina
( Tue, 15 Mar 2005 13:45:10 +0100 ) Thomas :
Thomas écrit:
au fait mettre apache en user est ce que ca augmente reellement bcp la sécurité ? Ça augmente d'avantage les ennuis que la sécurité.
ah bon, pourquoi ???
parceque
Les processus d'apache qui accèdent aux documents n'ont pas le privilège root. oui, mais si le processus "pere", qui ecoute sur le port 80, est tjr
sous root, un pirate a la possibilité de devenir root, nan ? il ne peut pirater que les processus fils qui ne sont plus root ?
Si apache permettait de devenir root "comme ça", ça se saurait. Si les "pirates" arrivent à devenir root, c'est essentiellement à cause des scripts (cgi, php, ...) mal foutus.
C'est du ressort de fr.comp.securite (modéré)
-- En mal de support technique? http://supports.etud-orleans.fr/ Infogerance de serveur dedie http://aspo.rktmb.org/activites/infogerance (En louant les services de l'ASPO vous luttez contre la fracture numerique) Etudiants de l'Universite d'Orleans: http://www.etud-orleans.fr/
( Tue, 15 Mar 2005 13:45:10 +0100 ) Thomas :
Thomas <fantome.forums.tDeContes@free.fr> écrit:
au fait mettre apache en user est ce que ca augmente reellement bcp la
sécurité ?
Ça augmente d'avantage les ennuis que la sécurité.
ah bon, pourquoi ???
parceque
Les processus d'apache qui accèdent aux documents n'ont pas le
privilège root.
oui, mais si le processus "pere", qui ecoute sur le port 80, est tjr
sous root,
un pirate a la possibilité de devenir root, nan ? il ne peut pirater
que les processus fils qui ne sont plus root ?
Si apache permettait de devenir root "comme ça", ça se saurait.
Si les "pirates" arrivent à devenir root, c'est essentiellement à cause
des scripts (cgi, php, ...) mal foutus.
C'est du ressort de fr.comp.securite (modéré)
--
En mal de support technique? http://supports.etud-orleans.fr/
Infogerance de serveur dedie http://aspo.rktmb.org/activites/infogerance
(En louant les services de l'ASPO vous luttez contre la fracture numerique)
Etudiants de l'Universite d'Orleans: http://www.etud-orleans.fr/
au fait mettre apache en user est ce que ca augmente reellement bcp la sécurité ? Ça augmente d'avantage les ennuis que la sécurité.
ah bon, pourquoi ???
parceque
Les processus d'apache qui accèdent aux documents n'ont pas le privilège root. oui, mais si le processus "pere", qui ecoute sur le port 80, est tjr
sous root, un pirate a la possibilité de devenir root, nan ? il ne peut pirater que les processus fils qui ne sont plus root ?
Si apache permettait de devenir root "comme ça", ça se saurait. Si les "pirates" arrivent à devenir root, c'est essentiellement à cause des scripts (cgi, php, ...) mal foutus.
C'est du ressort de fr.comp.securite (modéré)
-- En mal de support technique? http://supports.etud-orleans.fr/ Infogerance de serveur dedie http://aspo.rktmb.org/activites/infogerance (En louant les services de l'ASPO vous luttez contre la fracture numerique) Etudiants de l'Universite d'Orleans: http://www.etud-orleans.fr/
Rakotomandimby (R12y) Mihamina
( Tue, 15 Mar 2005 22:04:30 +0100 ) cedric :
La plupart des attaques visent des systèmes biens précis. Si tu fait un truc maison, même objectivement moins solide, tu te met à l'abris de tous les scripts dirigés contre un type d'installation précis.
mise au point:
- son truc maison à lui, il ne fait _que_ de faire suivre d'un port vers un autre, sans filtrage. - par défaut, apache propose de tourner sous un user non-root après le lancement (ex: sur Debian, c'est www-data). - explique-moi (justement sur son cas bien précis) comment www-data serait plus sûr que "toto". dans son cas bien prcis, il n'y aura pas de filtrage (il n'a rien evoqué dans ce sens), c'est _juste_ de la redirection. Et tout de suite apres cette redirection on retrouve un système apache on ne peut plus normal.
De plus, comme je connais un peu Thomas (il poste aussi sur fr.*.droit.internet, et fr.*.hebergement, et aussi sur fr.*.www.serveurs auxquels je suis aussi abonné) en cas de pépin, il va demander de l'aide et avec une configuration exotique (comme il projette de le faire) personne ne pourra rien pour lui. On lui demandera de toutes façon de tourner d'abord sur un système simple avant de lui fournir une quelconque aide... donc...
-- En mal de support technique? http://supports.etud-orleans.fr/ Infogerance de serveur dedie http://aspo.rktmb.org/activites/infogerance (En louant les services de l'ASPO vous luttez contre la fracture numerique) Etudiants de l'Universite d'Orleans: http://www.etud-orleans.fr/
( Tue, 15 Mar 2005 22:04:30 +0100 ) cedric :
La plupart des attaques visent des systèmes biens précis. Si tu fait un
truc maison, même objectivement moins solide, tu te met à l'abris de
tous les scripts dirigés contre un type d'installation précis.
mise au point:
- son truc maison à lui, il ne fait _que_ de faire suivre d'un port vers
un autre, sans filtrage.
- par défaut, apache propose de tourner sous un user non-root après le
lancement (ex: sur Debian, c'est www-data).
- explique-moi (justement sur son cas bien précis) comment www-data
serait plus sûr que "toto". dans son cas bien prcis, il n'y aura pas de
filtrage (il n'a rien evoqué dans ce sens), c'est _juste_ de la
redirection. Et tout de suite apres cette redirection on retrouve un
système apache on ne peut plus normal.
De plus, comme je connais un peu Thomas (il poste aussi sur
fr.*.droit.internet, et fr.*.hebergement, et aussi sur fr.*.www.serveurs
auxquels je suis aussi abonné) en cas de pépin, il va demander de l'aide
et avec une configuration exotique (comme il projette de le faire)
personne ne pourra rien pour lui. On lui demandera de toutes façon de
tourner d'abord sur un système simple avant de lui fournir une quelconque
aide... donc...
--
En mal de support technique? http://supports.etud-orleans.fr/
Infogerance de serveur dedie http://aspo.rktmb.org/activites/infogerance
(En louant les services de l'ASPO vous luttez contre la fracture numerique)
Etudiants de l'Universite d'Orleans: http://www.etud-orleans.fr/
La plupart des attaques visent des systèmes biens précis. Si tu fait un truc maison, même objectivement moins solide, tu te met à l'abris de tous les scripts dirigés contre un type d'installation précis.
mise au point:
- son truc maison à lui, il ne fait _que_ de faire suivre d'un port vers un autre, sans filtrage. - par défaut, apache propose de tourner sous un user non-root après le lancement (ex: sur Debian, c'est www-data). - explique-moi (justement sur son cas bien précis) comment www-data serait plus sûr que "toto". dans son cas bien prcis, il n'y aura pas de filtrage (il n'a rien evoqué dans ce sens), c'est _juste_ de la redirection. Et tout de suite apres cette redirection on retrouve un système apache on ne peut plus normal.
De plus, comme je connais un peu Thomas (il poste aussi sur fr.*.droit.internet, et fr.*.hebergement, et aussi sur fr.*.www.serveurs auxquels je suis aussi abonné) en cas de pépin, il va demander de l'aide et avec une configuration exotique (comme il projette de le faire) personne ne pourra rien pour lui. On lui demandera de toutes façon de tourner d'abord sur un système simple avant de lui fournir une quelconque aide... donc...
-- En mal de support technique? http://supports.etud-orleans.fr/ Infogerance de serveur dedie http://aspo.rktmb.org/activites/infogerance (En louant les services de l'ASPO vous luttez contre la fracture numerique) Etudiants de l'Universite d'Orleans: http://www.etud-orleans.fr/
cedric
Rakotomandimby (R12y) Mihamina wrote:
- son truc maison à lui, il ne fait _que_ de faire suivre d'un port vers un autre, sans filtrage.
Moui. Je généralisais.
Sinon, oui, un utilisateur toto est plus sur qu'un utilisateur www-data. Extraits de mes logs :
Mar 8 01:33:50 happyleptic sshd[40226]: Failed password for www from 134.102.219.162 port 14948 ssh2 Mar 8 01:33:58 happyleptic sshd[40242]: Failed password for mysql from 134.102.219.162 port 15947 ssh2 Mar 8 01:33:59 happyleptic sshd[40244]: Failed password for operator from 134.102.219.162 port 15988 ssh2
où l'on voit que les utilisateurs "standards" se font tester au dictionnaire ; pas "toto" ;-p
Rakotomandimby (R12y) Mihamina wrote:
- son truc maison à lui, il ne fait _que_ de faire suivre d'un port vers
un autre, sans filtrage.
Moui. Je généralisais.
Sinon, oui, un utilisateur toto est plus sur qu'un utilisateur www-data.
Extraits de mes logs :
Mar 8 01:33:50 happyleptic sshd[40226]: Failed password for www from
134.102.219.162 port 14948 ssh2
Mar 8 01:33:58 happyleptic sshd[40242]: Failed password for mysql from
134.102.219.162 port 15947 ssh2
Mar 8 01:33:59 happyleptic sshd[40244]: Failed password for operator
from 134.102.219.162 port 15988 ssh2
où l'on voit que les utilisateurs "standards" se font tester au
dictionnaire ; pas "toto" ;-p
- son truc maison à lui, il ne fait _que_ de faire suivre d'un port vers un autre, sans filtrage.
Moui. Je généralisais.
Sinon, oui, un utilisateur toto est plus sur qu'un utilisateur www-data. Extraits de mes logs :
Mar 8 01:33:50 happyleptic sshd[40226]: Failed password for www from 134.102.219.162 port 14948 ssh2 Mar 8 01:33:58 happyleptic sshd[40242]: Failed password for mysql from 134.102.219.162 port 15947 ssh2 Mar 8 01:33:59 happyleptic sshd[40244]: Failed password for operator from 134.102.219.162 port 15988 ssh2
où l'on voit que les utilisateurs "standards" se font tester au dictionnaire ; pas "toto" ;-p
