¿PCI-DSS requiere que el cliente telnet se desinstale de un servidor?

2

A menudo (no siempre) veo con las evaluaciones de vulnerabilidad de PCI de mis clientes que el cliente telnet que se está instalando aparece marcado, tanto para servidores basados en Windows como en Linux.

Entiendo por qué se marcaría un servidor de telnet pero el cliente se instala pero no se usa para las comunicaciones reales basadas en telnet. No veo por qué lo marcarían.

Para la solución de problemas de conectividad de red, hay otras herramientas de terceros que puede usar, pero cuando tiene usuarios remotos que realizan la solución de problemas en un entorno sin un conjunto estándar de herramientas instaladas, a veces esto puede salvarles la vida. Solo he tenido este artículo en mi lista por un tiempo y me gustaría obtener alguna entrada / perspectiva externa.

Editar: para aclarar esto se entiende en el contexto del uso del cliente telnet como una herramienta de solución de problemas para verificar el acceso a los puertos, no para usar realmente el protocolo telnet. Existen "mejores" herramientas para esto, pero como se indicó anteriormente, a menudo puede terminar en una situación en la que usar una verificación rápida de telnet puede darle la información que necesita en lugar de tomarse el tiempo para descargar una utilidad de terceros más pesada. Un servidor "OpenSSH" no es un sustituto adecuado para este caso de uso.

    
pregunta Bobby 21.07.2016 - 09:19
fuente

2 respuestas

1

No veo por qué querría un programa / protocolo inseguro como telnet cuando es fácil emplear una alternativa segura en forma de un servidor SSH abierto.

Telnet se ha usado a menudo para comprometer un sistema incluso cuando los operadores de red normales no lo usaron. Simplemente no hay manera de asegurar una sesión de telnet.

Dado que el cliente telnet de Windows se puede usar a través del sistema COM, incluso se ha usado para crear devoluciones de llamadas remotas a un servidor de atacantes. (p. ej., facilitar que alguien realmente haga algo con un host comprometido) Solo cuando se elimina por completo, se mitiga el riesgo.

Actualización:

  

Editar: para aclarar esto se entiende en el contexto del uso del cliente telnet como una herramienta de solución de problemas para verificar el acceso a los puertos, no para usar realmente el protocolo telnet. Existen "mejores" herramientas para esto, pero como se indicó anteriormente, a menudo puede terminar en una situación en la que usar una verificación rápida de telnet puede darle la información que necesita en lugar de tomarse el tiempo para descargar una utilidad de terceros más pesada. Un servidor "OpenSSH" no es un sustituto adecuado para este caso de uso.

Para este caso de uso, una herramienta cUrl sería suficiente. ya que puede obtener todos los detalles (a diferencia de algunos con telnet) y es incluso más ligero que telnet sin los elementos COM adjuntos que admite telnet (sí, tiene la biblioteca, pero eso es lo suficientemente pequeño como para poner un exploit y está ahí para no es una barrera para los atacantes).

El OpenSSH reemplazaría toda la funcionalidad de telnet como herramienta de administración (y acceso remoto), y reemplazaría esto con un alternativa segura

    
respondido por el LvB 21.07.2016 - 12:38
fuente
0

No creo que el PCI DSS prohíba el cliente Telnet, pero puedo ver cómo un ASV podría interpretar 2.3.b según se indique:

  

2.3.b Revise los servicios y los archivos de parámetros en los sistemas para determinar si Telnet y otros comandos de inicio de sesión no seguros no están disponibles para   acceso sin consola.

Por un lado, dice que "... los comandos de inicio de sesión remoto inseguros no están disponibles para el acceso sin consola". El uso de comando en lugar de servicio , daemon , o oyente en esta oración podría leerse fácilmente como que implica que Telnet software de cliente no debe estar disponible.

Por otra parte, cuando dice "Revisar servicios y archivos de parámetros , implica claramente que está enfocado en asegurarse de que el servicio no esté configurado para ejecutarse y escuchar las conexiones: el cliente Telnet está no es un servicio e interpreto que archivos de parámetros significa cosas como inetd.conf , no .telnetrc .

Personalmente, encuentro que Telnet está en desuso cada vez más por defecto ... Windows 7 y RHEL 6 no lo instalan. Francamente, me parece más preocupante que las distribuciones de Linux estén comenzando a instalar nc de forma predeterminada (RHEL lo tiene como una dependencia para algún programa estúpido u otro).

Y estoy de acuerdo con usted en que Telnet es una herramienta útil de depuración rápida y sucia. Cuando necesita determinar si los firewalls o enrutamiento están confundiendo una de sus conexiones, y solo quieren ver qué sucede, telnet está bien y es mejor que hacer que nc o nmap estén disponibles. (Y no estoy de acuerdo con @LvB en que las herramientas específicas del protocolo se quedan cortas cuando se utilizan protocolos no comunes: bases de datos, protocolos propietarios, etc.)

Al final, puedes hacer retroceder tu ASV, pedirles que citen su razonamiento y luego (si es como lo supuse anteriormente) discutir con ellos al respecto. Para un punto tan trivial, puedes ganar sin siquiera tener que luchar mucho.

    
respondido por el gowenfawr 21.07.2016 - 14:37
fuente

Lea otras preguntas en las etiquetas