es NetNamedPipeBinding seguro?

Question

me gustaría saber si netNamedPipeBinding es considerado seguro:

Por un lado NetNamedPipeBinding implementa la seguridad sólo en la capa de transporte y utiliza NTLM (source) que ya no es recomendado por Microsoft (source)

En por otro lado, no se puede acceder a Named Pipie desde una computadora remota, y no hay forma de escuchar a escondidas una instancia particular de tubería abierta que se usa para transferir datos o escribir datos en ella, a menos que se pueda obtener el manejador de la instancia específica involucrada. .

Esta es la razón por la cual no sé qué pensar acerca de la seguridad de esta solución.

Answer 1

No hace realmente la pregunta correcta: no es posible dar una respuesta booleana válida en cualquier circunstancia. Siempre debe evaluar la seguridad de una solución en su conjunto, identificar las amenazas y modelar los riesgos de seguridad asociados.

Dicho esto, es cierto que el WCF NetNamedPipeBinding tiene características de seguridad que hace que sea un poco diferente de las consolidaciones basadas en protocolos de red:

• En comparación con cualquier protocolo de red, la NetNamedPipeBinding es inherentemente mucho más segura contra amenazas a la comunicación sobre la conexión de transporte. En lugar de bytes transmitidos a través de una red, en el caso de canalizaciones con nombre, los mensajes se intercambian a través de un mecanismo que implica pasar bytes de datos (a través de las API del sistema operativo) hacia y desde la memoria administrada por el núcleo del sistema operativo en una sola máquina. La transmisión de mensajes no puede ser escuchada excepto por un atacante que ya tiene un código privilegiado en modo kernel (y si ya tiene un atacante dentro de las bragas de su sistema operativo, probablemente ya pueda hacer lo que quiera con su proceso de solicitud)) En consecuencia, el WCF "Seguridad de transporte" is more or less irrelevant to the security of the message stream and should arguably often be disabled in configuration to avoid unnecessary runtime overhead.
• El mecanismo utilizado por el enlace de canalización para publicar puntos finales de servicio a clientes potenciales también es inherentemente más seguro que los protocolos basados ​​en red: se basa en un objeto de memoria compartida y es imposible acceder desde cualquier equipo remoto.
• El conducto con nombre utilizado para el intercambio de mensajes se denomina con un GUID que cambia cada vez que se reinicia el servidor, y está protegido por una ACL que impide que cualquier usuario remoto lo abra, incluso si pudieron descubrir el GUID actual de alguna manera el nombre de la tubería

Por otro lado, se basa en una instalación de sistema operativo accede a través de una API, en lugar de en las normas públicas de comunicación en la red, hay algunas vulnerabilidades de seguridad específicas que no se deriven para los enlaces basados ​​en la red:

• Ataques de servidor "en cuclillas", donde algunos procesos que no sean el servidor de servicio WCF previsto logran escuchar en el conducto con nombre. El enlace de canalización con nombre en .NET 3.5 y anteriores no era seguro contra esta vulnerabilidad debido a un error en la ACL creada por el enlace para asegurar el conducto. .NET 4 corrigió principalmente este error.
• Los conductos con nombre en Windows tienen un mecanismo integrado para admitir servidores de pipa nombrados que se hacen pasar por sus clientes. WCF NetNamedPipeBinding contiene un error que en algunos casos permite que el servidor de tuberías (es decir, el servicio WCF) utilice las credenciales de Windows del cliente para dicha suplantación, incluso si el enlace WCF del lado del cliente está configurado para no permitir la suplantación.

En resumen, debe evaluar la seguridad general de su aplicación/sistema a la luz de las amenazas que le preocupan, teniendo en cuenta las características particulares de los diversos enlaces que podría considerar. NetNamedPipeBinding a menudo será la mejor opción para escenarios de la misma máquina.