Le service d'agent msdeploy peut-il ouvrir un vecteur d'attaque sur nos serveurs?

nous évaluons l'utilisation du service msdeploy Web Deployment Agent pour les déploiements automatiques sur nos serveurs de production.

Une chose que nous ne pouvons pas découvrir, ce sont les impacts potentiels sur la sécurité.

D'une part, nos serveurs Web sont bien sûr sécurisés (derrière les pare-feu et les équilibreurs de charge), donc seul le trafic http (s) est autorisé de l'extérieur.

Néanmoins, l'agent de déploiement Web s'exécute intégré à IIS (la seule chose qui fait face à l'extérieur), car il est accessible via http (s). Nous craignons donc qu'il soit possible d'accéder à l'agent via les sites Web hébergés sur cet IIS - et d'obtenir ainsi un accès en lecture et en écriture à tous nos sites Web.

Dans quelle mesure msdeploy est-il sécurisé pour une utilisation dans des environnements de production?

Mise à jour: le serveur Web de production exécute IIS7.

Cela fait un moment que je ne l'ai pas utilisé, et je ne l'ai utilisé qu'avec IIS 6 qui n'inclut pas la partie de gestion Web. Vous pouvez modifier l'URL et le port de gestion à distance et les bloquer sur le pare-feu externe. Voir ceci: Personnalisation et sécurisation du service distant . Son principal mécanisme de sécurité semble être la sécurité des comptes d'utilisateurs, mais comme vous l'avez dit, tout est dans IIS, donc une vulnérabilité IIS pourrait rendre les mesures de sécurité inutiles jusqu'à ce qu'elles soient corrigées. Pour cette seule raison, j'hésiterais à autoriser la mise à jour du contenu Web à partir d'Internet, mais cela dépend des exigences de sécurité de votre organisation par rapport aux besoins de votre développeur Web.

Pour éviter d'exposer le service de déploiement Web à Internet, vous pouvez effectuer les opérations suivantes:

• faire écouter le site Web par défaut sur une IP interne uniquement qui n'est pas NATed ou fait partie de la plage IP d'équilibrage de charge
• vous pouvez demander au site Web de gestion par défaut d'écouter uniquement sur localhost, puis d'écrire un script qui appelle l'exécutable msdeploy sur chaque hôte pour s'exécuter localement (au lieu d'utiliser msdeploy pour se connecter à distance à tous les hôtes à partir d'un seul point)
• demandez à votre équilibreur de charge de filtrer les demandes externes qui tentent d'atteindre l'URL de déploiement Web (par exemple, https: // serveur: 8081 / MSDeploy )
• avoir un hôte de déploiement (interne) désigné d'où proviennent tous vos déploiements Web et autoriser uniquement cette IP à se connecter à vos serveurs Web sur l'URL de déploiement (bloquer tout ce qui ne provient pas de l'hôte de déploiement unique)

S'il y a toujours un besoin d'avoir une fonctionnalité de déploiement Web disponible directement à partir d'Internet, dites si tous vos développeurs Web ont travaillé à distance (je ne peux pas imaginer pourquoi cela serait nécessaire directementavec l'utilisation répandue du VPN), vous pourriez avoir un processus de déploiement en deux étapes où vous configurez une DMZ isolée avec une boîte IIS 7 activée pour le déploiement Web (distincte de la DMZ de votre batterie de serveurs Web), et autorisez vos développeurs Web à connectez-vous uniquement à cette DMZ depuis Internet pour déployer les modifications à distance. Ensuite, vous pouvez vous connecter en interne à cet hôte et déployer sur le reste de vos serveurs Web après avoir examiné les modifications, les tests, etc. Même cette méthode n'est pas sans risques cependant - un utilisateur malveillant peut finir par compromettre la fonctionnalité de déploiement Web, en introduisant certains code malveillant à votre insu et vous pourriez sans le savoir l'introduire dans votre environnement de production.

Réponse simple. OUI, tout ce qui s'exécute sur n'importe quel ordinateur ouvre des vecteurs d'attaque. Il faut toujours supposer qu'il existe des vulnérabilités dans les logiciels. L'atténuation est un facteur clé, limitez l'accès aux réseaux, aux utilisateurs, aux ordinateurs, aux adresses IP, etc. Vérifiez également l'accès physique.

Vous pouvez également restreindre l'heure à laquelle les mises à jour sont autorisées, si votre pare-feu peut gérer les règles à des moments précis de la journée.

Je recommanderais de restreindre les utilisateurs sur vos serveurs Web, c'est-à-dire qui peut faire la mise à jour. (Vous l'avez probablement déjà fait) Ensuite, j'utiliserais les pare-feu pour restreindre les réseaux (IP) qui ont accès à l'interface de gestion. Ensuite, s'il est pris en charge, je n'autorise que les mises à jour à gérer pendant les heures de travail (via une règle de pare-feu). Notez que l'administrateur du pare-feu peut toujours modifier la règle pour une mise à jour d'urgence. Enfin, je surveillerais les vulnérabilités connues dans Web Deployment Agent et atténuerais davantage, ou le désactiverais jusqu'à ce qu'un correctif puisse être implémenté.