¿Por qué no debería ejecutar mi software de servidor no web en el puerto 80?

Question

Considerando que hay tantos cortafuegos draconianos en el mundo, ¿hay alguna razón por la que no deba ejecutar el software del servidor en el puerto 80 para garantizar la mayor accesibilidad posible? Parece que la excepción de cortafuegos más común es permitir conexiones de salida en el puerto 80. Entiendo que cualquier tipo de inspección de paquetes todavía bloquearía mi tráfico no HTTP, pero si ese es el caso, estoy seguro de que el cortafuegos no tendría ninguna otros puertos salientes abiertos de todos modos.

Si el servidor ya tiene un servidor web en el puerto 80 es posible el uso de algún tipo de máquina virtual que escucha en el puerto 80 (es decir, myDomain.com:80 y myApp.myDomain.com:80 en la misma máquina) ?

Answer 1

Si necesita hacer esto, ¿por qué no simplemente envuelve su código de red de comunicaciones con una interfaz SOAP o un HTTPHandler?

¿Entonces sus paquetes se ajustarán a HTTP, atravesará los firewalls y todos estarán contentos?

Será mucho más fácil que resolver todos los problemas de instalación y operaciones que obtendrá de puerto 80.

Answer 2

Para responder a la segunda pregunta "¿es posible el uso de algún tipo de máquina virtual que escucha en el puerto 80":

Sí, existe, y se llama el alojamiento virtual y están a cargo de la mayoría de los servidores web modernos. Pero entonces todas las solicitudes de su aplicación deben comenzar con el protocolo HTTP 1.1, donde se especifica un host. Su aplicación probablemente tiene que ser una aplicación CGI. Pero eso probablemente no es lo que quieres.

La otra forma es permitir que su aplicación tome control del puerto 80 y redirija todas las consultas http al servidor web. Es complicado y si su aplicación se cae, también lo hace el servidor web.

La solución es tener más de una dirección IP en su servidor (puede enlazar más de una dirección IP en un dispositivo). Luego puede vincular mydomain.com:80 en la dirección 1 al servidor web y a myapp.mydomain.com en la dirección 2 de la aplicación, pero aún están en el mismo servidor.

Y para responder a su primera pregunta: "¿Hay alguna razón por la que no debería ejecutar el software del servidor en el puerto 80": Sí, es una mala práctica. Espere obtener una gran cantidad de consultas http del escaneo automático. Puede elegir responderlas con un encabezado http correcto o ignorarlas.

Answer 3

Puedo pensar en dos razones: primero, si lo hace para evitar el firewall de una empresa, estará en violación de la política de seguridad y en segundo lugar, utilizará un reserved port para un protocolo que no está 't registrado que podría causar confusión significativa a los clientes que tratan de interactuar con su sistema (como, Google, por ejemplo) y dolores de cabeza significativos para su aplicación cuando lo hacen.

EDIT En sistemas Unix, los puertos con números bajos requieren cuentas con privilegios para ejecutarse. Esta sería otra razón para evitar hacerlo en ese entorno ya que su aplicación puede necesitar privilegios más altos que los requeridos.

Answer 4

No es posible hacer hosting virtual para otros dominios que escuchan en el puerto 80. Solo un proceso puede escuchar en un puerto. El alojamiento virtual ocurre en la capa de aplicación basada en los encabezados HTTP.

El otro problema con el que puede encontrarse son los servidores proxy. No del tipo que configura el usuario, sino proxies automáticos de compañías o ISP. Estos no entenderán el protocolo de su aplicación y probablemente fallarán.

Por último, si su aplicación se ejecuta en una variante de Unix/Linux, el puerto 80 requerirá privilegios de administrador.

Answer 5

voy a confesar que había trabajado en torno a un servidor de seguridad draconianas múltiples proponiéndose por tener un servidor ssh escuchar en el puerto 80 de vuelta a casa y usando túnel ssh para proporcionar acceso a otros servidores y servicios. Me apresuro a añadir que lo hice con la bendición de las personas que administran el cortafuegos; todos coincidimos en que era la mejor solución para los problemas que teníamos a mano.

Me apresuro a agregar que esta táctica hace que el puerto 80 sea inútil para su propósito previsto, lo que me pareció bien ya que era mi estación de trabajo personal. Si tiene una sola máquina en su dominio, sería un problema. Pero tener una máquina que podría dedicar a servir ssh desde el puerto 80 creó sin problemas de instalación u operaciones. Acabo de ejecutar /etc/init.d/apache stop y luego ejecuté sshd para escuchar el puerto 80. Entonces fui bueno para ir durante los pocos meses que necesité para hacer esto.

escáneres automáticos que vienen golpeando en el puerto 80 de mi estación de trabajo personal puede ir pasar :-)