Exponer puertos u ocultarlos detrás del proxy

Esto depende principalmente de cómo esté haciendo el proxy. Si simplemente está utilizando mod_rewrite en Apache o Nginx para redirigir de 80 a 8090 ... entonces no hay seguridad en absoluto. Este es el equivalente de poner una nota adhesiva en la puerta de su casa diciendo "por favor use la puerta en la parte de atrás". Cualquiera puede leer el manual, e incluso si no hay nadie que se pueda pegar en la casa y encontrar la puerta trasera abierta (también puede escanear el puerto de su host).

Si necesita tener un servicio web al que solo ciertas personas puedan acceder, una de las mejores maneras de hacerlo es en lugar de hospedar el servicio en localhost o 127.0.0.1 ... esto significa que el puerto no Ser accesible fuera de la caja. Luego, para poder acceder al servicio, ssh port forward:

ssh -L 80:127.0.0.1:8090 example.com -i ~/.ssh/id_rsa

lo anterior es cómo lograr el reenvío de puerto ssh en Linux, sin embargo, también está disponible a través de herramientas como puTTY .

El uso de un túnel ssh para acceder a su servicio aumenta el nivel de seguridad al:

• cifrar la comunicación entre cliente y servidor
• servicio de protección detrás de la autenticación pubkey (o contraseña) utilizada por ssh
• no hay puerto externo para escanear

Si no desea configurar el túnel SSH, otra opción es detonación de puertos .

Un patrón bastante común es tener un proxy de servicio pesado como apache o nginx que haga todo el trabajo pesado de http y se encargue de la terminación de https (por ejemplo, maneja SSL por usted). Su aplicación se encuentra oculta detrás de eso.

Tal configuración tiene algunas ventajas:

1. Hace que su servidor de aplicaciones sea mucho más sencillo, ya que no tiene que preocuparse por el almacenamiento en caché, el cifrado SSL y un montón de detalles que apache y nginx son buenos para el manejo. Tenga en cuenta que si su servidor de aplicaciones tiene el propio SSL, un proxy que se encuentra frente a él no podrá almacenar en caché nada, por lo que, desde el punto de vista del rendimiento, tiene sentido no dejar que el servidor de aplicaciones se ocupe de SSL.
2. Dejar que apache / nginx maneje las solicitudes de los clientes primero dirigirá cualquier ataque a apache / nginx primero, y están bien probadas y protegidas contra ataques, lo que probablemente no sea cierto para su servidor de aplicaciones.
3. Apache y nginx probablemente tienen más rendimiento que su servidor de aplicaciones. Por lo tanto, puede hacer que sirvan contenido estático y al mismo tiempo hacer que se ocupen de todas las implicaciones de seguridad de permitir que un servidor acceda al sistema de archivos de su servidor. Lo más probable es que el bloqueo de apache y nginx sea más fácil que asegurarse de que su servidor de aplicaciones no tenga ningún agujero de seguridad en su código para servir archivos estáticos (este es un ejemplo específico del punto 2).

Sin embargo, solo obtiene estos beneficios de seguridad si no hace que su servidor de aplicaciones sea accesible al público. Por lo tanto, debe hacerlo solo en localhost o hacer que su firewall cierre los puertos relevantes.

Esto también significa que usar redirecciones HTTP para que apache / nginx redirija a su puerto del servidor de aplicaciones ya no funcionará (y de hecho no debería, porque usar redirecciones HTTP no ayudará a ocultar su servidor de aplicaciones). Internet público en absoluto). En su lugar, deberá configurar apache / nginx para que actúe como un proxy utilizando sus directivas de proxy.