Il servizio agente msdeploy può aprire un vettore di attacco sui nostri server?

stiamo valutando l'utilizzo del servizio Agente distribuzione Web msdeploy per le distribuzioni automatiche sui nostri server di produzione.

Una cosa che non possiamo scoprire sono i potenziali impatti sulla sicurezza.

Per prima cosa, i nostri server Web sono ovviamente protetti (dietro firewall e bilanciamento del carico), quindi solo il traffico http (s) è consentito dall'esterno.

Tuttavia, l'agente di distribuzione Web funziona integrato con IIS (l'unica cosa rivolta all'esterno), poiché è accessibile tramite http (s). Quindi temiamo che potrebbe essere potenzialmente possibile ottenere l'accesso all'agente attraverso le reti ospitate su tale IIS - e con la presente ottenere l'accesso in lettura e scrittura a tutte le nostre reti.

Quanto è sicuro msdeploy per l'utilizzo in ambienti di produzione?

Aggiornamento: il server Web di produzione esegue IIS7.

È passato un po 'di tempo da quando l'ho usato e l'ho usato solo con IIS 6 che non include la parte di gestione web. È possibile modificare l'URL e la porta di gestione remota e bloccarlo sul firewall esterno. Vedere questo: personalizzazione e protezione del servizio remoto . Il suo meccanismo di sicurezza principale sembra essere la sicurezza dell'account utente, ma come hai detto, è tutto all'interno di IIS, quindi una vulnerabilità di IIS potrebbe rendere inutili le misure di sicurezza fino a quando non viene corretto. Solo per questo motivo, esiterei a consentire l'aggiornamento dei contenuti Web da Internet, ma ciò dipende dai requisiti di sicurezza della tua organizzazione rispetto alle esigenze dello sviluppatore web.

Per evitare di esporre il servizio di distribuzione Web a Internet, è possibile effettuare le seguenti operazioni:

• far ascoltare il sito Web predefinito su un IP solo interno che non sia NAT o che faccia parte dell'intervallo IP di bilanciamento del carico
• potresti avere il sito Web di gestione predefinito in ascolto solo su localhost, quindi scrivere uno script che chiama l'eseguibile msdeploy su ciascun host per essere eseguito localmente (invece di utilizzare msdeploy per connettersi in remoto a tutti gli host da un singolo punto)
• fare in modo che il bilanciamento del carico filtri le richieste esterne che tentano di colpire l'URL di distribuzione Web (ad es. https: // server: 8081 / MSDeploy )
• disporre di un host di distribuzione designato (interno) da cui provengono tutte le distribuzioni Web e consentire a tale IP di connettersi ai server Web sull'URL di distribuzione (bloccare qualsiasi cosa non dal singolo host di distribuzione)

Se è ancora necessario disporre della funzionalità di distribuzione Web direttamente da Internet, dire se tutti i tuoi sviluppatori Web hanno lavorato in remoto (non riesco a immaginare perché ciò sia necessario direttamentecon l'uso diffuso della VPN), potresti avere un processo di distribuzione in 2 fasi in cui hai impostato una DMZ isolata con una casella IIS 7 abilitata per la distribuzione Web (separata dalla DMZ della tua Web farm) e consenti ai tuoi sviluppatori web di connettersi solo a quella DMZ da Internet per distribuire le modifiche in remoto. Quindi potresti connetterti internamente a quell'host e distribuirlo al resto dei tuoi server web dopo aver esaminato le modifiche, i test, ecc. Anche questo metodo non è privo di rischi: un utente malintenzionato potrebbe finire per compromettere la funzionalità di distribuzione Web, introducendo alcuni codice dannoso a tua insaputa e potresti introdurlo inconsapevolmente nel tuo ambiente di produzione.

Semplice risposta. SÌ, qualsiasi cosa in esecuzione su qualsiasi computer apre vettori di attacco. Si dovrebbe sempre presumere che ci siano vulnerabilità nel software. La mitigazione è un fattore chiave, limita l'accesso a reti, utenti, computer, IP, ecc. Controlla anche l'accesso fisico.

Potresti anche limitare il tempo in cui è possibile che si verifichino gli aggiornamenti, se il tuo firewall è in grado di gestire le regole da determinate ore del giorno.

Consiglio di limitare gli utenti sui server Web, ad esempio chi può eseguire l'aggiornamento. (Probabilmente l'hai già fatto) Quindi utilizzerei i firewall per limitare le reti (IP) che hanno accesso all'interfaccia di gestione. Quindi, se supportato, consentirei di gestire gli aggiornamenti solo durante l'orario di lavoro (tramite una regola firewall). Nota che l'amministratore del firewall può sempre modificare la regola per un aggiornamento di emergenza. Infine, vorrei controllare le vulnerabilità note nel Web Deployment Agent e mitigarle ulteriormente, o disabilitarlo fino a quando non sarà possibile implementare una correzione.