Je me pose des questions métaphysiques sur le fait ou non de faire une
authentification sur le proxy.
L'argumentation pour :
- On ne veut pas forcemment donner un accès web à tout le monde dans la
société (ici, ce n'est pas le cas).
- Il est embetant que n'importe qui qui se connecte sur le LAN puisse
acceder à Internet (e.g. un prestataire qui utilise son portable. En
théorie, c'est le genre de situation qui ne doit pas arriver. Un presta ne
peut pas se connecter avec son portable sur le LAN mais c'est plus une
restriction morale que technologique).
L'argumentation contre:
- Certains soft qui ne gèrent pas le fait qu'il faille passer par un proxy
authentifié.
- Certains soft qui gèrent le fait que l'on passer par un proxy authentifié
mais le mot de passe est sauvegardé plus ou moins surement (ca va du texte
en clair à du chiffrement blowfish). Dans la mesure où le mot de passe est
celui du compteWindows, je ne trouve pas que c'est une bonne idée.
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 Wed, 02 Feb 2005 10:10:26 +0000, choowie a écrit :
Je me pose des questions métaphysiques sur le fait ou non de faire une authentification sur le proxy. L'argumentation pour : [...]
Accessoirement, ça permet aux trojans/backdoors codés par des gens peu compétents de ne pas pouvoir établir de connexion vers l'extérieur.
L'argumentation contre: [...]
Pour le registre évoqué au-dessus, il est somme-toute assez facile de contourner cela pour HTTP/HTTPS si l'utilisateur a déjà fourni une authentification au cours de la session en cours.
--
Il ne pourra plus dire: "Voila, j'ai les numéros de pleins de filles dans ce carnet".... Je n'ai jamais pu le dire.
-+- AL in GFA : "La réalité est trop dure" -+-
Le Wed, 02 Feb 2005 10:10:26 +0000, choowie a écrit :
Je me pose des questions métaphysiques sur le fait ou non de faire une
authentification sur le proxy.
L'argumentation pour :
[...]
Accessoirement, ça permet aux trojans/backdoors codés par des gens peu
compétents de ne pas pouvoir établir de connexion vers l'extérieur.
L'argumentation contre:
[...]
Pour le registre évoqué au-dessus, il est somme-toute assez facile de
contourner cela pour HTTP/HTTPS si l'utilisateur a déjà fourni une
authentification au cours de la session en cours.
--
Il ne pourra plus dire: "Voila, j'ai les numéros de pleins de
filles dans ce carnet"....
Je n'ai jamais pu le dire.
Le Wed, 02 Feb 2005 10:10:26 +0000, choowie a écrit :
Je me pose des questions métaphysiques sur le fait ou non de faire une authentification sur le proxy. L'argumentation pour : [...]
Accessoirement, ça permet aux trojans/backdoors codés par des gens peu compétents de ne pas pouvoir établir de connexion vers l'extérieur.
L'argumentation contre: [...]
Pour le registre évoqué au-dessus, il est somme-toute assez facile de contourner cela pour HTTP/HTTPS si l'utilisateur a déjà fourni une authentification au cours de la session en cours.
--
Il ne pourra plus dire: "Voila, j'ai les numéros de pleins de filles dans ce carnet".... Je n'ai jamais pu le dire.
-+- AL in GFA : "La réalité est trop dure" -+-
choowie
Cedric Blancher wrote:
Je me pose des questions métaphysiques sur le fait ou non de faire une authentification sur le proxy. L'argumentation pour : [...]
Accessoirement, ça permet aux trojans/backdoors codés par des gens peu compétents de ne pas pouvoir établir de connexion vers l'extérieur. Oui, c'est vrai. Personnellement je ne compterais pas sur l'incompétence des
gens qui écrivent les trojans pour me protéger :o))
L'argumentation contre: [...]
Pour le registre évoqué au-dessus, il est somme-toute assez facile de contourner cela pour HTTP/HTTPS si l'utilisateur a déjà fourni une authentification au cours de la session en cours.
Mon plus gros problème vient des machines unix qui ne sont pas dans le domaine windows et qui ont des progs qui font des accès automatiques sur le web. Il suffit de regarder les maj nessus par exemple, c'est un bon fichier texte avec toutes les info en clair.
-- Choowie
Cedric Blancher wrote:
Je me pose des questions métaphysiques sur le fait ou non de faire
une authentification sur le proxy.
L'argumentation pour :
[...]
Accessoirement, ça permet aux trojans/backdoors codés par des gens peu
compétents de ne pas pouvoir établir de connexion vers l'extérieur.
Oui, c'est vrai. Personnellement je ne compterais pas sur l'incompétence des
gens qui écrivent les trojans pour me protéger :o))
L'argumentation contre:
[...]
Pour le registre évoqué au-dessus, il est somme-toute assez facile de
contourner cela pour HTTP/HTTPS si l'utilisateur a déjà fourni une
authentification au cours de la session en cours.
Mon plus gros problème vient des machines unix qui ne sont pas dans le
domaine windows et qui ont des progs qui font des accès automatiques sur le
web. Il suffit de regarder les maj nessus par exemple, c'est un bon fichier
texte avec toutes les info en clair.
Je me pose des questions métaphysiques sur le fait ou non de faire une authentification sur le proxy. L'argumentation pour : [...]
Accessoirement, ça permet aux trojans/backdoors codés par des gens peu compétents de ne pas pouvoir établir de connexion vers l'extérieur. Oui, c'est vrai. Personnellement je ne compterais pas sur l'incompétence des
gens qui écrivent les trojans pour me protéger :o))
L'argumentation contre: [...]
Pour le registre évoqué au-dessus, il est somme-toute assez facile de contourner cela pour HTTP/HTTPS si l'utilisateur a déjà fourni une authentification au cours de la session en cours.
Mon plus gros problème vient des machines unix qui ne sont pas dans le domaine windows et qui ont des progs qui font des accès automatiques sur le web. Il suffit de regarder les maj nessus par exemple, c'est un bon fichier texte avec toutes les info en clair.
-- Choowie
Dominique Blas
choowie wrote:
Bjr,
Hum, sachant que l'on empêchera pas un prestataire déterminé (qui se fera viré ensuite, soit) de passer outre (substitution de MAC, écoute du réseau après inondation du vieux switch, découverte de couple id/mdp [qui sont codés en base64 donc en clair] qui vont bien) c'est une question de niveau ensuite.
Pourquoi ne pas simplement authentifier selon l'adresse IP allouée par un serveur DHCP (combinant MAC et IP) ? OK, le prestataire peut forcer l'adresse MAC et se brancher à la place d'un poste fixe existant (procédure plus discrète en outre que la précédente c'est vrai et donc plus difficilement décelable). OK, les dada grecs intelligents ou pas passeront allègrement au travers du coup.
Mais cela résout l'argumentation contre et répond à l'essentiel de l'argumentation pour et ceci, sans trop surcharger l'administrateur (qui n'a que la liste du serveur DHCP à gérer voire, si celle-ci est en annuaire LDAP, que l'annuaire LDAP à gérer).
Pour aller plus loin, et bien ma foi, on bloque en sortie (ACL), on place un détecteur d'intrusion, on impose que du HTTP, on installe un analyseur de flux (dont on étudie les journaux à intervalle régulier), etc. On peut aussi tout bloquer et réouvrir en fonction des besoins de chacun. Ou encore, placer tout le monde sur des terminaux (X/Citrix/TSE) ce qui simplifie la vie de l'administrateur de sécurité mais pas celle de l'administrateur des réseaux et encore moins celle de l'administrateur des systèmes.
db
-- courriel : usenet blas net
choowie wrote:
Bjr,
Hum, sachant que l'on empêchera pas un prestataire déterminé (qui se fera
viré ensuite, soit) de passer outre (substitution de MAC, écoute du réseau
après inondation du vieux switch, découverte de couple id/mdp [qui sont
codés en base64 donc en clair] qui vont bien) c'est une question de niveau
ensuite.
Pourquoi ne pas simplement authentifier selon l'adresse IP allouée par un
serveur DHCP (combinant MAC et IP) ?
OK, le prestataire peut forcer l'adresse MAC et se brancher à la place d'un
poste fixe existant (procédure plus discrète en outre que la précédente
c'est vrai et donc plus difficilement décelable).
OK, les dada grecs intelligents ou pas passeront allègrement au travers du
coup.
Mais cela résout l'argumentation contre et répond à l'essentiel de
l'argumentation pour et ceci, sans trop surcharger l'administrateur
(qui n'a que la liste du serveur DHCP à gérer voire, si celle-ci est en
annuaire LDAP, que l'annuaire LDAP à gérer).
Pour aller plus loin, et bien ma foi, on bloque en sortie (ACL),
on place un détecteur d'intrusion, on impose que du HTTP, on installe un
analyseur de flux (dont on étudie les journaux à intervalle régulier), etc.
On peut aussi tout bloquer et réouvrir en fonction des besoins de chacun.
Ou encore, placer tout le monde sur des terminaux (X/Citrix/TSE) ce qui
simplifie la vie de l'administrateur de sécurité mais pas celle de
l'administrateur des réseaux et encore moins celle de l'administrateur des
systèmes.
Hum, sachant que l'on empêchera pas un prestataire déterminé (qui se fera viré ensuite, soit) de passer outre (substitution de MAC, écoute du réseau après inondation du vieux switch, découverte de couple id/mdp [qui sont codés en base64 donc en clair] qui vont bien) c'est une question de niveau ensuite.
Pourquoi ne pas simplement authentifier selon l'adresse IP allouée par un serveur DHCP (combinant MAC et IP) ? OK, le prestataire peut forcer l'adresse MAC et se brancher à la place d'un poste fixe existant (procédure plus discrète en outre que la précédente c'est vrai et donc plus difficilement décelable). OK, les dada grecs intelligents ou pas passeront allègrement au travers du coup.
Mais cela résout l'argumentation contre et répond à l'essentiel de l'argumentation pour et ceci, sans trop surcharger l'administrateur (qui n'a que la liste du serveur DHCP à gérer voire, si celle-ci est en annuaire LDAP, que l'annuaire LDAP à gérer).
Pour aller plus loin, et bien ma foi, on bloque en sortie (ACL), on place un détecteur d'intrusion, on impose que du HTTP, on installe un analyseur de flux (dont on étudie les journaux à intervalle régulier), etc. On peut aussi tout bloquer et réouvrir en fonction des besoins de chacun. Ou encore, placer tout le monde sur des terminaux (X/Citrix/TSE) ce qui simplifie la vie de l'administrateur de sécurité mais pas celle de l'administrateur des réseaux et encore moins celle de l'administrateur des systèmes.