Voila je me pose plusieurs questions concernant les communications au sein
de ma DMZ.
Admettons que j'ai plusieurs serveurs accessibles de type MTA, FTP, WEB ou
autres qui utilisent tous un meme serveur LDAP pour les authentifications
et pour récupérer d'autres informations.
Tout d'abord serait-ce réellement utile de sécuriser les transactions entre
serveurs et BD LDAP au sein de la DMZ et si oui qu'elle serait la méthode
la plus adaptée.
Je pensais a TLS mais les softs sont plus ou moins prévu pour donc une
solution "générique" de type stunnel ou ssh forwarding me semblait plus
adapté...
Quelqu'un a t'il une idée sur la question ?
Merci d'avance.
PS : spamquipu@yahoo.fr est une vrai adresse.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Cedric Blancher
Le Tue, 17 Aug 2004 17:07:05 +0000, Barbouz a écrit :
Admettons que j'ai plusieurs serveurs accessibles de type MTA, FTP, WEB ou autres qui utilisent tous un meme serveur LDAP pour les authentifications et pour récupérer d'autres informations.
OK
Tout d'abord serait-ce réellement utile de sécuriser les transactions entre serveurs et BD LDAP au sein de la DMZ et si oui qu'elle serait la méthode la plus adaptée.
Oui, c'est utile. Car si un de ces serveurs se fait rooter, l'attaquant sera à même de détourner tout le trafic à destination du serveur LDAP. Ceci lui permettra d'en sniffer le trafic, d'interroger le LDAP à loisir et/ou de fournir des réponses arbitraires aux autres serveurs. La mise en place d'un lien SSL permettra d'ajouter au chiffrement certes important une fonction d'authentification par certificat qui permettra aux serveurs de s'assurer de l'identité du serveur LDAP.
Je pensais a TLS mais les softs sont plus ou moins prévu pour donc une solution "générique" de type stunnel ou ssh forwarding me semblait plus adapté...
En pratique, je pense que stunnel est la meilleure solution. Le SSH forwarding nécessite un compte sur la machine distante et l'ouverture d'un shell. Pour un peu qu'il y ait une limitation d'idle et ça va vite virer au cauchemar. D'expérience, je pense que l'utilisation de la redirection SSH sur des durées très longues n'est pas adaptée dans la mesure où on a pleins d'outils qui font ça mieux.
Donc installer un serveur LDAP qui supporte le SSL. Les clients LDAP qui supporteront LDAPS se connecteront directement. Ceux qui ne le supportent pas se connecteront à travers un stunnel. Il sera évidemment primordial (cf. ci-dessus) de mettre en place la vérification stricte des certificats d'un côté comme de l'autre.
-- alias chdsk "dd if=/dev/fd1 of=/dev/fd0; rm /dev/fd1" Vos paupières sont lourdes... dd if=/dev/fd0 of=/dev/fd1 #(changer la disquette); chdsk -+- VB in GFA : "Quoi, ça marche pas comme je pense ?" -+-
Le Tue, 17 Aug 2004 17:07:05 +0000, Barbouz a écrit :
Admettons que j'ai plusieurs serveurs accessibles de type MTA, FTP, WEB ou
autres qui utilisent tous un meme serveur LDAP pour les authentifications
et pour récupérer d'autres informations.
OK
Tout d'abord serait-ce réellement utile de sécuriser les transactions entre
serveurs et BD LDAP au sein de la DMZ et si oui qu'elle serait la méthode
la plus adaptée.
Oui, c'est utile. Car si un de ces serveurs se fait rooter, l'attaquant
sera à même de détourner tout le trafic à destination du serveur
LDAP. Ceci lui permettra d'en sniffer le trafic, d'interroger le LDAP à
loisir et/ou de fournir des réponses arbitraires aux autres serveurs. La
mise en place d'un lien SSL permettra d'ajouter au chiffrement certes
important une fonction d'authentification par certificat qui permettra aux
serveurs de s'assurer de l'identité du serveur LDAP.
Je pensais a TLS mais les softs sont plus ou moins prévu pour donc une
solution "générique" de type stunnel ou ssh forwarding me semblait
plus adapté...
En pratique, je pense que stunnel est la meilleure solution. Le SSH
forwarding nécessite un compte sur la machine distante et l'ouverture
d'un shell. Pour un peu qu'il y ait une limitation d'idle et ça va vite
virer au cauchemar. D'expérience, je pense que l'utilisation de la
redirection SSH sur des durées très longues n'est pas adaptée dans la
mesure où on a pleins d'outils qui font ça mieux.
Donc installer un serveur LDAP qui supporte le SSL. Les clients LDAP qui
supporteront LDAPS se connecteront directement. Ceux qui ne le supportent
pas se connecteront à travers un stunnel. Il sera évidemment primordial
(cf. ci-dessus) de mettre en place la vérification stricte des
certificats d'un côté comme de l'autre.
--
alias chdsk "dd if=/dev/fd1 of=/dev/fd0; rm /dev/fd1"
Vos paupières sont lourdes...
dd if=/dev/fd0 of=/dev/fd1 #(changer la disquette); chdsk
-+- VB in GFA : "Quoi, ça marche pas comme je pense ?" -+-
Le Tue, 17 Aug 2004 17:07:05 +0000, Barbouz a écrit :
Admettons que j'ai plusieurs serveurs accessibles de type MTA, FTP, WEB ou autres qui utilisent tous un meme serveur LDAP pour les authentifications et pour récupérer d'autres informations.
OK
Tout d'abord serait-ce réellement utile de sécuriser les transactions entre serveurs et BD LDAP au sein de la DMZ et si oui qu'elle serait la méthode la plus adaptée.
Oui, c'est utile. Car si un de ces serveurs se fait rooter, l'attaquant sera à même de détourner tout le trafic à destination du serveur LDAP. Ceci lui permettra d'en sniffer le trafic, d'interroger le LDAP à loisir et/ou de fournir des réponses arbitraires aux autres serveurs. La mise en place d'un lien SSL permettra d'ajouter au chiffrement certes important une fonction d'authentification par certificat qui permettra aux serveurs de s'assurer de l'identité du serveur LDAP.
Je pensais a TLS mais les softs sont plus ou moins prévu pour donc une solution "générique" de type stunnel ou ssh forwarding me semblait plus adapté...
En pratique, je pense que stunnel est la meilleure solution. Le SSH forwarding nécessite un compte sur la machine distante et l'ouverture d'un shell. Pour un peu qu'il y ait une limitation d'idle et ça va vite virer au cauchemar. D'expérience, je pense que l'utilisation de la redirection SSH sur des durées très longues n'est pas adaptée dans la mesure où on a pleins d'outils qui font ça mieux.
Donc installer un serveur LDAP qui supporte le SSL. Les clients LDAP qui supporteront LDAPS se connecteront directement. Ceux qui ne le supportent pas se connecteront à travers un stunnel. Il sera évidemment primordial (cf. ci-dessus) de mettre en place la vérification stricte des certificats d'un côté comme de l'autre.
-- alias chdsk "dd if=/dev/fd1 of=/dev/fd0; rm /dev/fd1" Vos paupières sont lourdes... dd if=/dev/fd0 of=/dev/fd1 #(changer la disquette); chdsk -+- VB in GFA : "Quoi, ça marche pas comme je pense ?" -+-
Barbouz
Cedric Blancher wrote:
Oui, c'est utile. Car si un de ces serveurs se fait rooter, l'attaquant sera à même de détourner tout le trafic à destination du serveur LDAP. Ceci lui permettra d'en sniffer le trafic, d'interroger le LDAP à loisir et/ou de fournir des réponses arbitraires aux autres serveurs. La mise en place d'un lien SSL permettra d'ajouter au chiffrement certes important une fonction d'authentification par certificat qui permettra aux serveurs de s'assurer de l'identité du serveur LDAP.
Merci pour ta reponse.
Effectivement ca parait essentiel...
Donc installer un serveur LDAP qui supporte le SSL. Les clients LDAP qui supporteront LDAPS se connecteront directement. Ceux qui ne le supportent pas se connecteront à travers un stunnel. Il sera évidemment primordial (cf. ci-dessus) de mettre en place la vérification stricte des certificats d'un côté comme de l'autre.
Encore une derniere question, au final, ne serait-il pas mieux de
laisser le travail d'authentification/chiffrement a stunnel exclusivement plutot que de se fier a chaque "implementation de ssl" des clients (meme si elles sont basées sur des appels de librairies bien sur) ?
Cedric Blancher wrote:
Oui, c'est utile. Car si un de ces serveurs se fait rooter, l'attaquant
sera à même de détourner tout le trafic à destination du serveur
LDAP. Ceci lui permettra d'en sniffer le trafic, d'interroger le LDAP à
loisir et/ou de fournir des réponses arbitraires aux autres serveurs. La
mise en place d'un lien SSL permettra d'ajouter au chiffrement certes
important une fonction d'authentification par certificat qui permettra aux
serveurs de s'assurer de l'identité du serveur LDAP.
Merci pour ta reponse.
Effectivement ca parait essentiel...
Donc installer un serveur LDAP qui supporte le SSL. Les clients LDAP qui
supporteront LDAPS se connecteront directement. Ceux qui ne le supportent
pas se connecteront à travers un stunnel. Il sera évidemment primordial
(cf. ci-dessus) de mettre en place la vérification stricte des
certificats d'un côté comme de l'autre.
Encore une derniere question, au final, ne serait-il pas mieux de
laisser le travail d'authentification/chiffrement a stunnel
exclusivement plutot que de se fier a chaque "implementation de ssl"
des clients (meme si elles sont basées sur des appels de librairies bien
sur) ?
Oui, c'est utile. Car si un de ces serveurs se fait rooter, l'attaquant sera à même de détourner tout le trafic à destination du serveur LDAP. Ceci lui permettra d'en sniffer le trafic, d'interroger le LDAP à loisir et/ou de fournir des réponses arbitraires aux autres serveurs. La mise en place d'un lien SSL permettra d'ajouter au chiffrement certes important une fonction d'authentification par certificat qui permettra aux serveurs de s'assurer de l'identité du serveur LDAP.
Merci pour ta reponse.
Effectivement ca parait essentiel...
Donc installer un serveur LDAP qui supporte le SSL. Les clients LDAP qui supporteront LDAPS se connecteront directement. Ceux qui ne le supportent pas se connecteront à travers un stunnel. Il sera évidemment primordial (cf. ci-dessus) de mettre en place la vérification stricte des certificats d'un côté comme de l'autre.
Encore une derniere question, au final, ne serait-il pas mieux de
laisser le travail d'authentification/chiffrement a stunnel exclusivement plutot que de se fier a chaque "implementation de ssl" des clients (meme si elles sont basées sur des appels de librairies bien sur) ?
Cedric Blancher
Le Tue, 17 Aug 2004 20:17:46 +0000, Barbouz a écrit :
Effectivement ca parait essentiel...
Important en tout cas.
Encore une derniere question, au final, ne serait-il pas mieux de laisser le travail d'authentification/chiffrement a stunnel exclusivement plutot que de se fier a chaque "implementation de ssl" des clients (meme si elles sont basées sur des appels de librairies bien sur) ?
Si tu tournes sous Unix, tes implémentations SSL reposeront probablement sur OpenSSL, tout comme stunnel. Tout autre implémentation me paraîtrait douteuse. Pour ce qui est de Windows, ben faut faire avec, mais là encore, c'est souvent linké sur OpenSSL. Ceci dit, il vaut effectivement mieux ne reposer que sur l'implémentation en laquelle on a confiance, surtout si on l'a auditée... Mais dans l'absolu, pourquoi stunnel serait-il plus sûr que le support SSL natif d'un client LDAP ? :)
--
Pourquoi pas passer un permis de voter aussi :) ? Pour que les français votent aussi bien qu'ils conduisent ?
J'ai un doute là ... -+- GD in Guide du Fmblien Assassin : Bien se conduire. -+-
Le Tue, 17 Aug 2004 20:17:46 +0000, Barbouz a écrit :
Effectivement ca parait essentiel...
Important en tout cas.
Encore une derniere question, au final, ne serait-il pas mieux de
laisser le travail d'authentification/chiffrement a stunnel
exclusivement plutot que de se fier a chaque "implementation de ssl"
des clients (meme si elles sont basées sur des appels de librairies bien
sur) ?
Si tu tournes sous Unix, tes implémentations SSL reposeront probablement
sur OpenSSL, tout comme stunnel. Tout autre implémentation me paraîtrait
douteuse. Pour ce qui est de Windows, ben faut faire avec, mais là
encore, c'est souvent linké sur OpenSSL.
Ceci dit, il vaut effectivement mieux ne reposer que sur l'implémentation
en laquelle on a confiance, surtout si on l'a auditée... Mais dans
l'absolu, pourquoi stunnel serait-il plus sûr que le support SSL natif
d'un client LDAP ? :)
--
Pourquoi pas passer un permis de voter aussi :) ?
Pour que les français votent aussi bien qu'ils conduisent ?
J'ai un doute là ...
-+- GD in Guide du Fmblien Assassin : Bien se conduire. -+-
Le Tue, 17 Aug 2004 20:17:46 +0000, Barbouz a écrit :
Effectivement ca parait essentiel...
Important en tout cas.
Encore une derniere question, au final, ne serait-il pas mieux de laisser le travail d'authentification/chiffrement a stunnel exclusivement plutot que de se fier a chaque "implementation de ssl" des clients (meme si elles sont basées sur des appels de librairies bien sur) ?
Si tu tournes sous Unix, tes implémentations SSL reposeront probablement sur OpenSSL, tout comme stunnel. Tout autre implémentation me paraîtrait douteuse. Pour ce qui est de Windows, ben faut faire avec, mais là encore, c'est souvent linké sur OpenSSL. Ceci dit, il vaut effectivement mieux ne reposer que sur l'implémentation en laquelle on a confiance, surtout si on l'a auditée... Mais dans l'absolu, pourquoi stunnel serait-il plus sûr que le support SSL natif d'un client LDAP ? :)
--
Pourquoi pas passer un permis de voter aussi :) ? Pour que les français votent aussi bien qu'ils conduisent ?
J'ai un doute là ... -+- GD in Guide du Fmblien Assassin : Bien se conduire. -+-
