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 ?
Il faut surtout interdire l'accès direct en root, et maintenir le package openssh le plus à jour possible.
De quand date la dernière faille sur ssh? Vraie question. -- Kevin
Kevin Denis
Le 11-04-2012, HAAAAAA, c'est la fin du monde on va tous MOURIR. a écrit :
Pour le moment j'ai pas testé ssh et je me pose justement des questions. - Que pensez vous de portknocker ?
Qu'on peut le faire avec iptables et le module ipt_recent. http://www.debian-administration.org/articles/268
- Peut on changer le mot de passe (ou le code du portknocker) régulièrement via un SMS/mail sur un portable après chaque déconnexion ?
Si tu veux, mais ça peut vite poser d'autres problèmes. Si la sécurité est trop compliquée, tu vas la bypasser.
Pour ssh, je conseille des petits trucs: -un changement de port d'écoute -toujours vérifier la clé du serveur! -Bannir l'usage des mots de passe pour se logger -Utiliser des clés de longueur suffisante -Des clés protégées!
Généralement, tu peux dormir tranquille après. -- Kevin
Le 11-04-2012, HAAAAAA, c'est la fin du monde on va tous MOURIR. a écrit :
Pour le moment j'ai pas testé ssh et je me pose justement des questions.
- Que pensez vous de portknocker ?
Qu'on peut le faire avec iptables et le module ipt_recent.
http://www.debian-administration.org/articles/268
- Peut on changer le mot de passe (ou le code du portknocker)
régulièrement via un SMS/mail sur un portable après chaque déconnexion ?
Si tu veux, mais ça peut vite poser d'autres problèmes.
Si la sécurité est trop compliquée, tu vas la bypasser.
Pour ssh, je conseille des petits trucs:
-un changement de port d'écoute
-toujours vérifier la clé du serveur!
-Bannir l'usage des mots de passe pour se logger
-Utiliser des clés de longueur suffisante
-Des clés protégées!
Généralement, tu peux dormir tranquille après.
--
Kevin
Le 11-04-2012, HAAAAAA, c'est la fin du monde on va tous MOURIR. a écrit :
Pour le moment j'ai pas testé ssh et je me pose justement des questions. - Que pensez vous de portknocker ?
Qu'on peut le faire avec iptables et le module ipt_recent. http://www.debian-administration.org/articles/268
- Peut on changer le mot de passe (ou le code du portknocker) régulièrement via un SMS/mail sur un portable après chaque déconnexion ?
Si tu veux, mais ça peut vite poser d'autres problèmes. Si la sécurité est trop compliquée, tu vas la bypasser.
Pour ssh, je conseille des petits trucs: -un changement de port d'écoute -toujours vérifier la clé du serveur! -Bannir l'usage des mots de passe pour se logger -Utiliser des clés de longueur suffisante -Des clés protégées!
Généralement, tu peux dormir tranquille après. -- Kevin
Kevin Denis
Le 10-04-2012, Luc Habert a écrit :
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.
Si. Le mot de passe est parfaitement récupérable. Lors d'une connexion ssh, tu ouvres un canal chiffré. Dans ce canal chiffré, tu envoies _en clair_ ton login et ton mot de passe.
Ce qui signifie que si tu te connectes à un mauvais serveur, ce serveur peut tout à fait récupérer ton login et ton mot de passe. (il faut bien que le serveur le valide, après tout)
C'est pour cette raison qu'il est essentiel de vérifier la clé du serveur. C'est aussi pour cette raison que lors du changement de clé on a un message d'info long comme le bras "et qui fait peur".
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).
ssh est solide, et ssh n'a pas été modifié par la suite. C'est exactement comme si debian ne proposait un ssh qu'avec trois mots de passe différents. La faille n'a rien à voir avec ssh, et c'est debian qui a du corriger, pas ssh. -- Kevin
Le 10-04-2012, Luc Habert <Luc.Habert.00__arjf@normalesup.org> a écrit :
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.
Si. Le mot de passe est parfaitement récupérable.
Lors d'une connexion ssh, tu ouvres un canal chiffré. Dans ce canal
chiffré, tu envoies _en clair_ ton login et ton mot de passe.
Ce qui signifie que si tu te connectes à un mauvais serveur, ce serveur
peut tout à fait récupérer ton login et ton mot de passe. (il faut bien
que le serveur le valide, après tout)
C'est pour cette raison qu'il est essentiel de vérifier la clé du
serveur. C'est aussi pour cette raison que lors du changement de clé
on a un message d'info long comme le bras "et qui fait peur".
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).
ssh est solide, et ssh n'a pas été modifié par la suite. C'est exactement
comme si debian ne proposait un ssh qu'avec trois mots de passe différents.
La faille n'a rien à voir avec ssh, et c'est debian qui a du corriger,
pas ssh.
--
Kevin
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.
Si. Le mot de passe est parfaitement récupérable. Lors d'une connexion ssh, tu ouvres un canal chiffré. Dans ce canal chiffré, tu envoies _en clair_ ton login et ton mot de passe.
Ce qui signifie que si tu te connectes à un mauvais serveur, ce serveur peut tout à fait récupérer ton login et ton mot de passe. (il faut bien que le serveur le valide, après tout)
C'est pour cette raison qu'il est essentiel de vérifier la clé du serveur. C'est aussi pour cette raison que lors du changement de clé on a un message d'info long comme le bras "et qui fait peur".
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).
ssh est solide, et ssh n'a pas été modifié par la suite. C'est exactement comme si debian ne proposait un ssh qu'avec trois mots de passe différents. La faille n'a rien à voir avec ssh, et c'est debian qui a du corriger, pas ssh. -- Kevin
Pascal Hambourg
Salut,
Kevin Denis a écrit :
Lors d'une connexion ssh, tu ouvres un canal chiffré. Dans ce canal chiffré, tu envoies _en clair_ ton login et ton mot de passe.
Ce qui signifie que si tu te connectes à un mauvais serveur, ce serveur peut tout à fait récupérer ton login et ton mot de passe. (il faut bien que le serveur le valide, après tout)
La vérification du mot de passe ne nécessite pas forcément sa tranmission en clair. Il peut être transmis après hachage à sens unique, comme par exemple dans l'authentification CHAP de PPP. Je suis un peu surpris que ce ne soit pas le cas avec SSH.
Salut,
Kevin Denis a écrit :
Lors d'une connexion ssh, tu ouvres un canal chiffré. Dans ce canal
chiffré, tu envoies _en clair_ ton login et ton mot de passe.
Ce qui signifie que si tu te connectes à un mauvais serveur, ce serveur
peut tout à fait récupérer ton login et ton mot de passe. (il faut bien
que le serveur le valide, après tout)
La vérification du mot de passe ne nécessite pas forcément sa
tranmission en clair. Il peut être transmis après hachage à sens unique,
comme par exemple dans l'authentification CHAP de PPP. Je suis un peu
surpris que ce ne soit pas le cas avec SSH.
Lors d'une connexion ssh, tu ouvres un canal chiffré. Dans ce canal chiffré, tu envoies _en clair_ ton login et ton mot de passe.
Ce qui signifie que si tu te connectes à un mauvais serveur, ce serveur peut tout à fait récupérer ton login et ton mot de passe. (il faut bien que le serveur le valide, après tout)
La vérification du mot de passe ne nécessite pas forcément sa tranmission en clair. Il peut être transmis après hachage à sens unique, comme par exemple dans l'authentification CHAP de PPP. Je suis un peu surpris que ce ne soit pas le cas avec SSH.
Le Sat, 14 Apr 2012 14:25:19 +0200 Pascal Hambourg a écrit :
Salut,
Kevin Denis a écrit : > Lors d'une connexion ssh, tu ouvres un canal chiffré. Dans ce canal > chiffré, tu envoies _en clair_ ton login et ton mot de passe. > > Ce qui signifie que si tu te connectes à un mauvais serveur, ce > serveur peut tout à fait récupérer ton login et ton mot de passe. > (il faut bien que le serveur le valide, après tout)
La vérification du mot de passe ne nécessite pas forcément sa tranmission en clair. Il peut être transmis après hachage à sens unique, comme par exemple dans l'authentification CHAP de PPP. Je suis un peu surpris que ce ne soit pas le cas avec SSH.
Je ne vois pas trop à quoi ça sert : si ce qu'il faut envoyer c'est l'empreinte issue du hachage plutôt que le mot de passe lui-même, il n'y a plus besoin du mot de passe. Tu interceptes l'empreinte, tu envoies l'empreinte.
Juste plus difficile à taper dans une console, mais ça n'arrête qu'un attaquant pas très motivé.
Le Sat, 14 Apr 2012 14:25:19 +0200
Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> a écrit :
Salut,
Kevin Denis a écrit :
> Lors d'une connexion ssh, tu ouvres un canal chiffré. Dans ce canal
> chiffré, tu envoies _en clair_ ton login et ton mot de passe.
>
> Ce qui signifie que si tu te connectes à un mauvais serveur, ce
> serveur peut tout à fait récupérer ton login et ton mot de passe.
> (il faut bien que le serveur le valide, après tout)
La vérification du mot de passe ne nécessite pas forcément sa
tranmission en clair. Il peut être transmis après hachage à sens
unique, comme par exemple dans l'authentification CHAP de PPP. Je
suis un peu surpris que ce ne soit pas le cas avec SSH.
Je ne vois pas trop à quoi ça sert : si ce qu'il faut envoyer c'est
l'empreinte issue du hachage plutôt que le mot de passe lui-même, il n'y
a plus besoin du mot de passe. Tu interceptes l'empreinte, tu envoies
l'empreinte.
Juste plus difficile à taper dans une console, mais ça n'arrête qu'un
attaquant pas très motivé.
Le Sat, 14 Apr 2012 14:25:19 +0200 Pascal Hambourg a écrit :
Salut,
Kevin Denis a écrit : > Lors d'une connexion ssh, tu ouvres un canal chiffré. Dans ce canal > chiffré, tu envoies _en clair_ ton login et ton mot de passe. > > Ce qui signifie que si tu te connectes à un mauvais serveur, ce > serveur peut tout à fait récupérer ton login et ton mot de passe. > (il faut bien que le serveur le valide, après tout)
La vérification du mot de passe ne nécessite pas forcément sa tranmission en clair. Il peut être transmis après hachage à sens unique, comme par exemple dans l'authentification CHAP de PPP. Je suis un peu surpris que ce ne soit pas le cas avec SSH.
Je ne vois pas trop à quoi ça sert : si ce qu'il faut envoyer c'est l'empreinte issue du hachage plutôt que le mot de passe lui-même, il n'y a plus besoin du mot de passe. Tu interceptes l'empreinte, tu envoies l'empreinte.
Juste plus difficile à taper dans une console, mais ça n'arrête qu'un attaquant pas très motivé.
Kevin Denis
Le 14-04-2012, Pascal Hambourg a écrit :
Lors d'une connexion ssh, tu ouvres un canal chiffré. Dans ce canal chiffré, tu envoies _en clair_ ton login et ton mot de passe.
Ce qui signifie que si tu te connectes à un mauvais serveur, ce serveur peut tout à fait récupérer ton login et ton mot de passe. (il faut bien que le serveur le valide, après tout)
La vérification du mot de passe ne nécessite pas forcément sa tranmission en clair. Il peut être transmis après hachage à sens unique, comme par exemple dans l'authentification CHAP de PPP.
Ce qui n'aiderait malheureusement pas car il serait possible de passer le hash pour s'authentifier auprès du serveur.
Je suis un peu surpris que ce ne soit pas le cas avec SSH.
RFC 4252 paragraphe 8:
8. Password Authentication Method: "password" Note that the 'plaintext password' value is encoded in ISO-10646 UTF-8. Puis: Note that even though the cleartext password is transmitted in the packet, the entire packet is encrypted by the transport layer. -- Kevin
Le 14-04-2012, Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> a écrit :
Lors d'une connexion ssh, tu ouvres un canal chiffré. Dans ce canal
chiffré, tu envoies _en clair_ ton login et ton mot de passe.
Ce qui signifie que si tu te connectes à un mauvais serveur, ce serveur
peut tout à fait récupérer ton login et ton mot de passe. (il faut bien
que le serveur le valide, après tout)
La vérification du mot de passe ne nécessite pas forcément sa
tranmission en clair. Il peut être transmis après hachage à sens unique,
comme par exemple dans l'authentification CHAP de PPP.
Ce qui n'aiderait malheureusement pas car il serait possible de passer
le hash pour s'authentifier auprès du serveur.
Je suis un peu
surpris que ce ne soit pas le cas avec SSH.
RFC 4252 paragraphe 8:
8. Password Authentication Method: "password"
Note that the 'plaintext password' value is encoded in ISO-10646 UTF-8.
Puis:
Note that even though the cleartext password
is transmitted in the packet, the entire packet is encrypted by the
transport layer.
--
Kevin
Lors d'une connexion ssh, tu ouvres un canal chiffré. Dans ce canal chiffré, tu envoies _en clair_ ton login et ton mot de passe.
Ce qui signifie que si tu te connectes à un mauvais serveur, ce serveur peut tout à fait récupérer ton login et ton mot de passe. (il faut bien que le serveur le valide, après tout)
La vérification du mot de passe ne nécessite pas forcément sa tranmission en clair. Il peut être transmis après hachage à sens unique, comme par exemple dans l'authentification CHAP de PPP.
Ce qui n'aiderait malheureusement pas car il serait possible de passer le hash pour s'authentifier auprès du serveur.
Je suis un peu surpris que ce ne soit pas le cas avec SSH.
RFC 4252 paragraphe 8:
8. Password Authentication Method: "password" Note that the 'plaintext password' value is encoded in ISO-10646 UTF-8. Puis: Note that even though the cleartext password is transmitted in the packet, the entire packet is encrypted by the transport layer. -- Kevin
Nicolas George
Pascal Hambourg , dans le message <jmcpiq$2qb8$, a écrit :
Dans CHAP, c'est la combinaison du mot de passe avec une valeur aléatoire envoyée par le serveur qui est hachée, empêchant le rejeu.
Dans ce cas, c'est que le serveur lui-même stocke le mot de passe en clair. Si on veut se passer de crypto asymétrique, c'est l'un ou l'autre.
Pascal Hambourg , dans le message <jmcpiq$2qb8$1@saria.nerim.net>, a
écrit :
Dans CHAP, c'est la combinaison du mot de passe avec une valeur
aléatoire envoyée par le serveur qui est hachée, empêchant le rejeu.
Dans ce cas, c'est que le serveur lui-même stocke le mot de passe en clair.
Si on veut se passer de crypto asymétrique, c'est l'un ou l'autre.
