à part une analyse statistique de l'utilisation de la bp je vois pas
Par exemple, par défaut, la première réponse d'un serveur ssh c'est la banniere de version, qui se detecte facilement (et qui se change aussi facilement, mais ce n'est q'un exemple). Ensuite oui, certaines boites font de l'interception ssl systématique sur leurs proxy (sauf sur les sites pour lequel c'est interdit, tels que les banques).
rien ne m'empêche sur un serveur externe que je contrôle de mettre un service sur le port 80 qui répond à un bête client qui fait du http pour lui faire exécuter des commandes en interne.
Il y aura toujours un moyen, plus ou moins évident selon l'architecture en place. Le but est déjà d'éviter les plus triviaux.
elles ne servent à rien pour une personne déterminée à donner un accès vers l'intérieur
La sécurité totale n'existe pas (même chez OpenBSD :) , mais la personne en question risque de ce casser les dents sur les premières barrières en place, ce qui permettra de le detecter et de gentiment aller lui expliquer ce qu'il n'est pas sensé faire.
Le problème en soi n'est même pas le reverse tunnel, c'est le fait de ne plus contrôller le périmétre : qu'est ce qu'on sait de la sécurité du serveur qui monte le reverse ? Peut-être qu'il est cracké et que, sans le savoir, celui qui monte ce tunnel et qui est plein de bonnes intentions donne au passage accès au réseau de l'entreprise à un vil pirate qui n'en demande pas tant...
[^] # Re: Touche pas à (mon) grisbi !
Posté par Volnai . En réponse au journal Avec SPDY, Google souhaite accélérer remplacer/accélérer HTTP. Évalué à 1.
Par exemple, par défaut, la première réponse d'un serveur ssh c'est la banniere de version, qui se detecte facilement (et qui se change aussi facilement, mais ce n'est q'un exemple). Ensuite oui, certaines boites font de l'interception ssl systématique sur leurs proxy (sauf sur les sites pour lequel c'est interdit, tels que les banques).
rien ne m'empêche sur un serveur externe que je contrôle de mettre un service sur le port 80 qui répond à un bête client qui fait du http pour lui faire exécuter des commandes en interne.
Il y aura toujours un moyen, plus ou moins évident selon l'architecture en place. Le but est déjà d'éviter les plus triviaux.
elles ne servent à rien pour une personne déterminée à donner un accès vers l'intérieur
La sécurité totale n'existe pas (même chez OpenBSD :) , mais la personne en question risque de ce casser les dents sur les premières barrières en place, ce qui permettra de le detecter et de gentiment aller lui expliquer ce qu'il n'est pas sensé faire.
Le problème en soi n'est même pas le reverse tunnel, c'est le fait de ne plus contrôller le périmétre : qu'est ce qu'on sait de la sécurité du serveur qui monte le reverse ? Peut-être qu'il est cracké et que, sans le savoir, celui qui monte ce tunnel et qui est plein de bonnes intentions donne au passage accès au réseau de l'entreprise à un vil pirate qui n'en demande pas tant...