Ignorando los directorios .svn en IIS

Somos una organización de desarrollo web y recientemente hemos pasado a usar la subversión para nuestro sistema de control de versiones. Dado que ejecutar una actualización es mucho más rápido que exportar y copiar sobre los archivos, los desarrolladores quieren que el servidor de producción sea una copia de trabajo.

La única preocupación que tengo con esto es con todos los archivos .svn esparcidos por todo el sistema, y ​​el hecho de que alguna persona empresarial podría, potencialmente, leer el contenido de los archivos allí, posiblemente dándoles información que preferiríamos que no tuvieran. .

¿Cuál es la forma mejor / más fácil de evitar que IIS sirva contenido desde esos directorios .svn?

"No lo hagas así" no responde la pregunta.

Prácticamente, me gusta tener una copia de trabajo en el servidor de producción, porque de esa manera puedo hacer cambios rápidos en la producción (¿quién nunca ha hecho eso?) Y volver a registrarlos. Depende de dónde desee su control deslizante de seguridad / conveniencia, y En muchos casos este es un buen lugar.

La solución estándar en Apacheland es dejar los archivos .svn allí pero decirle al servidor web que nunca los sirva. Aquí se explica cómo hacerlo con IIS 5-7 en Windows 2000-2008.

1. Descargue e instale ISAPI_Rewrite : la versión Lite será suficiente para este propósito. Tenga en cuenta los requisitos adicionales del sistema para Win 2008. Advertencia : el instalador de MSI se detiene e inicia IIS.

2. Desactive la casilla "solo lectura" en las propiedades del archivo httpd.ini . Si usó el instalador MSI, hay un acceso directo al archivo httpd.ini en el menú Inicio en Helicon-> ISAPI_Rewrite

3. Agregue estas líneas a httpd.ini :

Directivas ISAPI_Rewrite en httpd.ini :

# Deny access to Subversion working copy administrative
#  directories (.svn) and their contents
RewriteRule .*/\.svn\b.* . [F,I,O]

Ahora, cualquier solicitud de un directorio .svn o su contenido dará como resultado un 404 No encontrado del servidor.

Puede asegurarse de que cualquier cuenta de usuario utilizada por IIS no tenga derechos para acceder a los directorios .svn.

Puede hacer esto manualmente (no recomendado) o usar algo como el script de eliminación de MrJangles, ya sea que se active para ejecutarse después de realizar la actualización de SVN o que se ejecute regularmente como una tarea programada:

for /r YOURPATH %f in (.svn) do icacls /deny <name_of_iis_user>:F "%f"

(nota: no he probado lo anterior, deberá comprobar que hace lo que está intentando antes de confiar en la producción, consulte la salida de "icacls / help" para obtener más información)

(otra nota: "icacls" es un comando Vista / 2008, en versiones anteriores de Windows el comando es "cacls" en su lugar)

Con IIS 7, abra el Administrador de IIS, seleccione el nodo del servidor, haga doble clic en la función Asignaciones de controladores . Haga clic en la acción Agregar controlador administrado y configure el controlador de la siguiente manera:

• Ruta de solicitud: * .svn / * (asignación de comodines para todos los archivos en todas las carpetas .svn)
• Tipo: System.Web.HttpForbiddenHandler
• Nombre: Subversion-metadata (puede elegir un nombre diferente si lo desea)

Ahora, cualquier solicitud de archivos en las carpetas de metadatos de Subversion llamada .svn en todos los sitios debería devolver esto:

Error del servidor en la aplicación '/'.

Este tipo de página no se sirve.

Descripción: el tipo de página que ha solicitado no se sirve porque ha sido explícitamente prohibido. Revise la URL a continuación y asegúrese de que esté escrita correctamente.

URL solicitada: /.svn/text-base/Default.aspx.svn-base

Puede elegir un tipo de controlador diferente si lo desea, tal vez un controlador FileNotFound que devolverá un código de estado 404.

Para IIS 6 (con ASP.NET 2 instalado y configurado):

Vaya a Directorio de inicio> Configuración> Asignación y asigne la .svn-baseextensión a %SystemRoot%\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll. Luego, en machine.config (que puede encontrar %SystemRoot%\Microsoft.NET\Framework\v2.0.50727\CONFIG) puede agregar el mismo controlador que el anterior para la extensión, agregue el siguiente elemento XML como elemento secundario del <httpHandlers>elemento:

<add verb="*" path="*.svn-base" type="System.Web.HttpForbiddenHandler"/>

Esto solo evitará que los visitantes soliciten los archivos de código fuente, aún podrían solicitar otros archivos de las carpetas .svn. Asigne más extensiones a aspnet_isapi.dll o realice una asignación de comodines (afectará el rendimiento) y podría bloquear la solicitud de más archivos.

Desde un punto de vista de seguridad pura, volvería a educar a sus desarrolladores.

La facilidad de implementación no es necesariamente una buena idea si sacrifica la seguridad.

Está planeando una configuración para bloquear el acceso a información confidencial. ¿Qué sucede si la configuración cambia accidentalmente? ¿Qué sucede si un hotfix de IIS se cae y cambia cómo funciona su configuración? ¿Qué sucede si la biblioteca de terceros que usa falla y deja de funcionar? Puedo pensar en varios eventos extremadamente probables que romperían su configuración y permitirían el acceso a estos archivos, que se TOTALIZARÍAN TOTALMENTE al no tener los archivos en el servidor en primer lugar.

Debe crear una secuencia de comandos de implementación que copie los archivos apropiados de un servidor intermedio. Incluso podría realizar una etapa a través de SVN a un directorio diferente en Prod.

Para implementar, puede usar RoboCopy y el comando / XD para excluir directorios .svn. Puede usar la herramienta de implementación web de Microsoft y limitar los directorios con eso. Puede implementar y ejecutar lo anterior for /r YOURPATH %f in (.svn) do rd /s /q "%f"si lo necesita también.

Simplemente no implemente estos directorios en el sitio web de producción.

No uses subversión. Seriamente.

Según sus comentarios, parece que está utilizando la herramienta incorrecta para el trabajo. Subversion es una gran herramienta para sus desarrolladores, pero no es una herramienta de implementación / reflejo. Si su objetivo es simplemente copiar archivos de su servidor de ensayo / prueba a su servidor de producción con un mínimo de ancho de banda y tiempo, le sugiero que use rsync . Ahora, como soy un administrador de Unix, puede haber algún equivalente de Windows a rsync que no conozco, por lo que es posible que desee investigar un poco. Sin embargo, puede usar rsync en Cygwin o cwrsync .

Rsync le permite duplicar directorios en un servidor con directorios en otro. Calcula un delta entre los dos servidores y solo copia las diferencias. No solo eso, sino que comprime el delta y, opcionalmente, también puede cifrarlo.

La mejor práctica sería un sistema de implementación automática que exporta y publica después de que se realiza una actualización de SVN. Considere Hudson por ejemplo. Hay pocos más, pero como no necesitamos uno, no estoy muy bien informado

Greetz, GHad

Planifico un script en mis servidores de producción que busca .svn y simplemente elimina los archivos. No creo que esto funcione en tu caso.

for /r YOURPATH %f in (.svn) do rd /s /q "%f"

Si eliminar los archivos no es una opción, puede poner seguridad básica en los directorios a través de IIS (contraseña o restricciones de IP). Esto evitaría que IIS sirva contenido a usuarios no autorizados.

¡Buena suerte!