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 ?
Arnaud Gomes-do-Vale , dans le message , a écrit :
Ça empêche certes le rejeu, mais ça ne gêne pas l'homme du milieu.
Évidemment. Pour ça, il faut de la crypto plus complexe. Mais tu reconnaîtras qu'une attaque interactive comme celle-là est très largement plus difficile à mener qu'une écoute passive et un rejeu.
Arnaud Gomes-do-Vale , dans le message
<m3ty0lddch.fsf@carrosse.glou.org>, a écrit :
Ça empêche certes le rejeu, mais ça ne gêne pas l'homme du milieu.
Évidemment. Pour ça, il faut de la crypto plus complexe. Mais tu
reconnaîtras qu'une attaque interactive comme celle-là est très largement
plus difficile à mener qu'une écoute passive et un rejeu.
Arnaud Gomes-do-Vale , dans le message , a écrit :
Ça empêche certes le rejeu, mais ça ne gêne pas l'homme du milieu.
Évidemment. Pour ça, il faut de la crypto plus complexe. Mais tu reconnaîtras qu'une attaque interactive comme celle-là est très largement plus difficile à mener qu'une écoute passive et un rejeu.
Pascal Hambourg
Nicolas George a écrit :
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.
Effectivement le mot de passe est en clair dans /etc/ppp/chap-secrets.
Si on veut se passer de crypto asymétrique, c'est l'un ou l'autre.
Nicolas George a écrit :
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.
Effectivement le mot de passe est en clair dans /etc/ppp/chap-secrets.
Si on veut se passer de crypto asymétrique, c'est l'un ou l'autre.
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.
Effectivement le mot de passe est en clair dans /etc/ppp/chap-secrets.
Si on veut se passer de crypto asymétrique, c'est l'un ou l'autre.
Pascal Hambourg
Nicolas George a écrit :
Arnaud Gomes-do-Vale , dans le message , a écrit :
Ça empêche certes le rejeu, mais ça ne gêne pas l'homme du milieu.
Effectivement. Même si l'attaquant ne connaît pas le mot de passe en clair, il peut ouvrir une session sur le serveur véritable. Bref, sans vérification préalable de l'identité du serveur par le client, point de salut.
Évidemment. Pour ça, il faut de la crypto plus complexe. Mais tu reconnaîtras qu'une attaque interactive comme celle-là est très largement plus difficile à mener qu'une écoute passive et un rejeu.
Qu'entends-tu par écoute passive dans le cas de SSH ?
Nicolas George a écrit :
Arnaud Gomes-do-Vale , dans le message
<m3ty0lddch.fsf@carrosse.glou.org>, a écrit :
Ça empêche certes le rejeu, mais ça ne gêne pas l'homme du milieu.
Effectivement. Même si l'attaquant ne connaît pas le mot de passe en
clair, il peut ouvrir une session sur le serveur véritable. Bref, sans
vérification préalable de l'identité du serveur par le client, point de
salut.
Évidemment. Pour ça, il faut de la crypto plus complexe. Mais tu
reconnaîtras qu'une attaque interactive comme celle-là est très largement
plus difficile à mener qu'une écoute passive et un rejeu.
Qu'entends-tu par écoute passive dans le cas de SSH ?
Arnaud Gomes-do-Vale , dans le message , a écrit :
Ça empêche certes le rejeu, mais ça ne gêne pas l'homme du milieu.
Effectivement. Même si l'attaquant ne connaît pas le mot de passe en clair, il peut ouvrir une session sur le serveur véritable. Bref, sans vérification préalable de l'identité du serveur par le client, point de salut.
Évidemment. Pour ça, il faut de la crypto plus complexe. Mais tu reconnaîtras qu'une attaque interactive comme celle-là est très largement plus difficile à mener qu'une écoute passive et un rejeu.
Qu'entends-tu par écoute passive dans le cas de SSH ?
Pascal Hambourg
Fabien LE LEZ a écrit :
On Sat, 14 Apr 2012 14:27:18 +0200, Pascal Hambourg :
Pour quoi faire ?
Pour faire avancer le schmilblick.
Par exemple ?
Fabien LE LEZ a écrit :
On Sat, 14 Apr 2012 14:27:18 +0200, Pascal Hambourg
<boite-a-spam@plouf.fr.eu.org>:
Pascal Hambourg , dans le message <jme6hg$9tj$, a écrit :
Qu'entends-tu par écoute passive dans le cas de SSH ?
SSH utilise de la crypto asymétrique.
Kevin Denis
Le 15-04-2012, Pascal Hambourg a écrit :
Bref, sans vérification préalable de l'identité du serveur par le client, point de salut.
En fait, il semble que si, cf un message de TP: news:<4d344e34$0$29070$
N'y a t'il pas de solution pour protéger le mot de passe de l'utilisateur distrait?
Dans le cas général, ça existe : ce sont les protocoles dits PAKE (Password-Authenticated Key Exchange -- parfois, on dit "Agreement" au lieu de "Exchange"). Le premier est EKE ("Encrypted Key Exchange") décrit par Bellovin et Merritt en 1992(*). Le plus connu est SRP, publié par Wu en 1998. Un protocole PAKE comporte un échange de clé "classique" et n'a pas besoin d'être joué dans un tunnel pré-établi. Les caractéristiques sont assez "magiques" : à l'issue du protocole, le client et le serveur se sont authentifiés mutuellement, relativement à leur connaissance du mot de passe, et ont une clé secrète commune de forte entropie (qu'on peut utiliser pour chiffer symmétriquement la suite de la conversation). Néanmoins, un faux serveur ou un faux client n'apprend pas le mot de passe ni même un hash du mot de passe ou quoi que ce soit qui permette d'"essayer" des mots de passe. SRP rajoute même une propriété intéressante, qui est que le serveur n'a pas besoin de stocker le mot de passe, seulement une forme "hachée" (mais pas avec n'importe quelle fonction de hachage).
SRP est intégré dans SSL/TLS, cf RFC 5054 : http://tools.ietf.org/html/rfc5054 (on attend que les browsers Web veuillent bien l'implémenter).
Un ennui vis-à-vis des mots de passe Unix est qu'un serveur Unix ne stocke pas les mots de passe, ni leur haché à la sauce SRP, mais une forme dérivée avec salt. Donc, intégrer SRP dans SSH et s'arranger pour que ça tombe sur les mêmes mots de passe que les mots de passe Unix pourrait être compliqué.
Le 15-04-2012, Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> a écrit :
Bref, sans
vérification préalable de l'identité du serveur par le client, point de
salut.
En fait, il semble que si, cf un message de TP:
news:<4d344e34$0$29070$426a34cc@news.free.fr>
N'y a t'il pas de solution pour protéger le mot de passe de
l'utilisateur distrait?
Dans le cas général, ça existe : ce sont les protocoles dits PAKE
(Password-Authenticated Key Exchange -- parfois, on dit "Agreement" au
lieu de "Exchange"). Le premier est EKE ("Encrypted Key Exchange")
décrit par Bellovin et Merritt en 1992(*). Le plus connu est SRP, publié
par Wu en 1998. Un protocole PAKE comporte un échange de clé "classique"
et n'a pas besoin d'être joué dans un tunnel pré-établi. Les
caractéristiques sont assez "magiques" : à l'issue du protocole, le
client et le serveur se sont authentifiés mutuellement, relativement à
leur connaissance du mot de passe, et ont une clé secrète commune de
forte entropie (qu'on peut utiliser pour chiffer symmétriquement la
suite de la conversation). Néanmoins, un faux serveur ou un faux client
n'apprend pas le mot de passe ni même un hash du mot de passe ou quoi
que ce soit qui permette d'"essayer" des mots de passe. SRP rajoute même
une propriété intéressante, qui est que le serveur n'a pas besoin de
stocker le mot de passe, seulement une forme "hachée" (mais pas avec
n'importe quelle fonction de hachage).
SRP est intégré dans SSL/TLS, cf RFC 5054 :
http://tools.ietf.org/html/rfc5054
(on attend que les browsers Web veuillent bien l'implémenter).
Un ennui vis-à-vis des mots de passe Unix est qu'un serveur Unix ne
stocke pas les mots de passe, ni leur haché à la sauce SRP, mais une
forme dérivée avec salt. Donc, intégrer SRP dans SSH et s'arranger pour
que ça tombe sur les mêmes mots de passe que les mots de passe Unix
pourrait être compliqué.
Bref, sans vérification préalable de l'identité du serveur par le client, point de salut.
En fait, il semble que si, cf un message de TP: news:<4d344e34$0$29070$
N'y a t'il pas de solution pour protéger le mot de passe de l'utilisateur distrait?
Dans le cas général, ça existe : ce sont les protocoles dits PAKE (Password-Authenticated Key Exchange -- parfois, on dit "Agreement" au lieu de "Exchange"). Le premier est EKE ("Encrypted Key Exchange") décrit par Bellovin et Merritt en 1992(*). Le plus connu est SRP, publié par Wu en 1998. Un protocole PAKE comporte un échange de clé "classique" et n'a pas besoin d'être joué dans un tunnel pré-établi. Les caractéristiques sont assez "magiques" : à l'issue du protocole, le client et le serveur se sont authentifiés mutuellement, relativement à leur connaissance du mot de passe, et ont une clé secrète commune de forte entropie (qu'on peut utiliser pour chiffer symmétriquement la suite de la conversation). Néanmoins, un faux serveur ou un faux client n'apprend pas le mot de passe ni même un hash du mot de passe ou quoi que ce soit qui permette d'"essayer" des mots de passe. SRP rajoute même une propriété intéressante, qui est que le serveur n'a pas besoin de stocker le mot de passe, seulement une forme "hachée" (mais pas avec n'importe quelle fonction de hachage).
SRP est intégré dans SSL/TLS, cf RFC 5054 : http://tools.ietf.org/html/rfc5054 (on attend que les browsers Web veuillent bien l'implémenter).
Un ennui vis-à-vis des mots de passe Unix est qu'un serveur Unix ne stocke pas les mots de passe, ni leur haché à la sauce SRP, mais une forme dérivée avec salt. Donc, intégrer SRP dans SSH et s'arranger pour que ça tombe sur les mêmes mots de passe que les mots de passe Unix pourrait être compliqué.
Pascal Hambourg
Kevin Denis a écrit :
Le 15-04-2012, Pascal Hambourg a écrit :
Bref, sans vérification préalable de l'identité du serveur par le client, point de salut.
En fait, il semble que si, cf un message de TP: news:<4d344e34$0$29070$
Je n'arrive pas à retrouver cet article, ni sur le serveur de mon FAI, de Free ni chez Google Groups.
Un ennui vis-à-vis des mots de passe Unix est qu'un serveur Unix ne stocke pas les mots de passe, ni leur haché à la sauce SRP, mais une forme dérivée avec salt. Donc, intégrer SRP dans SSH et s'arranger pour que ça tombe sur les mêmes mots de passe que les mots de passe Unix pourrait être compliqué.
Précisément. D'où ma conclusion.
Kevin Denis a écrit :
Le 15-04-2012, Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> a écrit :
Bref, sans
vérification préalable de l'identité du serveur par le client, point de
salut.
En fait, il semble que si, cf un message de TP:
news:<4d344e34$0$29070$426a34cc@news.free.fr>
Je n'arrive pas à retrouver cet article, ni sur le serveur de mon FAI,
de Free ni chez Google Groups.
Un ennui vis-à-vis des mots de passe Unix est qu'un serveur Unix ne
stocke pas les mots de passe, ni leur haché à la sauce SRP, mais une
forme dérivée avec salt. Donc, intégrer SRP dans SSH et s'arranger pour
que ça tombe sur les mêmes mots de passe que les mots de passe Unix
pourrait être compliqué.
Bref, sans vérification préalable de l'identité du serveur par le client, point de salut.
En fait, il semble que si, cf un message de TP: news:<4d344e34$0$29070$
Je n'arrive pas à retrouver cet article, ni sur le serveur de mon FAI, de Free ni chez Google Groups.
Un ennui vis-à-vis des mots de passe Unix est qu'un serveur Unix ne stocke pas les mots de passe, ni leur haché à la sauce SRP, mais une forme dérivée avec salt. Donc, intégrer SRP dans SSH et s'arranger pour que ça tombe sur les mêmes mots de passe que les mots de passe Unix pourrait être compliqué.
Précisément. D'où ma conclusion.
Kevin Denis
Le 16-04-2012, Pascal Hambourg a écrit :
En fait, il semble que si, cf un message de TP: news:<4d344e34$0$29070$
Je n'arrive pas à retrouver cet article, ni sur le serveur de mon FAI, de Free ni chez Google Groups.
Un ennui vis-à-vis des mots de passe Unix est qu'un serveur Unix ne stocke pas les mots de passe, ni leur haché à la sauce SRP, mais une forme dérivée avec salt. Donc, intégrer SRP dans SSH et s'arranger pour que ça tombe sur les mêmes mots de passe que les mots de passe Unix pourrait être compliqué.
Précisément. D'où ma conclusion.
-- Kevin
Le 16-04-2012, Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> a écrit :
En fait, il semble que si, cf un message de TP:
news:<4d344e34$0$29070$426a34cc@news.free.fr>
Je n'arrive pas à retrouver cet article, ni sur le serveur de mon FAI,
de Free ni chez Google Groups.
Un ennui vis-à-vis des mots de passe Unix est qu'un serveur Unix ne
stocke pas les mots de passe, ni leur haché à la sauce SRP, mais une
forme dérivée avec salt. Donc, intégrer SRP dans SSH et s'arranger pour
que ça tombe sur les mêmes mots de passe que les mots de passe Unix
pourrait être compliqué.
Un ennui vis-à-vis des mots de passe Unix est qu'un serveur Unix ne stocke pas les mots de passe, ni leur haché à la sauce SRP, mais une forme dérivée avec salt. Donc, intégrer SRP dans SSH et s'arranger pour que ça tombe sur les mêmes mots de passe que les mots de passe Unix pourrait être compliqué.
