Tráfico TCP seguro para la comunicación entre procesos

3

Tengo varios procesos que se ejecutan en un sistema que interactúan entre sí mediante TCP (por ejemplo, con el protocolo de mensajería asíncrono mediante trenzado).

process1 <=====> broker <=====> process2

Hay una instancia de servidor (agente) ejecutándose en un host de Linux, que escucha un socket TCP localhost: puerto . También hay algunos otros procesos, que se ejecutan en el mismo host, que consultan la instancia del agente utilizando el socket a través de TCP (dado por trenzado). El agente tiene acceso a un módulo de seguridad de hardware (HSM).

Actualmente estoy pensando en los aspectos de seguridad de este diseño. ¿Sería posible que un intruso, que tiene acceso físico directo al host, escuche el tráfico TCP entre los clientes y el intermediario en este host? Como a veces se transfieren datos confidenciales, quiero asegurar la comunicación entre los procesos y el intermediario en el host.

¿Cómo se puede hacer esto? Siempre existe el problema de almacenar un secreto privado. Para el intermediario no es un problema porque tiene acceso a HSM, pero para los procesos cliente que interactúan con el intermediario. Es difícil ocultar un secreto para un atacante que tiene acceso físico al host. ¿Cómo se puede realizar la autenticación / encriptación entre los procesos y el intermediario?

¡Espero que entiendas mi problema y puedas ayudarme!

EDIT: SSL / TLS no sería un buen enfoque, ya que conlleva una gran sobrecarga y también existe el problema del almacenamiento seguro para secreto privado.

    
pregunta Ovomaltine 27.12.2016 - 14:08
fuente

3 respuestas

2

Si desea restringir la comunicación entre procesos en una máquina, sugeriría eliminar TCP y, en su lugar, utilizar el socket de dominio Unix. El socket de dominio Unix se puede usar exactamente de la misma manera que TCP (es un socket bidireccional), pero crea un archivo de socket en lugar de escuchar en un puerto TCP. Puede controlar los permisos en el archivo de socket utilizando permisos de sistema de archivos estándar. Twisted admite el socket de dominio Unix.

Si realmente tiene que usar TCP, entonces puede usar SSL sin cifrado . De forma predeterminada, el cifrado eNULL y la autenticación aNULL no están permitidos en OpenSSL, pero puede solicitarlo explícitamente. Yo personalmente no recomendaría esto.

También puede tener suerte al definir regla iptable que restringe la forma en que los procesos Puede conectarse a algún puerto TCP.

Sin embargo, en general, tratar de defenderse contra alguien con acceso raíz / físico no restringido a su máquina es un esfuerzo inútil, y el cifrado para la comunicación entre procesos dentro de la misma máquina es bastante tonto, pero es bastante inofensivo.

    
respondido por el Lie Ryan 29.12.2016 - 07:01
fuente
3

También es posible escuchar en el tráfico de localhost en Windows y Linux.

En Linux tcpdump -i lo .

Debe considerar al menos la codificación con un algoritmo especial de su comunicación y también debe considerar la protección del proceso del agente para que no sea objeto de volcado, depuración o ingeniería inversa.

    
respondido por el Opaida 27.12.2016 - 16:15
fuente
2

Las comunicaciones entre estos procesos siempre pueden ser interceptadas por un atacante con acceso privilegiado al sistema.

Con acceso de raíz al cuadro, el atacante es el propietario del sistema y puede eludir todo lo que implementes (en su mayor parte). ¿Tráfico cifrado? Las funciones que procesan las claves de cifrado se pueden enganchar o la memoria del proceso se puede volcar. La ingeniería anti-reversa es una posibilidad, pero siempre puede ser burlada por alguien lo suficientemente experto. La forma más efectiva y segura de hacer esto sería escribir un LKM que haga cumplir la seguridad de sus procesos en el nivel del kernel; esto requiere una gran experiencia en la programación del kernel y es extremadamente difícil de hacer correctamente (¡¿me atrevo a decir que es imposible ?!) - alguien siempre encontrará una laguna, aunque es algo a considerar.

Además, los usuarios que no son root no pueden crear sockets sin formato, que son necesarios para detectar paquetes (lo que significa que un atacante necesitará acceso de root a su sistema para interceptar las comunicaciones entre sus procesos).

Asegurar la información sobre un sistema de un atacante que ya lo posee no es una tarea trivial. Puede hacer que sea más difícil acceder a dicha información, pero nunca puede protegerla por completo.

    
respondido por el Hello 29.12.2016 - 02:31
fuente

Lea otras preguntas en las etiquetas