¿Se debe cifrar el tráfico entre dos hosts en el mismo centro de datos?

5

Tenemos dos hosts, teóricamente en el mismo centro de datos. Las dos máquinas están alojadas en Online.net. Estamos teniendo un pequeño debate: si el tráfico entre los dos hosts está cifrado.

El tráfico que necesitamos para intercambiar son consultas de Redis. Los datos que se intercambiarán son los ID de usuario de Twitter y Facebook, un código para indicar el trabajo que se debe realizar y un ID de mercado, que en sí mismo es un UUID. Una consulta y respuesta típica sería:

> hgetall Twitter:12345
1) 1) "c4a9c7f0-78d1-0132-b14c-70921c10876c"
   2) "F"

Las dos implementaciones en las que estamos pensando:

  1. Use un túnel SSH con reenvío de puertos para ocultar el servidor Redis de la Internet pública. En la máquina que aloja el servidor de Redis, cree un usuario independiente con una sola tecla de auror, con los valores adecuados para no permitir la ejecución de programas arbitrarios;

  2. Simplemente use el firewall para limitar el tráfico a Redis a la única dirección IP que necesitamos, nada más.

No estamos seguros de cuál sería "más seguro" (o más apropiadamente, menos riesgoso). Agregar usuarios y configurar SSH introduce complejidad, mientras que agregar una regla de firewall es mucho más simple. Por otro lado, si un atacante lee paquetes en vuelo, ¿qué datos útiles pueden recopilar?

De lo que quiero protegerme es después de haber obtenido acceso a la máquina cliente, un atacante podría posicionarse en la máquina del servidor Redis, que alberga muchos más servicios.

    
pregunta François Beausoleil 13.07.2015 - 16:48
fuente

3 respuestas

1

Diría que una ACL explícita en el Firewall que permita el tráfico hacia y desde los dispositivos en cuestión debería estar bien en esta instancia.

¿Parece que la información que se intercambia es solo una ID de usuario? Si este es el caso y la información no es necesariamente confidencial, no veo un problema con solo asegurar que las reglas estén en su lugar para permitir el tráfico.

    
respondido por el shift_tab 13.07.2015 - 19:36
fuente
3

Si las máquinas estuvieran en su propia red (en casa, el centro de datos de su empresa, etc.), una simple restricción basada en IP y / o poner las máquinas relacionadas con Redis en una VLAN separada debería ser suficiente.

Sin embargo, en el caso de un proveedor de alojamiento, recomiendo considerar sus redes como hostiles y equivalentes a la Internet abierta, en cuyo caso debe crear su propia red interna usando IPSec entre sus máquinas, y pasar el tráfico sin cifrar que desee a través de que.

No protegerá contra el hecho de que la empresa de alojamiento no esté en tu contra, pero al menos el atacante tendrá que hacer mucho más (análisis de memoria que requiere un hipervisor o acceso físico) para obtener las claves IPSec y dar sentido a tu datos que la captura de paquetes pasiva que es realmente fácil

    
respondido por el Anonymous 13.07.2015 - 20:58
fuente
1

Facebook terminó trabajando para encriptar todos los datos dentro de sus propios centros de datos privados.

El tráfico cifrado proporciona una sobrecarga ... algo pequeño en el rendimiento de la CPU si se hace correctamente, pero algo no trivial en el tiempo administrativo para descubrir cómo configurarlo sin problemas. Recomendaría una opción que no haya enumerado: SSL con agrupación de conexiones y Perfect Forward Secrecy. La mayor parte de la sobrecarga en SSL está dentro del protocolo de enlace asimétrico inicial, por lo que la agrupación ayuda al rendimiento. PFS significa que si las claves de host se comprometen en una fecha posterior, una transmisión encriptada grabada no tendrá valor.

Eso significa que las escuchas ilegales incluso a través de un toque de red serían esencialmente inútiles para un atacante si tiene un buen control de certificados.

    
respondido por el Jeff Ferland 13.07.2015 - 21:54
fuente

Lea otras preguntas en las etiquetas