
Escáner automatizado de configuración de servidor y cliente TLS para pentesters e investigadores. Evalúa conjuntos de cifrado, versiones de protocolo y guías de seguridad con profundidad de escaneo personalizable y salida legible por máquina.
TLS-Scanner es una herramienta para ayudar a pentesters e investigadores de seguridad en la evaluación de configuraciones de servidores y clientes TLS.
Tenga en cuenta: TLS-Scanner es una herramienta de investigación destinada a desarrolladores TLS, pentesters, administradores e investigadores. No tiene GUI. Está en la primera versión y puede contener algunos errores.
Para compilar y usar TLS-Scanner, necesita ejecutar:
$ cd TLS-Scanner
$ git submodule update --init --recursive
$ mvn clean package
Alternativamente, si tiene prisa, puede omitir las pruebas usando:
$ mvn clean package -DskipTests=true
Si desea usar TLS-Scanner como biblioteca, debe instalarlo con el siguiente comando:
$ mvn clean install
Para ejecutar TLS-Scanner necesita ejecutar uno de los archivos jar en la carpeta apps/. Estos se pueden obtener compilando la aplicación usted mismo o descargando archivos jar publicados desde GitHub.
$ java -jar apps/TLS-Server-Scanner.jar -connect localhost:4433
Debe especificar un host que desee escanear con el parámetro -connect.
Si desea mejorar el rendimiento del escaneo, puede usar el parámetro -threads para aumentar el número de hilos utilizados.
Otro parámetro importante por cuestiones de rendimiento es el parámetro -scanDetail, que se puede usar para configurar cuán detallado desea escanear. Los valores posibles, de rápido a muy detallado, son: QUICK, NORMAL, DETAILED, ALL.
El detalle de la salida se puede configurar con el parámetro -reportDetail. Para ver más detalles sobre las Guidelines, use -reportDetail ALL.
Por defecto, los resultados se escriben solo en la consola. Si desea tener una salida legible por máquina, puede usar -outputFile output.json para escribir automáticamente los resultados en un archivo JSON.
Los parámetros más importantes a cambiar son -scanDetail y -reportDetail. A continuación, explicamos algunos casos de uso para estos parámetros.
Para la mayoría de los casos, nuestra configuración de parámetros predeterminada es suficiente. Esto realiza un escaneo con ambos niveles de detalle establecidos en NORMAL.
Si desea realizar un escaneo rápido y obtener una visión general rápida de su sistema, recomendamos usar ambos niveles de detalle establecidos en QUICK. Esto limita el alcance de algunas sondas ejecutadas para reducir el tiempo de ejecución y limita el detalle del informe para no incluir información muy detallada y técnica.
Si desea evaluar completamente su sistema y ejecutar todo lo que tenemos, recomendamos usar ambos niveles de detalle establecidos en ALL. Esto ejecuta todas las sondas existentes por completo e imprime información muy detallada para análisis y evaluación adicionales.
Para obtener información detallada sobre todos los parámetros posibles, use el parámetro -help o ejecute el jar sin ningún parámetro.
Proporcionamos imágenes Docker preconstruidas para un uso fácil del TLS-Server-Scanner.
$ docker run -it --network host ghcr.io/tls-attacker/tlsscanner -connect localhost:4433
La imagen está hecha para ser utilizada para escaneo de servidores, pero también contiene los otros archivos jar. Se pueden acceder a ellos alterando el entrypoint.
$ docker run -it --network host --entrypoint java ghcr.io/tls-attacker/tlsscanner -jar TLS-Client-Scanner.jar
También le proporcionamos un Dockerfile para construir el contenedor usted mismo:
$ docker build . -t tlsscanner
$ docker run -t tlsscanner
Tenga en cuenta: No estoy familiarizado con las mejores prácticas de Docker. Si sabe cómo mejorar el Dockerfile, no dude en enviar un pull request
Las sondas (TLS) a veces tienen requisitos previos que son necesarios para ejecutar esta sonda específica. El sistema de requisitos le permite definir conjuntos de dichos requisitos que deben cumplirse para que se ejecute la sonda.
Cada requisito ofrece una función evaluate que devuelve un valor booleano que indica si se ha cumplido el requisito. Los requisitos se pueden concatenar de varias formas utilizando operaciones lógicas conocidas. Cada requisito ofrece métodos de instancia and, or, not y xor para encadenar múltiples requisitos. Las siguientes sondas están actualmente implementadas y se pueden usar directamente:
FulfilledRequirement - Siempre evalúa a true, útil para indicar que no hay requisito.UnfulfillableRequirement - Siempre evalúa a false, evita la ejecución de sondas.ProbeRequirement - Evalúa a true si la(s) sonda(s) especificada(s) se ha(n) ejecutado.PropertyRequirement - Evalúa a true si las propiedades analizadas especificadas tienen un valor predefinido. El valor puede proporcionarse como parámetro del constructor o se pueden usar PropertyTrueRequirement y PropertyFalseRequirement como abreviatura de TestResults.TRUE y TestResults.FALSE.PropertyComparatorRequirement - Evalúa a si el resultado de la colección de una propiedad analizada es menor, igual o mayor que un valor constante.Además de estos requisitos predefinidos, también se puede extender la clase Requirement de forma anónima dentro del método getRequirements. Si no se requiere nada, puede devolver un FulfilledRequirement que siempre evalúa a true.
Se pueden encontrar ejemplos de cómo usar requisitos en los paquetes probe de tls-client-scanner y tls-server-scanner.
@Override
public Requirement<ClientReport> getRequirements() {
return new ProbeRequirement<ClientReport>(TlsProbeType.CIPHER_SUITE)
.and(new PropertyTrueRequirement<>(TlsAnalyzedProperty.SUPPORTS_DHE));
}
trueProtocolRequirement - Evalúa a true si ciertas versiones de protocolo son soportadas.ExtensionRequirement - Evalúa a true si ciertas extensiones son soportadas por el par remoto.OptionsRequirement - Evalúa a true si se establecen banderas cli adicionales. Actualmente se usa en algunas sondas de cliente (ALPN, SNI, reanudación de sesión).WorkingConfigRequirement - Evalúa a true si se ha encontrado una configuración funcional.