Kann der msdeploy-Agentendienst einen Angriffsvektor auf unseren Servern eröffnen?

Wir evaluieren die Verwendung des msdeploy Web Deployment Agent-Dienstes für die automatische Bereitstellung auf unseren Produktionsservern.

Eine Sache, die wir nicht herausfinden können, sind mögliche Sicherheitsauswirkungen.

Zum einen sind unsere Webserver natürlich gesichert (hinter Firewalls und Load Balancern), sodass nur HTTP-Datenverkehr von außen zulässig ist.

Der Web Deployment Agent wird jedoch in IIS integriert ausgeführt (das Einzige, was nach außen gerichtet ist), da er über http (s) zugänglich ist. Aus diesem Grund befürchten wir, dass der Zugriff auf den Agenten möglicherweise über die auf diesem IIS gehosteten Websites möglich sein könnte - und damit Lese- und Schreibzugriff auf alle unsere Websites.

Wie sicher ist msdeploy für den Einsatz in Produktionsumgebungen?

Update: Auf dem Produktionswebserver wird IIS7 ausgeführt.

Es ist schon eine Weile her, dass ich es verwendet habe, und ich habe es nur mit IIS 6 verwendet, das den Webverwaltungsteil nicht enthält. Sie können die URL und den Port der Remoteverwaltung ändern und an der externen Firewall blockieren. Siehe hierzu: Anpassen und Sichern des Remote-Service . Der Hauptsicherheitsmechanismus scheint die Sicherheit des Benutzerkontos zu sein, aber wie Sie sagten, ist alles in IIS enthalten, sodass eine IIS-Sicherheitsanfälligkeit die Sicherheitsmaßnahmen unbrauchbar machen kann, bis sie gepatcht werden. Allein aus diesem Grund würde ich zögern, die Aktualisierung von Webinhalten aus dem Internet zuzulassen. Dies hängt jedoch von den Sicherheitsanforderungen Ihrer Organisation und den Anforderungen Ihres Webentwicklers ab.

Gehen Sie folgendermaßen vor, um zu vermeiden, dass der Webbereitstellungsdienst dem Internet ausgesetzt wird:

• Lassen Sie die Standardwebsite eine interne IP überwachen, die nicht NATed ist oder Teil des IP-Bereichs für den Lastenausgleich ist
• Die Standardverwaltungswebsite kann nur localhost überwachen und dann ein Skript schreiben, das die ausführbare Datei von msdeploy auf jedem Host aufruft, um sie lokal auszuführen (anstatt msdeploy zu verwenden, um von einem einzigen Punkt aus eine Remoteverbindung mit allen Hosts herzustellen).
• Lassen Sie Ihren Load Balancer externe Anforderungen filtern, die versuchen, die URL für die Webbereitstellung zu ermitteln (z. B. https: // server: 8081 / MSDeploy ).
• über einen festgelegten (internen) Bereitstellungshost verfügen, von dem alle Ihre Webbereitstellungen stammen, und dieser IP-Adresse nur über die Bereitstellungs-URL erlauben, eine Verbindung zu Ihren Webservern herzustellen (alles blockieren, was nicht vom einzelnen Bereitstellungshost stammt)

Wenn weiterhin Webbereitstellungsfunktionen direkt aus dem Internet verfügbar sein müssen, sagen Sie, ob alle Ihre Webentwickler remote gearbeitet haben (ich kann mir nicht vorstellen, warum dies direkt erforderlich ist)Mit der weit verbreiteten Verwendung von VPN könnten Sie einen zweistufigen Bereitstellungsprozess durchführen, bei dem Sie eine isolierte DMZ mit einem für Web Deploy aktivierten IIS 7-Feld einrichten (getrennt von der DMZ Ihrer Webfarm) und dies Ihren Webentwicklern ermöglichen Stellen Sie über das Internet nur eine Verbindung zu dieser DMZ her, um Änderungen remote bereitzustellen. Anschließend können Sie eine interne Verbindung zu diesem Host herstellen und auf den restlichen Webservern bereitstellen, nachdem Sie die Änderungen, Tests usw. überprüft haben. Auch diese Methode ist nicht ohne Risiko. Ein böswilliger Benutzer kann möglicherweise die Funktionen der Webbereitstellung beeinträchtigen und einige davon einführen bösartiger Code ohne Ihr Wissen und Sie könnten ihn unwissentlich in Ihre Produktionsumgebung einführen.

Einfache Antwort. JA, alles, was auf einem Computer ausgeführt wird, öffnet Angriffsvektoren. Es ist immer davon auszugehen, dass Software Schwachstellen aufweist. Schadensbegrenzung ist ein Schlüsselfaktor, der den Zugriff auf Netzwerke, Benutzer, Computer, IPs usw. einschränkt. Überprüfen Sie auch den physischen Zugriff.

Sie können auch die Zeit einschränken, zu der Aktualisierungen durchgeführt werden dürfen, wenn Ihre Firewall Regeln für bestimmte Tageszeiten verarbeiten kann.

Ich würde empfehlen, Benutzer auf Ihren Webservern einzuschränken, z. B. wer das Update durchführen kann. (Sie haben dies wahrscheinlich bereits getan.) Dann würde ich mithilfe der Firewalls einschränken, welche Netzwerke (IPs) Zugriff auf die Verwaltungsschnittstelle haben. Wenn dies unterstützt wird, erlaube ich Updates nur während der Arbeitszeit (über eine Firewall-Regel). Beachten Sie, dass der Firewall-Administrator die Regel für ein Notfall-Update jederzeit bearbeiten kann. Schließlich würde ich nach bekannten Schwachstellen im Web Deployment Agent suchen und diese abschwächen oder deaktivieren, bis ein Fix implementiert werden kann.