Compartir a través de

Restricciones de IP en Azure App Service como comportamiento esperado (es-MX)

  • Artículo

Artículo Original: https://blogs.msdn.microsoft.com/benjaminperkins/2018/07/19/ip-restrictions-on-azure-app-service-as-expected-behavior/

No se proporciona un método para cerrar al 100% el punto final público de un Servicio de aplicaciones que se ejecuta en el tenant público. Sin embargo, puede crear un ILB ASE (que no es un tenant  público) o puede restringir el acceso utilizando una Restricción de IP. Aquí hay información sobre la función detallada para configurar esto en IIS y en el archivo web.config. Si desea hacer lo mismo en un servicio de aplicaciones de Azure, entonces verifique esto.

Un comportamiento interesante que quería documentar se refiere a lo que sucede cuando ha realizado alguna configuración en el portal para su Servicio de aplicaciones, pero también ha agregado algunas configuraciones 'complementarias' en el archivo web.config para la aplicación que se ejecuta en la plataforma ...

Como se ve en la Figura 1, creé una Restricción de IP que permite que solo un cliente con una dirección IP de 10.0.0.1 acceda al Servicio de aplicaciones. Sabía que este no era el IP de mi cliente, así que fue bueno para probarlo.

https://msdnshared.blob.core.windows.net/media/2018/07/image_thumb80.png

Figura 1, Restricciones de IP no se aplican, no funcionan

Una vez aplicado, cuando accedímos a la  aplicación, recibimos lo siguiente:

*"No tienes permiso para ver este directorio o página."
*
Esto se debe a que denyAction predeterminado está configurado como Prohibido y devuelve 403.503

Pero, si modificamos el  archivo web.config

<ipSecurity allowUnlisted="true" />

A continuación, la configuración en el archivo web.config anula la configuración en el portal y ahora puedo acceder a mi Servicio de aplicaciones independientemente de la configuración del portal.

Una cosa genial fue que en lugar de aceptar el denyAction predeterminado, se puede configurar en el web.config para que se devuelva un estado diferente al cliente.

<ipSecurity allowUnlisted="false" denyAction="NotFound" />

Al agregar esa configuración a web.config, se devuelve lo siguiente, junto con un 404.503

"El recurso que está buscando se ha eliminado, se ha cambiado su nombre o no está disponible temporalmente."

Confirmamos también que tenemos esta configuración, es decir el cambio a denyAction no anula las IP a las que se permite el acceso, consulte la Figura 2. Después de agregar la dirección IP del cliente, se puede acceder incluso después de personalizar denyAction en web.config.

https://msdnshared.blob.core.windows.net/media/2018/07/image_thumb81.png

Figura 2, Restricciones de IP no aplicadas, no funciona

Lo que conduce a un posible malentendido. Supongamos que tenemos una configuración en el  archivo web.config como la siguiente que permite la dirección IP del cliente.

<ipSecurity allowUnlisted="false" denyAction="NotFound"> <add ipAddress="###.220.196.###" /> </ipSecurity>

Se puede obtener una combinación de comportamientos según las direcciones IP ingresadas a través del portal y las direcciones IP configuradas en web.config. La recomendación es usar el portal. Al mismo tiempo, mi experiencia fue positiva de que el cambio de denyAction no tuvo un impacto negativo.

TIP # 1:
Puede obtener la configuración de IP que creó en el portal a través del Azure Resource Explorer aquí. Navegue a la siguiente URL:

https://management.azure.com/subscriptions/"1"/resourceGroups/"2"/providers/Microsoft.Web/ sites/"3"/config?api-version=2016-08-01

Donde 1 = subscriptionID, 2 = nombre del grupo de recursos y 3 = el nombre del servicio de aplicaciones. Vería un resultado similar como se ve en la Figura 3.

https://msdnshared.blob.core.windows.net/media/2018/07/image_thumb82.png

Figura 3, viendo las configuraciones de restricciones de IP en el explorador de recursos

TIP # 2:

Puede aprender mucho sobre IIS y la canalización de ASP.NET a través del seguimiento de solicitudes fallidas. Menciono cómo habilitar eso aquí "Habilitar seguimiento de solicitud fallido para una aplicación web de Azure App Service". Sin embargo, como se ve en la Figura 4, pude encontrar rápidamente la dirección IP de mi cliente, el estado y el código de subestado plus, ver que efectivamente fue el IpRestrictionModule el que se aplicó para solicitar restricción en la solicitud.

https://msdnshared.blob.core.windows.net/media/2018/07/image_thumb83.png

Figura 4 Restricciones de IP no se aplican, no funcionan