J'aurais voulu savoir pourquoi il est fortement déconseillé de laisser
l'utilisateur root se connecter en ssh alors que la directive
PermitRootLogin no
du sshd_config n'empêche pas une fois loggé en utilisateur normal de
passer en root avec la commande su. Je comprends bien que c'est plus
difficile d'obtenir les droits root puisqu'il faut 2 mots de passe, mais
j'aurais voulu savoir s'il y a d'autres raisons.
Le Wed, 13 Apr 2005 20:35:06 +0000, Laurent Blume a écrit :
Il est tout de même bien pratique de pouvoir se connecter en root à distance pour pouvoir lancer, par exemple, des sauvegardes automatisées. C'est d'ailleurs l'exemple donné dans le man.
ON peut aussi créer un utilisateur "backup" autorisé à se connecter à distance, avec des droits très limités mais la possibilité de lancer un "sudo <commande de backup>". Ça me paraît plus sûr.
-- Sutor ne ultra Crepidam.
Le Wed, 13 Apr 2005 20:35:06 +0000, Laurent Blume a écrit :
Il est tout de même bien pratique de pouvoir se connecter en root à
distance pour pouvoir lancer, par exemple, des sauvegardes automatisées.
C'est d'ailleurs l'exemple donné dans le man.
ON peut aussi créer un utilisateur "backup" autorisé à se connecter à
distance, avec des droits très limités mais la possibilité de lancer un
"sudo <commande de backup>". Ça me paraît plus sûr.
Le Wed, 13 Apr 2005 20:35:06 +0000, Laurent Blume a écrit :
Il est tout de même bien pratique de pouvoir se connecter en root à distance pour pouvoir lancer, par exemple, des sauvegardes automatisées. C'est d'ailleurs l'exemple donné dans le man.
ON peut aussi créer un utilisateur "backup" autorisé à se connecter à distance, avec des droits très limités mais la possibilité de lancer un "sudo <commande de backup>". Ça me paraît plus sûr.
-- Sutor ne ultra Crepidam.
Cedric Blancher
Le Thu, 14 Apr 2005 07:58:20 +0000, Emmanuel Florac a écrit :
ON peut aussi créer un utilisateur "backup" autorisé à se connecter à distance, avec des droits très limités mais la possibilité de lancer un "sudo <commande de backup>". Ça me paraît plus sûr.
C'est tout l'intérêt des outils comme sudo ou super : distribuer des privilèges au goutte à goutte. Sinon, sudo ne présente pas d'intérêt.
Si la machine n'a qu'un seul admin, le mot de passe utilisé pour se loguer et celui pour passer en root avec sudo est le même. Donc pas d'intérêt. Si la machine a plusieurs admins qui ont tous les droits, pas plus d'intérêt entre "su -" et "sudo -s", sinon que dans le second cas, on ne divulgue pas le pass root, mais on garde le même que celui du user, ce qui peut présenter un problème.
Sudo est amha très utile quand on a plusieurs admin qui n'ont pas les mêmes droits. Les autres cas sont discutables, et pas tous en faveur de sudo, loin de là.
-- JCP : Oui, j'ai cru remarquer que les gens n'étaient pas très ...détendus... sur fr.usenet.forums.evolution FB : Normal. Il faut être tendu pour violenter ces pauvres mouches. -+- in: Guide du Cabaliste Usenet - Les enfilades sous tension -+-
Le Thu, 14 Apr 2005 07:58:20 +0000, Emmanuel Florac a écrit :
ON peut aussi créer un utilisateur "backup" autorisé à se connecter à
distance, avec des droits très limités mais la possibilité de lancer un
"sudo <commande de backup>". Ça me paraît plus sûr.
C'est tout l'intérêt des outils comme sudo ou super : distribuer des
privilèges au goutte à goutte. Sinon, sudo ne présente pas d'intérêt.
Si la machine n'a qu'un seul admin, le mot de passe utilisé pour se
loguer et celui pour passer en root avec sudo est le même. Donc pas
d'intérêt. Si la machine a plusieurs admins qui ont tous les droits, pas
plus d'intérêt entre "su -" et "sudo -s", sinon que dans le second cas,
on ne divulgue pas le pass root, mais on garde le même que celui du user,
ce qui peut présenter un problème.
Sudo est amha très utile quand on a plusieurs admin qui n'ont pas les
mêmes droits. Les autres cas sont discutables, et pas tous en faveur de
sudo, loin de là.
--
JCP : Oui, j'ai cru remarquer que les gens n'étaient pas très
...détendus... sur fr.usenet.forums.evolution
FB : Normal. Il faut être tendu pour violenter ces pauvres mouches.
-+- in: Guide du Cabaliste Usenet - Les enfilades sous tension -+-
Le Thu, 14 Apr 2005 07:58:20 +0000, Emmanuel Florac a écrit :
ON peut aussi créer un utilisateur "backup" autorisé à se connecter à distance, avec des droits très limités mais la possibilité de lancer un "sudo <commande de backup>". Ça me paraît plus sûr.
C'est tout l'intérêt des outils comme sudo ou super : distribuer des privilèges au goutte à goutte. Sinon, sudo ne présente pas d'intérêt.
Si la machine n'a qu'un seul admin, le mot de passe utilisé pour se loguer et celui pour passer en root avec sudo est le même. Donc pas d'intérêt. Si la machine a plusieurs admins qui ont tous les droits, pas plus d'intérêt entre "su -" et "sudo -s", sinon que dans le second cas, on ne divulgue pas le pass root, mais on garde le même que celui du user, ce qui peut présenter un problème.
Sudo est amha très utile quand on a plusieurs admin qui n'ont pas les mêmes droits. Les autres cas sont discutables, et pas tous en faveur de sudo, loin de là.
-- JCP : Oui, j'ai cru remarquer que les gens n'étaient pas très ...détendus... sur fr.usenet.forums.evolution FB : Normal. Il faut être tendu pour violenter ces pauvres mouches. -+- in: Guide du Cabaliste Usenet - Les enfilades sous tension -+-
Fabien LE LEZ
On 14 Apr 2005 07:58:20 GMT, Emmanuel Florac :
ON peut aussi créer un utilisateur "backup" autorisé à se connecter à distance, avec des droits très limités mais la possibilité de lancer un "sudo <commande de backup>".
J'ai du mal à suivre, là : s'il s'agit de faire un backup, n'est-il pas possible de créer un utilisateur avec des droits en lecture partout (sauf sur le fichier contenant effectivement les mots de passe), et des droits en écriture nulle part ?
-- ;-)
On 14 Apr 2005 07:58:20 GMT, Emmanuel Florac <eflorac@imaginet.fr>:
ON peut aussi créer un utilisateur "backup" autorisé à se connecter à
distance, avec des droits très limités mais la possibilité de lancer un
"sudo <commande de backup>".
J'ai du mal à suivre, là : s'il s'agit de faire un backup, n'est-il
pas possible de créer un utilisateur avec des droits en lecture
partout (sauf sur le fichier contenant effectivement les mots de
passe), et des droits en écriture nulle part ?
ON peut aussi créer un utilisateur "backup" autorisé à se connecter à distance, avec des droits très limités mais la possibilité de lancer un "sudo <commande de backup>".
J'ai du mal à suivre, là : s'il s'agit de faire un backup, n'est-il pas possible de créer un utilisateur avec des droits en lecture partout (sauf sur le fichier contenant effectivement les mots de passe), et des droits en écriture nulle part ?
-- ;-)
Vincent Bernat
OoO En cette matinée pluvieuse du jeudi 14 avril 2005, vers 10:59, Fabien LE LEZ disait:
ON peut aussi créer un utilisateur "backup" autorisé à se connecter à distance, avec des droits très limités mais la possibilité de lancer un "sudo <commande de backup>".
J'ai du mal à suivre, là : s'il s'agit de faire un backup, n'est-il pas possible de créer un utilisateur avec des droits en lecture partout (sauf sur le fichier contenant effectivement les mots de passe), et des droits en écriture nulle part ?
Avec les droits Unix classique, c'est assez compliqué. -- printk("HPFS: Grrrr... Kernel memory corrupted ... going on, but it'll crash very soon :-(n"); 2.4.3 linux/fs/hpfs/super.c
OoO En cette matinée pluvieuse du jeudi 14 avril 2005, vers 10:59,
Fabien LE LEZ <gramster@gramster.com> disait:
ON peut aussi créer un utilisateur "backup" autorisé à se connecter à
distance, avec des droits très limités mais la possibilité de lancer un
"sudo <commande de backup>".
J'ai du mal à suivre, là : s'il s'agit de faire un backup, n'est-il
pas possible de créer un utilisateur avec des droits en lecture
partout (sauf sur le fichier contenant effectivement les mots de
passe), et des droits en écriture nulle part ?
Avec les droits Unix classique, c'est assez compliqué.
--
printk("HPFS: Grrrr... Kernel memory corrupted ... going on, but
it'll crash very soon :-(n");
2.4.3 linux/fs/hpfs/super.c
OoO En cette matinée pluvieuse du jeudi 14 avril 2005, vers 10:59, Fabien LE LEZ disait:
ON peut aussi créer un utilisateur "backup" autorisé à se connecter à distance, avec des droits très limités mais la possibilité de lancer un "sudo <commande de backup>".
J'ai du mal à suivre, là : s'il s'agit de faire un backup, n'est-il pas possible de créer un utilisateur avec des droits en lecture partout (sauf sur le fichier contenant effectivement les mots de passe), et des droits en écriture nulle part ?
Avec les droits Unix classique, c'est assez compliqué. -- printk("HPFS: Grrrr... Kernel memory corrupted ... going on, but it'll crash very soon :-(n"); 2.4.3 linux/fs/hpfs/super.c
Vincent Bernat
OoO En cette matinée pluvieuse du jeudi 14 avril 2005, vers 10:02, Cedric Blancher disait:
Si la machine n'a qu'un seul admin, le mot de passe utilisé pour se loguer et celui pour passer en root avec sudo est le même. Donc pas d'intérêt. Si la machine a plusieurs admins qui ont tous les droits, pas plus d'intérêt entre "su -" et "sudo -s", sinon que dans le second cas, on ne divulgue pas le pass root, mais on garde le même que celui du user, ce qui peut présenter un problème.
Cela permet tout de même de savoir qui fait quoi et de révoquer facilement les droits. Maintenant, cela s'entend dans un contexte où il y a une relative confiance, car bien entendu, rien n'empêche quelqu'un disposant d'un sudo d'aller falsifier les logs ou de s'installer une backdoor. -- I WON'T NOT USE NO DOUBLE NEGATIVES I WON'T NOT USE NO DOUBLE NEGATIVES I WON'T NOT USE NO DOUBLE NEGATIVES -+- Bart Simpson on chalkboard in episode BABF02
OoO En cette matinée pluvieuse du jeudi 14 avril 2005, vers 10:02,
Cedric Blancher <blancher@cartel-securite.fr> disait:
Si la machine n'a qu'un seul admin, le mot de passe utilisé pour se
loguer et celui pour passer en root avec sudo est le même. Donc pas
d'intérêt. Si la machine a plusieurs admins qui ont tous les droits, pas
plus d'intérêt entre "su -" et "sudo -s", sinon que dans le second cas,
on ne divulgue pas le pass root, mais on garde le même que celui du user,
ce qui peut présenter un problème.
Cela permet tout de même de savoir qui fait quoi et de révoquer
facilement les droits. Maintenant, cela s'entend dans un contexte où
il y a une relative confiance, car bien entendu, rien n'empêche
quelqu'un disposant d'un sudo d'aller falsifier les logs ou de
s'installer une backdoor.
--
I WON'T NOT USE NO DOUBLE NEGATIVES
I WON'T NOT USE NO DOUBLE NEGATIVES
I WON'T NOT USE NO DOUBLE NEGATIVES
-+- Bart Simpson on chalkboard in episode BABF02
OoO En cette matinée pluvieuse du jeudi 14 avril 2005, vers 10:02, Cedric Blancher disait:
Si la machine n'a qu'un seul admin, le mot de passe utilisé pour se loguer et celui pour passer en root avec sudo est le même. Donc pas d'intérêt. Si la machine a plusieurs admins qui ont tous les droits, pas plus d'intérêt entre "su -" et "sudo -s", sinon que dans le second cas, on ne divulgue pas le pass root, mais on garde le même que celui du user, ce qui peut présenter un problème.
Cela permet tout de même de savoir qui fait quoi et de révoquer facilement les droits. Maintenant, cela s'entend dans un contexte où il y a une relative confiance, car bien entendu, rien n'empêche quelqu'un disposant d'un sudo d'aller falsifier les logs ou de s'installer une backdoor. -- I WON'T NOT USE NO DOUBLE NEGATIVES I WON'T NOT USE NO DOUBLE NEGATIVES I WON'T NOT USE NO DOUBLE NEGATIVES -+- Bart Simpson on chalkboard in episode BABF02
Cedric Blancher
Le Thu, 14 Apr 2005 09:43:44 +0000, Vincent Bernat a écrit :
Cela permet tout de même de savoir qui fait quoi et de révoquer facilement les droits. Maintenant, cela s'entend dans un contexte où il y a une relative confiance, car bien entendu, rien n'empêche quelqu'un disposant d'un sudo d'aller falsifier les logs ou de s'installer une backdoor.
Les commandes "su -" et "sudo -s" génèrent toutes les deux des lignes de log :
"su -" : su[15909]: + tty1 toto:root su[15909]: (pam_unix) session opened for user root by toto(uid06)
Donc le résultat est le même à partir de là. La seule manière de tout tracer est d'interdire le lancement d'un shell par sudo, mais ça peut se détourner en renommant un binaire.
--
- Bientot==> Une rubrique membre avec photos - Bientot==> "Un chat on line" pour discuter Si j'amène la photo de mon membre, je pourai caresser le chat ?
-+- FF in Guide du Neuneu Usenet - Cha chanonchait bien pourtant -+-
Le Thu, 14 Apr 2005 09:43:44 +0000, Vincent Bernat a écrit :
Cela permet tout de même de savoir qui fait quoi et de révoquer
facilement les droits. Maintenant, cela s'entend dans un contexte où
il y a une relative confiance, car bien entendu, rien n'empêche
quelqu'un disposant d'un sudo d'aller falsifier les logs ou de
s'installer une backdoor.
Les commandes "su -" et "sudo -s" génèrent toutes les deux des lignes de
log :
"su -" :
su[15909]: + tty1 toto:root
su[15909]: (pam_unix) session opened for user root by toto(uid06)
Donc le résultat est le même à partir de là. La seule manière de tout
tracer est d'interdire le lancement d'un shell par sudo, mais ça peut se
détourner en renommant un binaire.
--
- Bientot==> Une rubrique membre avec photos
- Bientot==> "Un chat on line" pour discuter
Si j'amène la photo de mon membre, je pourai caresser le chat ?
-+- FF in Guide du Neuneu Usenet - Cha chanonchait bien pourtant -+-
Le Thu, 14 Apr 2005 09:43:44 +0000, Vincent Bernat a écrit :
Cela permet tout de même de savoir qui fait quoi et de révoquer facilement les droits. Maintenant, cela s'entend dans un contexte où il y a une relative confiance, car bien entendu, rien n'empêche quelqu'un disposant d'un sudo d'aller falsifier les logs ou de s'installer une backdoor.
Les commandes "su -" et "sudo -s" génèrent toutes les deux des lignes de log :
"su -" : su[15909]: + tty1 toto:root su[15909]: (pam_unix) session opened for user root by toto(uid06)
Donc le résultat est le même à partir de là. La seule manière de tout tracer est d'interdire le lancement d'un shell par sudo, mais ça peut se détourner en renommant un binaire.
--
- Bientot==> Une rubrique membre avec photos - Bientot==> "Un chat on line" pour discuter Si j'amène la photo de mon membre, je pourai caresser le chat ?
-+- FF in Guide du Neuneu Usenet - Cha chanonchait bien pourtant -+-
Kevin Denis
Le 13-04-2005, Laurent Blume a écrit :
Personellement, c'est ainsi que je le comprends. Et on peut voir que ca a un sens: # grep "User root not allowed" /var/log/auth.log | wc -l 531 Plus de 500 tentatives en moins d'une semaine...
Si on part par là, il n'y a pas que root qui soit brute-forcé régulièrement.
Voici un extrait de mes logs récents (sur une semaine). Plus de 500 logins *différents*! Reconnaissez-vous le vôtre?
Tiens, partant de la, est-ce possible de loguer les pass essayes?
(en laissant de cote les pb de securite eventuels de cette methode). -- Kevin
Le 13-04-2005, Laurent Blume <laurent_news200504@elanor.org> a écrit :
Personellement, c'est ainsi que je le comprends.
Et on peut voir que ca a un sens:
# grep "User root not allowed" /var/log/auth.log | wc -l
531
Plus de 500 tentatives en moins d'une semaine...
Si on part par là, il n'y a pas que root qui soit brute-forcé régulièrement.
Voici un extrait de mes logs récents (sur une semaine). Plus de 500 logins
*différents*! Reconnaissez-vous le vôtre?
Tiens, partant de la, est-ce possible de loguer les pass essayes?
(en laissant de cote les pb de securite eventuels de cette methode).
--
Kevin
Personellement, c'est ainsi que je le comprends. Et on peut voir que ca a un sens: # grep "User root not allowed" /var/log/auth.log | wc -l 531 Plus de 500 tentatives en moins d'une semaine...
Si on part par là, il n'y a pas que root qui soit brute-forcé régulièrement.
Voici un extrait de mes logs récents (sur une semaine). Plus de 500 logins *différents*! Reconnaissez-vous le vôtre?
Tiens, partant de la, est-ce possible de loguer les pass essayes?
(en laissant de cote les pb de securite eventuels de cette methode). -- Kevin
Nicob
On Thu, 14 Apr 2005 11:32:41 +0000, Kevin Denis wrote:
Tiens, partant de la, est-ce possible de loguer les pass essayes? (en laissant de cote les pb de securite eventuels de cette methode).
Oui, en patchant le démon SSH. Ca doit pas être difficile, en plus ...
Nicob
On Thu, 14 Apr 2005 11:32:41 +0000, Kevin Denis wrote:
Tiens, partant de la, est-ce possible de loguer les pass essayes? (en
laissant de cote les pb de securite eventuels de cette methode).
Oui, en patchant le démon SSH.
Ca doit pas être difficile, en plus ...
Donc le résultat est le même à partir de là. La seule manière de tout tracer est d'interdire le lancement d'un shell par sudo, mais ça peut se détourner en renommant un binaire.
Bonjour,
Dans le cas de SSH il m'a semblé qu'on pouvait inclure dans la clef publique sur le serveur les commandes utilisables à partir de cette clef. Donc une petite clef SSH avec seulement la commande 'su' activée dans la clef, ça devrait être un bon début, non ?
Samuel.
Les commandes "su -" et "sudo -s" génèrent toutes les deux des lignes de
log :
"su -" :
su[15909]: + tty1 toto:root
su[15909]: (pam_unix) session opened for user root by toto(uid06)
Donc le résultat est le même à partir de là. La seule manière de tout
tracer est d'interdire le lancement d'un shell par sudo, mais ça peut se
détourner en renommant un binaire.
Bonjour,
Dans le cas de SSH il m'a semblé qu'on pouvait inclure dans la clef
publique sur le serveur les commandes utilisables à partir de cette clef.
Donc une petite clef SSH avec seulement la commande 'su' activée dans la
clef, ça devrait être un bon début, non ?
Donc le résultat est le même à partir de là. La seule manière de tout tracer est d'interdire le lancement d'un shell par sudo, mais ça peut se détourner en renommant un binaire.
Bonjour,
Dans le cas de SSH il m'a semblé qu'on pouvait inclure dans la clef publique sur le serveur les commandes utilisables à partir de cette clef. Donc une petite clef SSH avec seulement la commande 'su' activée dans la clef, ça devrait être un bon début, non ?
Samuel.
VANHULLEBUS Yvan
(Xavier) writes:
VANHULLEBUS Yvan wrote:
D'abord parceque sur un systeme ters propre et tres bien configure, tu ne feras pas "su", mais "sudo commande".
Ah oui ?
Et sudo commande 2>/tmp.file | while read VAR; do .... tu sais le faire ?
Si le sudo est là uniquement pour demander un mot de passe supplémentaire (une seule fois) puis casser les cou***es de l'admin, c'est pas mieux.
J'ai dit "sur un systeme tres propre et tres bien configure" :-)
Et en plus, il me semble que c'est un debat qui a deja eu lieu ici, le coup du "su Vs sudo", non ?
A +
VANHU.
xavier@groumpf.org (Xavier) writes:
VANHULLEBUS Yvan <vanhu@nospam_free.fr> wrote:
D'abord parceque sur un systeme ters propre et tres bien configure, tu
ne feras pas "su", mais "sudo commande".
Ah oui ?
Et sudo commande 2>/tmp.file | while read VAR; do .... tu sais le
faire ?
Si le sudo est là uniquement pour demander un mot de passe
supplémentaire (une seule fois) puis casser les cou***es de l'admin,
c'est pas mieux.
J'ai dit "sur un systeme tres propre et tres bien configure" :-)
Et en plus, il me semble que c'est un debat qui a deja eu lieu ici, le
coup du "su Vs sudo", non ?
