Protection contre attaque Port scan sur serveur privée Linux Amen
48 réponses
llnis
Bonjour à tous,
J'ai un serveur privée Linux chez Amen.
Amen à été contraint de suspendre brutalement mon serveur.
Ils l'annoncent compromis et à l'origine d'attaques Port scan.
Les conséquences sont énormes, car la suspension entraîne, après récupération des données théoriquement infectées, ( après isolement, le serveur à été mis en mode recovery) la réinitialisation complète du serveur, et la perte totale des configurations initiales de tous les sites hébergés (www, bdd, qmail).
De plus, même si les BDD et les Domaines sont récupérables (là encore en théorie), les comptes de messagerie, sont inexorablement perdus, et devront être reconfigurés 1 par 1 à la main. L'information à l'attention de chaque usager s'avère alors difficile à réaliser, en l'absence le plus souvent d'alias email, dans la mesure aussi, ou le MP aura fatalement été réinitialisé.
Amen argue que je suis censé organiser et protéger moi-même mon serveur de ce type d'attaques et de recherches d'intrusion, raison pour laquelle la suspension totale du serveur à été appliqué.
Aussi, auriez-vous réponses à ces questions :
Que pourrai-je installer comme application compatible, sur un serveur privée Linux d'Amen, apte à protéger celui-ci, et à me signaler en temps réel, toute intrusion potentiellle en cours ?
Comment gérer l'ouverture ou la fermeture des ports, le serveur privée d'Amen étant, dans la réalité, un serveur virtuel ?
Le Tue, 10 Apr 2012 13:09:53 -0500, llnis a écrit:
Aussi, auriez-vous réponses à ces questions : Que pourrai-je installer comme application compatible, sur un serveur privée Linux d'Amen, apte à protéger celui-ci, et à me signaler en temps réel, toute intrusion potentiellle en cours ?
Un accès ssh qui refuse les connexions par mot de passe et accepte uniquement une clef privée, de préférence limité à certaines IP. Ensuite, installer le minimum absolu de services et d'applications; surtout ne pas installer de distro non adaptée genre ubuntu ou fedora mais rester sur une distro légère, qu'on peut tailler selon les besoins, par exemple Debian.
-- An expert is a man who has made all the mistakes that can be made in a very narrow field. Niels Bohr
Le Tue, 10 Apr 2012 13:09:53 -0500, llnis a écrit:
Aussi, auriez-vous réponses à ces questions : Que pourrai-je installer
comme application compatible, sur un serveur privée Linux d'Amen, apte à
protéger celui-ci, et à me signaler en temps réel, toute intrusion
potentiellle en cours ?
Un accès ssh qui refuse les connexions par mot de passe et accepte
uniquement une clef privée, de préférence limité à certaines IP. Ensuite,
installer le minimum absolu de services et d'applications; surtout ne pas
installer de distro non adaptée genre ubuntu ou fedora mais rester sur
une distro légère, qu'on peut tailler selon les besoins, par exemple
Debian.
--
An expert is a man who has made all the mistakes that can be made in a
very narrow field.
Niels Bohr
Le Tue, 10 Apr 2012 13:09:53 -0500, llnis a écrit:
Aussi, auriez-vous réponses à ces questions : Que pourrai-je installer comme application compatible, sur un serveur privée Linux d'Amen, apte à protéger celui-ci, et à me signaler en temps réel, toute intrusion potentiellle en cours ?
Un accès ssh qui refuse les connexions par mot de passe et accepte uniquement une clef privée, de préférence limité à certaines IP. Ensuite, installer le minimum absolu de services et d'applications; surtout ne pas installer de distro non adaptée genre ubuntu ou fedora mais rester sur une distro légère, qu'on peut tailler selon les besoins, par exemple Debian.
-- An expert is a man who has made all the mistakes that can be made in a very narrow field. Niels Bohr
Francois Lafont
Bonsoir,
Le 10/04/2012 23:03, Emmanuel Florac a écrit :
Un accès ssh qui refuse les connexions par mot de passe
Juste pour ma « culture générale » (et ma curiosité), est-ce qu'il y a un souci potentiel avec une connexion ssh via un mot de passe (avec un bon mot de passe suffisamment complexe) ?
-- François Lafont
Bonsoir,
Le 10/04/2012 23:03, Emmanuel Florac a écrit :
Un accès ssh qui refuse les connexions par mot de passe
Juste pour ma « culture générale » (et ma curiosité), est-ce qu'il y a
un souci potentiel avec une connexion ssh via un mot de passe (avec un
bon mot de passe suffisamment complexe) ?
Un accès ssh qui refuse les connexions par mot de passe
Juste pour ma « culture générale » (et ma curiosité), est-ce qu'il y a un souci potentiel avec une connexion ssh via un mot de passe (avec un bon mot de passe suffisamment complexe) ?
-- François Lafont
denis.paris
Le 10/04/2012 23:03, Emmanuel Florac a écrit :
Le Tue, 10 Apr 2012 13:09:53 -0500, llnis a écrit:
Aussi, auriez-vous réponses à ces questions : Que pourrai-je installer comme application compatible, sur un serveur privée Linux d'Amen, apte à protéger celui-ci, et à me signaler en temps réel, toute intrusion potentiellle en cours ?
Un accès ssh qui refuse les connexions par mot de passe et accepte uniquement une clef privée, de préférence limité à certaines IP. Ensuite, installer le minimum absolu de services et d'applications; surtout ne pas installer de distro non adaptée genre ubuntu ou fedora mais rester sur une distro légère, qu'on peut tailler selon les besoins, par exemple Debian.
En même temps si c'est un serveur WEB c'est difficile de limiter l'accès en ssh uniquement...
Tout dépend de l'usage de la machine, chaque application serveur est potentiellement dangereuse, les bonnes pratiques pour chacune font l'objet de beaucoup de littérature, il n'est pas possible de répondre en quelques mots. et il faut bien sûr maintenir le serveur le plus à jour possible.
Le 10/04/2012 23:03, Emmanuel Florac a écrit :
Le Tue, 10 Apr 2012 13:09:53 -0500, llnis a écrit:
Aussi, auriez-vous réponses à ces questions : Que pourrai-je installer
comme application compatible, sur un serveur privée Linux d'Amen, apte à
protéger celui-ci, et à me signaler en temps réel, toute intrusion
potentiellle en cours ?
Un accès ssh qui refuse les connexions par mot de passe et accepte
uniquement une clef privée, de préférence limité à certaines IP. Ensuite,
installer le minimum absolu de services et d'applications; surtout ne pas
installer de distro non adaptée genre ubuntu ou fedora mais rester sur
une distro légère, qu'on peut tailler selon les besoins, par exemple
Debian.
En même temps si c'est un serveur WEB c'est difficile de limiter l'accès
en ssh uniquement...
Tout dépend de l'usage de la machine, chaque application serveur est
potentiellement dangereuse, les bonnes pratiques pour chacune font
l'objet de beaucoup de littérature, il n'est pas possible de répondre en
quelques mots. et il faut bien sûr maintenir le serveur le plus à jour
possible.
Le Tue, 10 Apr 2012 13:09:53 -0500, llnis a écrit:
Aussi, auriez-vous réponses à ces questions : Que pourrai-je installer comme application compatible, sur un serveur privée Linux d'Amen, apte à protéger celui-ci, et à me signaler en temps réel, toute intrusion potentiellle en cours ?
Un accès ssh qui refuse les connexions par mot de passe et accepte uniquement une clef privée, de préférence limité à certaines IP. Ensuite, installer le minimum absolu de services et d'applications; surtout ne pas installer de distro non adaptée genre ubuntu ou fedora mais rester sur une distro légère, qu'on peut tailler selon les besoins, par exemple Debian.
En même temps si c'est un serveur WEB c'est difficile de limiter l'accès en ssh uniquement...
Tout dépend de l'usage de la machine, chaque application serveur est potentiellement dangereuse, les bonnes pratiques pour chacune font l'objet de beaucoup de littérature, il n'est pas possible de répondre en quelques mots. et il faut bien sûr maintenir le serveur le plus à jour possible.
denis.paris
Le 10/04/2012 23:11, Francois Lafont a écrit :
Bonsoir,
Le 10/04/2012 23:03, Emmanuel Florac a écrit :
Un accès ssh qui refuse les connexions par mot de passe
Juste pour ma « culture générale » (et ma curiosité), est-ce qu'il y a un souci potentiel avec une connexion ssh via un mot de passe (avec un bon mot de passe suffisamment complexe) ?
Il faut surtout interdire l'accès direct en root, et maintenir le package openssh le plus à jour possible.
Le 10/04/2012 23:11, Francois Lafont a écrit :
Bonsoir,
Le 10/04/2012 23:03, Emmanuel Florac a écrit :
Un accès ssh qui refuse les connexions par mot de passe
Juste pour ma « culture générale » (et ma curiosité), est-ce qu'il y a
un souci potentiel avec une connexion ssh via un mot de passe (avec un
bon mot de passe suffisamment complexe) ?
Il faut surtout interdire l'accès direct en root, et maintenir le
package openssh le plus à jour possible.
Un accès ssh qui refuse les connexions par mot de passe
Juste pour ma « culture générale » (et ma curiosité), est-ce qu'il y a un souci potentiel avec une connexion ssh via un mot de passe (avec un bon mot de passe suffisamment complexe) ?
Il faut surtout interdire l'accès direct en root, et maintenir le package openssh le plus à jour possible.
Luc.Habert.00__arjf
"denis.paris" :
Il faut surtout interdire l'accès direct en root
Bof. C'est une ligne de défense supplémentaire, mais elle ne vaut pas grand chose.
"denis.paris" :
Il faut surtout interdire l'accès direct en root
Bof. C'est une ligne de défense supplémentaire, mais elle ne vaut pas grand
chose.
Bof. C'est une ligne de défense supplémentaire, mais elle ne vaut pas grand chose.
Francois Lafont
Le 10/04/2012 23:21, denis.paris a écrit :
Un accès ssh qui refuse les connexions par mot de passe
Juste pour ma « culture générale » (et ma curiosité), est-ce qu'il y a un souci potentiel avec une connexion ssh via un mot de passe (avec un bon mot de passe suffisamment complexe) ?
Il faut surtout interdire l'accès direct en root,
Parce que le mot de passe est potentiellement récupérable donc ?
Je soulève cette question car simplement, pour le petit geek du dimanche que je suis et qui voit tout ça de loin, le ssh a la réputation d'être un protocole très sécurisé.
-- François Lafont
Le 10/04/2012 23:21, denis.paris a écrit :
Un accès ssh qui refuse les connexions par mot de passe
Juste pour ma « culture générale » (et ma curiosité), est-ce qu'il y a
un souci potentiel avec une connexion ssh via un mot de passe (avec un
bon mot de passe suffisamment complexe) ?
Il faut surtout interdire l'accès direct en root,
Parce que le mot de passe est potentiellement récupérable donc ?
Je soulève cette question car simplement, pour le petit geek du dimanche
que je suis et qui voit tout ça de loin, le ssh a la réputation d'être
un protocole très sécurisé.
Un accès ssh qui refuse les connexions par mot de passe
Juste pour ma « culture générale » (et ma curiosité), est-ce qu'il y a un souci potentiel avec une connexion ssh via un mot de passe (avec un bon mot de passe suffisamment complexe) ?
Il faut surtout interdire l'accès direct en root,
Parce que le mot de passe est potentiellement récupérable donc ?
Je soulève cette question car simplement, pour le petit geek du dimanche que je suis et qui voit tout ça de loin, le ssh a la réputation d'être un protocole très sécurisé.
-- François Lafont
Luc.Habert.00__arjf
Francois Lafont :
Il faut surtout interdire l'accès direct en root,
Parce que le mot de passe est potentiellement récupérable donc ?
Non. C'est juste un mème aléatoire qui se transmet depuis des lustres sans que les gens prennent la peine de se demander si ça apporte quelque chose.
Je ne lui vois que deux justifications, toutes les deux faibles : - si on essaye des mots de passe au hasard, il faut en même temps essayer des noms d'utilisateurs aléatoires - après avoir pris la main sur un compte de luser, il va falloir trouver un trou local pour passer root, mais vue la quantité de trous découverts en permanence, y compris dans le noyau, ça ne doit pas poser problème à grand monde.
le ssh a la réputation d'être un protocole très sécurisé.
Les failles sont en général ailleurs (genre mots de passe faibles, keyloggers, ...). Cela dit, de temps en temps, on trouve un gros trou dans les implémentations du protocole. Comme la fois où le mainteneur du package Debian a, en croyant bien faire, flingué l'aléas du générateur de clefs (d'où des clefs facilement cassables).
Francois Lafont :
Il faut surtout interdire l'accès direct en root,
Parce que le mot de passe est potentiellement récupérable donc ?
Non. C'est juste un mème aléatoire qui se transmet depuis des lustres sans
que les gens prennent la peine de se demander si ça apporte quelque chose.
Je ne lui vois que deux justifications, toutes les deux faibles :
- si on essaye des mots de passe au hasard, il faut en même temps essayer
des noms d'utilisateurs aléatoires
- après avoir pris la main sur un compte de luser, il va falloir trouver un
trou local pour passer root, mais vue la quantité de trous découverts en
permanence, y compris dans le noyau, ça ne doit pas poser problème à grand
monde.
le ssh a la réputation d'être un protocole très sécurisé.
Les failles sont en général ailleurs (genre mots de passe faibles,
keyloggers, ...). Cela dit, de temps en temps, on trouve un gros trou dans
les implémentations du protocole. Comme la fois où le mainteneur du package
Debian a, en croyant bien faire, flingué l'aléas du générateur de clefs
(d'où des clefs facilement cassables).
Parce que le mot de passe est potentiellement récupérable donc ?
Non. C'est juste un mème aléatoire qui se transmet depuis des lustres sans que les gens prennent la peine de se demander si ça apporte quelque chose.
Je ne lui vois que deux justifications, toutes les deux faibles : - si on essaye des mots de passe au hasard, il faut en même temps essayer des noms d'utilisateurs aléatoires - après avoir pris la main sur un compte de luser, il va falloir trouver un trou local pour passer root, mais vue la quantité de trous découverts en permanence, y compris dans le noyau, ça ne doit pas poser problème à grand monde.
le ssh a la réputation d'être un protocole très sécurisé.
Les failles sont en général ailleurs (genre mots de passe faibles, keyloggers, ...). Cela dit, de temps en temps, on trouve un gros trou dans les implémentations du protocole. Comme la fois où le mainteneur du package Debian a, en croyant bien faire, flingué l'aléas du générateur de clefs (d'où des clefs facilement cassables).
Francois Lafont
Le 10/04/2012 23:43, Luc Habert a écrit :
Francois Lafont :
Il faut surtout interdire l'accès direct en root,
Parce que le mot de passe est potentiellement récupérable donc ?
Non.
Ah, me voilà rassuré. :-)
C'est juste un mème aléatoire qui se transmet depuis des lustres sans que les gens prennent la peine de se demander si ça apporte quelque chose.
Je ne lui vois que deux justifications, toutes les deux faibles : - si on essaye des mots de passe au hasard, il faut en même temps essayer des noms d'utilisateurs aléatoires - après avoir pris la main sur un compte de luser, il va falloir trouver un trou local pour passer root, mais vue la quantité de trous découverts en permanence, y compris dans le noyau, ça ne doit pas poser problème à grand monde.
À mon niveau, ce sont des justifications qui ne me paraissent pas faibles mais j'imagine que pour un expert en pirateries c'est une autre histoires...
Perso, devenir root sur une machine distante où j'ai une connexion ssh en tant qu'utilisateur « lambda », je ne sais pas faire. Moi, il me faut un accès physique à la machine. :-)
le ssh a la réputation d'être un protocole très sécurisé.
Les failles sont en général ailleurs (genre mots de passe faibles, keyloggers, ...).
En supposant que le mot de passe soit fort, l'exemple du keyloggers que tu donnes signifie, j'imagine, que la faille se trouve alors potentiellement plutôt du côté de la machine cliente qui tente une connexion au serveur que du côté serveur. Mais dans ce cas, l'argument n'est-il pas valable également dans le cas de l'utilisation d'une clé privée comme le suggérait Emmanuel ? Peut-être est-il moins valable dans ce cas ?
Cela dit, de temps en temps, on trouve un gros trou dans les implémentations du protocole. Comme la fois où le mainteneur du package Debian a, en croyant bien faire, flingué l'aléas du générateur de clefs (d'où des clefs facilement cassables).
Ok, merci pour les explications.
-- François Lafont
Le 10/04/2012 23:43, Luc Habert a écrit :
Francois Lafont :
Il faut surtout interdire l'accès direct en root,
Parce que le mot de passe est potentiellement récupérable donc ?
Non.
Ah, me voilà rassuré. :-)
C'est juste un mème aléatoire qui se transmet depuis des lustres sans
que les gens prennent la peine de se demander si ça apporte quelque chose.
Je ne lui vois que deux justifications, toutes les deux faibles :
- si on essaye des mots de passe au hasard, il faut en même temps essayer
des noms d'utilisateurs aléatoires
- après avoir pris la main sur un compte de luser, il va falloir trouver un
trou local pour passer root, mais vue la quantité de trous découverts en
permanence, y compris dans le noyau, ça ne doit pas poser problème à grand
monde.
À mon niveau, ce sont des justifications qui ne me paraissent pas
faibles mais j'imagine que pour un expert en pirateries c'est une autre
histoires...
Perso, devenir root sur une machine distante où j'ai une connexion ssh
en tant qu'utilisateur « lambda », je ne sais pas faire. Moi, il me faut
un accès physique à la machine. :-)
le ssh a la réputation d'être un protocole très sécurisé.
Les failles sont en général ailleurs (genre mots de passe faibles,
keyloggers, ...).
En supposant que le mot de passe soit fort, l'exemple du keyloggers que
tu donnes signifie, j'imagine, que la faille se trouve alors
potentiellement plutôt du côté de la machine cliente qui tente une
connexion au serveur que du côté serveur. Mais dans ce cas, l'argument
n'est-il pas valable également dans le cas de l'utilisation d'une clé
privée comme le suggérait Emmanuel ? Peut-être est-il moins valable dans
ce cas ?
Cela dit, de temps en temps, on trouve un gros trou dans
les implémentations du protocole. Comme la fois où le mainteneur du package
Debian a, en croyant bien faire, flingué l'aléas du générateur de clefs
(d'où des clefs facilement cassables).
Parce que le mot de passe est potentiellement récupérable donc ?
Non.
Ah, me voilà rassuré. :-)
C'est juste un mème aléatoire qui se transmet depuis des lustres sans que les gens prennent la peine de se demander si ça apporte quelque chose.
Je ne lui vois que deux justifications, toutes les deux faibles : - si on essaye des mots de passe au hasard, il faut en même temps essayer des noms d'utilisateurs aléatoires - après avoir pris la main sur un compte de luser, il va falloir trouver un trou local pour passer root, mais vue la quantité de trous découverts en permanence, y compris dans le noyau, ça ne doit pas poser problème à grand monde.
À mon niveau, ce sont des justifications qui ne me paraissent pas faibles mais j'imagine que pour un expert en pirateries c'est une autre histoires...
Perso, devenir root sur une machine distante où j'ai une connexion ssh en tant qu'utilisateur « lambda », je ne sais pas faire. Moi, il me faut un accès physique à la machine. :-)
le ssh a la réputation d'être un protocole très sécurisé.
Les failles sont en général ailleurs (genre mots de passe faibles, keyloggers, ...).
En supposant que le mot de passe soit fort, l'exemple du keyloggers que tu donnes signifie, j'imagine, que la faille se trouve alors potentiellement plutôt du côté de la machine cliente qui tente une connexion au serveur que du côté serveur. Mais dans ce cas, l'argument n'est-il pas valable également dans le cas de l'utilisation d'une clé privée comme le suggérait Emmanuel ? Peut-être est-il moins valable dans ce cas ?
Cela dit, de temps en temps, on trouve un gros trou dans les implémentations du protocole. Comme la fois où le mainteneur du package Debian a, en croyant bien faire, flingué l'aléas du générateur de clefs (d'où des clefs facilement cassables).
Ok, merci pour les explications.
-- François Lafont
Luc.Habert.00__arjf
Francois Lafont :
Perso, devenir root sur une machine distante où j'ai une connexion ssh en tant qu'utilisateur « lambda », je ne sais pas faire.
google linux exploit, tu en essaye quelques uns, et si la machine n'est pas parfaitement à jour, il y en aura bien un pour marcher.
Exercice : fais-le sur ton système.
En supposant que le mot de passe soit fort, l'exemple du keyloggers que tu donnes signifie, j'imagine, que la faille se trouve alors potentiellement plutôt du côté de la machine cliente qui tente une connexion au serveur que du côté serveur. Mais dans ce cas, l'argument n'est-il pas valable également dans le cas de l'utilisation d'une clé privée comme le suggérait Emmanuel ? Peut-être est-il moins valable dans ce cas ?
Pour la clef, ce n'est pas un keyloger qu'il faudrait, mais un truc qui cherche les fichiers de clefs dans la config de putty. Si tu mets une passphrase sur la clef, il faut le combiner à un keylogger. Ça devient vachement spécifique comme attaque, donc à moins d'avoir la CIA sur le dos, ça me fait moins peur que de taper directement un mot de passe. Mais je conviens fort bien que c'est faible comme argument.
Francois Lafont :
Perso, devenir root sur une machine distante où j'ai une connexion ssh
en tant qu'utilisateur « lambda », je ne sais pas faire.
google linux exploit, tu en essaye quelques uns, et si la machine n'est pas
parfaitement à jour, il y en aura bien un pour marcher.
Exercice : fais-le sur ton système.
En supposant que le mot de passe soit fort, l'exemple du keyloggers que
tu donnes signifie, j'imagine, que la faille se trouve alors
potentiellement plutôt du côté de la machine cliente qui tente une
connexion au serveur que du côté serveur. Mais dans ce cas, l'argument
n'est-il pas valable également dans le cas de l'utilisation d'une clé
privée comme le suggérait Emmanuel ? Peut-être est-il moins valable dans
ce cas ?
Pour la clef, ce n'est pas un keyloger qu'il faudrait, mais un truc qui
cherche les fichiers de clefs dans la config de putty. Si tu mets une
passphrase sur la clef, il faut le combiner à un keylogger. Ça devient
vachement spécifique comme attaque, donc à moins d'avoir la CIA sur le dos,
ça me fait moins peur que de taper directement un mot de passe. Mais je
conviens fort bien que c'est faible comme argument.
Perso, devenir root sur une machine distante où j'ai une connexion ssh en tant qu'utilisateur « lambda », je ne sais pas faire.
google linux exploit, tu en essaye quelques uns, et si la machine n'est pas parfaitement à jour, il y en aura bien un pour marcher.
Exercice : fais-le sur ton système.
En supposant que le mot de passe soit fort, l'exemple du keyloggers que tu donnes signifie, j'imagine, que la faille se trouve alors potentiellement plutôt du côté de la machine cliente qui tente une connexion au serveur que du côté serveur. Mais dans ce cas, l'argument n'est-il pas valable également dans le cas de l'utilisation d'une clé privée comme le suggérait Emmanuel ? Peut-être est-il moins valable dans ce cas ?
Pour la clef, ce n'est pas un keyloger qu'il faudrait, mais un truc qui cherche les fichiers de clefs dans la config de putty. Si tu mets une passphrase sur la clef, il faut le combiner à un keylogger. Ça devient vachement spécifique comme attaque, donc à moins d'avoir la CIA sur le dos, ça me fait moins peur que de taper directement un mot de passe. Mais je conviens fort bien que c'est faible comme argument.
Francois Lafont
Le 11/04/2012 00:22, Luc Habert a écrit :
Perso, devenir root sur une machine distante où j'ai une connexion ssh en tant qu'utilisateur « lambda », je ne sais pas faire.
google linux exploit, tu en essaye quelques uns, et si la machine n'est pas parfaitement à jour, il y en aura bien un pour marcher.
Exercice : fais-le sur ton système.
Ok. :-) Je ne connaissais pas ce terme « exploit ».
En supposant que le mot de passe soit fort, l'exemple du keyloggers que tu donnes signifie, j'imagine, que la faille se trouve alors potentiellement plutôt du côté de la machine cliente qui tente une connexion au serveur que du côté serveur. Mais dans ce cas, l'argument n'est-il pas valable également dans le cas de l'utilisation d'une clé privée comme le suggérait Emmanuel ? Peut-être est-il moins valable dans ce cas ?
Pour la clef, ce n'est pas un keyloger qu'il faudrait, mais un truc qui cherche les fichiers de clefs dans la config de putty. Si tu mets une passphrase sur la clef, il faut le combiner à un keylogger. Ça devient vachement spécifique comme attaque, donc à moins d'avoir la CIA sur le dos, ça me fait moins peur que de taper directement un mot de passe. Mais je conviens fort bien que c'est faible comme argument.
Non, non, ça me va. :-)
Merci. À+
-- François Lafont
Le 11/04/2012 00:22, Luc Habert a écrit :
Perso, devenir root sur une machine distante où j'ai une connexion ssh
en tant qu'utilisateur « lambda », je ne sais pas faire.
google linux exploit, tu en essaye quelques uns, et si la machine n'est pas
parfaitement à jour, il y en aura bien un pour marcher.
Exercice : fais-le sur ton système.
Ok. :-)
Je ne connaissais pas ce terme « exploit ».
En supposant que le mot de passe soit fort, l'exemple du keyloggers que
tu donnes signifie, j'imagine, que la faille se trouve alors
potentiellement plutôt du côté de la machine cliente qui tente une
connexion au serveur que du côté serveur. Mais dans ce cas, l'argument
n'est-il pas valable également dans le cas de l'utilisation d'une clé
privée comme le suggérait Emmanuel ? Peut-être est-il moins valable dans
ce cas ?
Pour la clef, ce n'est pas un keyloger qu'il faudrait, mais un truc qui
cherche les fichiers de clefs dans la config de putty. Si tu mets une
passphrase sur la clef, il faut le combiner à un keylogger. Ça devient
vachement spécifique comme attaque, donc à moins d'avoir la CIA sur le dos,
ça me fait moins peur que de taper directement un mot de passe. Mais je
conviens fort bien que c'est faible comme argument.
Perso, devenir root sur une machine distante où j'ai une connexion ssh en tant qu'utilisateur « lambda », je ne sais pas faire.
google linux exploit, tu en essaye quelques uns, et si la machine n'est pas parfaitement à jour, il y en aura bien un pour marcher.
Exercice : fais-le sur ton système.
Ok. :-) Je ne connaissais pas ce terme « exploit ».
En supposant que le mot de passe soit fort, l'exemple du keyloggers que tu donnes signifie, j'imagine, que la faille se trouve alors potentiellement plutôt du côté de la machine cliente qui tente une connexion au serveur que du côté serveur. Mais dans ce cas, l'argument n'est-il pas valable également dans le cas de l'utilisation d'une clé privée comme le suggérait Emmanuel ? Peut-être est-il moins valable dans ce cas ?
Pour la clef, ce n'est pas un keyloger qu'il faudrait, mais un truc qui cherche les fichiers de clefs dans la config de putty. Si tu mets une passphrase sur la clef, il faut le combiner à un keylogger. Ça devient vachement spécifique comme attaque, donc à moins d'avoir la CIA sur le dos, ça me fait moins peur que de taper directement un mot de passe. Mais je conviens fort bien que c'est faible comme argument.
