¿Es seguro servir HTTP / HTTPS a través de los puertos 8080/8443

Debido a una limitación de infraestructura, una de las soluciones propuestas para servir un servicio HTTP al mundo es ofrecerlo a través de los puertos 8080 y 8443.

Mi preocupación es que algunos usuarios no puedan acceder a estos servicios porque no se ejecutan en puertos estándar, y el contenido puede ser filtrado por (por ejemplo) como parte de la política de red corporativa.

Entonces ... ¿qué posibilidades hay de que un usuario de Internet en general no pueda acceder a estos servicios?

— gastador
fuente

¿No puede enviar la dirección al puerto 80 y 443?

— Froggiz

Estamos utilizando roles web y de trabajo en los servicios de Azure Cloud. Por lo que puedo decir, no es posible apuntar un segundo VIP a una máquina diferente a menos que cambiemos a máquinas virtuales de Azure. Otras opciones incluyen reemplazar todo el servidor web front-end con un proxy, pero obviamente usar diferentes puertos resolvería este problema con menos gasto.

— gastador

Quiero

— Froggiz

Me gustaría abordar una preocupación que parece faltar aquí. El hecho de que no puede usar puertos 80o 443puede sugerir que se está ejecutando en un servidor compartido. Si es así, existe la posibilidad de que otro usuario pueda unirse a esos puertos si el suyo alguna vez dejó de funcionar . Ese usuario podría hacerse pasar por su sitio web (aunque SSL podría ayudar a mitigar esto).

— Nathan Osman

@NathanOsman, creo que le preocupa el acceso de los usuarios y los firewalls de los usuarios.

— Pacerier

Respuestas:

Las redes corporativas generalmente estarán predeterminadas a reglas como esta:

deny all; allow 80; allow 443; allow 21; allow 22; etc...

Es mucho más fácil configurar de esta manera que negar explícitamente el 99% de los 65.535 puertos disponibles.

Dicho esto, me hice cargo de un portal orientado al cliente que utilizaba un puerto no estándar debido a limitaciones de red; No conozco los detalles de NAT. De todos modos, esto hizo imposible que aproximadamente el 50% de nuestros usuarios / visitantes accedan al sitio y cada vez que nos llamen para informar este problema, tendremos que coordinarnos con su TI inexistente para intentar que se implemente una regla de permiso.

No conozco los detalles de las limitaciones de su infraestructura, pero me imagino que algo más se está ejecutando en 80/443

Si este es el caso, entonces su única opción podría ser utilizar un proxy interno o actualizar el conmutador a algo con capacidades NAT más avanzadas que puedan enrutar las solicitudes de manera adecuada.

TL; DR

No utilice un puerto no estándar para servicios públicos que ya tienen un puerto estándar.

— MonoZeus
fuente

"Es mucho más fácil configurar de esta manera en lugar de negar explícitamente el 99% de los 65.535 puertos disponibles". - incluso si negaran explícitamente el 99% de los puertos, tendría el mismo efecto.

— user253751

Terminamos usando el servidor web principal para enviar solicitudes a los servicios ofrecidos en otros puertos. Debido a que los otros servicios necesitan escalar para poder de procesamiento adicional en lugar de porque alcanzan los límites de la red, y el tamaño de las solicitudes y respuestas es relativamente bajo, esta disposición funciona muy bien con el sitio web principal con equilibrio de carga que absorbe fácilmente el costo de la representación.

— gastador

@spender Me alegra saber que ustedes pudieron resolverlo sin usar puertos no estándar orientados al cliente :)

— MonkeyZeus

Es muy probable que se bloqueen, especialmente en redes corporativas o en wifi público. Menos probable en una conexión de internet doméstica normal.

Ciertamente estaría bloqueado en mi red de trabajo.

Además, las personas deberán recordar escribir el número de puerto para llegar a su sitio, lo cual es un dolor de cabeza adicional con el que no desea lidiar. Para sitios internos o privados no es un gran problema, pero si esto es para el público en general, tendrá mucho más éxito utilizando los puertos estándar.

— Conceder
fuente

Los servicios en cuestión nunca se escriben en el navegador ... más bien se señalan desde los recursos que se sirven a través de los puertos normales. Sin embargo, parece que mis preocupaciones sobre la fiabilidad de mi enfoque están bien justificadas.

— gastador

¿Puedes explicar por qué estaría bloqueado? Utilicé el puerto 800 durante mucho tiempo sin ningún problema, incluso con las herramientas de SEO de Google y las referencias ..

— Froggiz

Uno de mis trabajos es ejecutar un sitio web que indexa las transmisiones de shoutcast, y es una queja común que algunos usuarios detrás de las redes corporativas no puedan escuchar las transmisiones que se ejecutan en puertos no estándar. Sin embargo, 8080 y 8443 parecen ser un poco especiales, pero probablemente no lo suficientemente especiales. Yo diría que ejecutar un servicio en 800 es particularmente arriesgado porque se encuentra en puertos "conocidos" que tienen muchas más probabilidades de ser bloqueados.

— gastador

Una solución fácil es dejar su servidor funcionando en el puerto 8080/8443, y en el firewall, los puertos NAT / forward 80/443 a 8080/8443.

— SnakeDoc

@SnakeDoc De acuerdo, cubrí la opción proxy en mi respuesta :-)

— MonkeyZeus

No es difícil hacer que su navegador golpee, digamos http://example.com:8080/index.html , pero cuando habla de políticas corporativas que bloquean puertos no estándar, eso parece muy difícil.

Si tiene algún tipo de equilibrio de carga configurado, aún puede configurar sus aplicaciones para que se ejecuten en un puerto estándar y que el puerto del equilibrador de carga reenvíe al puerto impar internamente. Incluso si no tiene equilibrio de carga, estoy seguro de que puede encontrar una forma de reenviar puertos a un puerto interno que no sea estándar.

Internamente, los usuarios pueden acceder en un puerto extraño (si no es parte de su política corporativa para bloquear), externamente ven http://example.com .

Hay muchas maneras de hacer esto, tendrás que ser un poco creativo dependiendo de los tipos de obstáculos que encuentres. ¡Siempre es un desafío!

— Brett Salmiery
fuente