tls-attacker/tls-scannerEscá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
[](https://hydrogen.cloud.nds.rub.de/job/TLS-Scanner/)
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 de TLS, pentesters, administradores e investigadores. No tiene interfaz gráfica. Está en su primera versión y puede contener algunos errores.*
# Compilación
Para compilar y usar TLS-Scanner, debe ejecutar:
```bash
$ cd TLS-Scanner
$ git submodule update --init --recursive
$ mvn clean package
```
Alternativamente, si tiene prisa, puede omitir las pruebas usando:
```bash
$ mvn clean package -DskipTests=true
```
Si desea usar TLS-Scanner como biblioteca, debe instalarlo con el siguiente comando:
```bash
$ mvn clean install
```
# Ejecución
Para ejecutar TLS-Scanner debe ejecutar uno de los archivos jar en la carpeta apps/.
Estos se pueden obtener compilando la aplicación usted mismo o
[descargando los archivos jar publicados desde GitHub](https://github.com/tls-attacker/TLS-Scanner/releases).
```bash
$ java -jar apps/TLS-Server-Scanner.jar -connect localhost:4433
```
TLS-Scanner evaluará el servidor especificado (aquí `localhost` en el puerto `4433`) y, al final, imprimirá un informe.
El informe utiliza colores para transmitir la gravedad de los hallazgos:
- Verde: Un buen resultado.
- Amarillo: Una advertencia, que puede ser un problema potencial.
- Fondo amarillo: Resultados en los que el escáner no está seguro de si el objetivo es vulnerable.
- Rojo: Un problema grave, que debería corregirse.
- Color predeterminado (según su terminal, probablemente negro o blanco): Un resultado neutral, que no es ni bueno ni malo. Esto incluye resultados informativos.
- Azul: El escáner no pudo escanear el servidor para esta prueba específica. Probablemente se deba a que no se cumple un requisito previo para esta prueba.
- Púrpura: El escáner encontró un error al escanear el servidor para esta prueba específica. Esto puede deberse a un error en el escáner, pero también a que el servidor no admite una característica requerida.
- Cian: Se utiliza para estructurar el informe (encabezados, ...).
## Parámetros importantes
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 razones de rendimiento es el parámetro `-scanDetail`, que se puede usar para configurar el nivel de detalle con el que 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`.
De forma predeterminada, los resultados se escriben solo en la consola. Si desea una salida legible por máquina, puede usar `-outputFile output.json` para escribir automáticamente los resultados en un archivo JSON.
## Casos de uso
Los parámetros más importantes que se pueden cambiar son `-scanDetail` y `-reportDetail`. A continuación, explicamos algunos casos de uso para estos parámetros.
### Escaneo predeterminado
En 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`.
### Escaneo rápido
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 la extensión 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.
### Escaneo detallado
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 su posterior análisis y evaluación.
## Perfiles de escaneo
En lugar de (o además de) establecer parámetros como `-scanDetail` individualmente, puede agrupar
qué sondas ejecutar y cuáles de estos parámetros usar en un perfil de escaneo JSON reutilizable con
el parámetro `-profile <path/to/profile.json>`. Está disponible tanto en `TlsServerScanner` como en
`TlsClientScanner`.
Un perfil es un archivo JSON con:
- `inheritedFromProfiles`: rutas a otros perfiles desde los que combinar sondas, resueltas en relación con
el directorio del archivo de perfil que las declara (una ruta absoluta se usa tal cual).
- `probes`: las sondas a ejecutar, como un mapa desde el nombre completo de una clase enum `ProbeType`
a la lista de los nombres de sus constantes a ejecutar. Esto agrupa las sondas por tipo en lugar de repetir
el tipo para cada sonda individual, mientras que un único perfil aún puede combinar libremente sondas de
diferentes implementaciones de `ProbeType`, p. ej. `TlsProbeType` y `QuicProbeType`. Cada lista por tipo
también acepta `"*"` (todas las constantes de ese tipo) y `"!CONSTANT_NAME"` (eliminar una constante
previamente añadida por nombre o por `"*"`), procesadas en orden — consulte `Everything.json` y
`demo.json` en [`scan-profiles/`](https://github.com/tls-attacker/tls-scanner/blob/main/scan-profiles) para ver ejemplos.
- `settings` (opcional): anulaciones para parámetros como `-scanDetail`, `-reportDetail`,
`-postAnalysisDetail`, `-noColor`, `-outputFile`, `-probeTimeout`, `-parallelProbes` y
`-threads`. Cualquier campo omitido conserva su valor predeterminado normal (o el que se haya pasado en la línea
de comandos). **A diferencia de `probes`, los `settings` no se heredan** — solo se aplican los settings declarados directamente en
el perfil al que apunta `-profile`, incluso si hereda sondas de otros perfiles.
Solo se ejecutan las sondas resueltas desde el perfil activo (y todo lo que hereda);
todo lo demás se omite.
Ejemplo, combinando las sondas de un perfil base con las suyas y ajustando el detalle del escaneo:
`base.json`:
```json
{
"probes": {
"de.rub.nds.tlsscanner.core.constants.TlsProbeType": ["PROTOCOL_VERSION", "CIPHER_SUITE"]
}
}
```
`quic.json` (en el mismo directorio que `base.json`):
```json
{
"inheritedFromProfiles": ["base.json"],
"settings": {
"scanDetail": "QUICK"
},
"probes": {
"de.rub.nds.tlsscanner.core.constants.QuicProbeType": ["SUPPORTED_VERSIONS"]
}
}
```
```bash
$ java -jar apps/TLS-Server-Scanner.jar -connect localhost:4433 -profile quic.json
```
Esto ejecuta `PROTOCOL_VERSION`, `CIPHER_SUITE` y `SUPPORTED_VERSIONS` con `-scanDetail QUICK`.
Para ver todas las sondas disponibles para un escáner (sin conectarse a un objetivo), use `-listProbes`.
Las imprime agrupadas por clase `ProbeType` en la sintaxis JSON exacta que espera el campo `probes` de un perfil,
para que pueda copiarla y pegarla directamente en un perfil:
```bash
$ java -jar apps/TLS-Server-Scanner.jar -listProbes
{
"de.rub.nds.tlsscanner.core.constants.TlsProbeType" : [ "ALPN", "ESNI", "CERTIFICATE", ... ],
"de.rub.nds.tlsscanner.core.constants.QuicProbeType" : [ "SUPPORTED_VERSIONS", ... ]
}
```
## Todos los parámetros
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 establecido.
# Docker
Proporcionamos imágenes Docker precompiladas para un uso sencillo de TLS-Server-Scanner.
```bash
$ docker run -it --network host ghcr.io/tls-attacker/tlsscanner -connect localhost:4433
```
La imagen está hecha para usarse para el escaneo de servidores, pero también contiene los otros archivos jar.
Se puede acceder a ellos modificando el entrypoint.
```bash
$ 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:
```bash
$ docker build . -t tlsscanner
$ docker run -t tlsscanner
```
**Tenga en cuenta:** *No estoy en absoluto familiarizado con las buenas prácticas de Docker. Si sabe cómo mejorar el Dockerfile,
no dude en enviar un pull request*
# Sistema de requisitos
Las sondas (TLS) a veces tienen requisitos previos necesarios para ejecutar esa sonda específica. El sistema de requisitos le permite definir conjuntos de dichos requisitos que deben cumplirse para que la sonda se ejecute.
Cada requisito ofrece una función `evaluate` que devuelve un valor booleano que indica si el requisito se ha cumplido.
Los requisitos se pueden concatenar de varias formas usando operaciones lógicas conocidas. Cada requisito ofrece los métodos de instancia `and`, `or`, `not` y `xor`
para encadenar múltiples requisitos. Actualmente están implementadas las siguientes sondas y se pueden usar directamente:
- `FulfilledRequirement` - Siempre evalúa a `true`, útil para indicar que no hay requisito.
- `UnfulfillableRequirement` - Siempre evalúa a `false`, impide 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 puede usar `PropertyTrueRequirement` y `PropertyFalseRequirement` como abreviatura de `TestResults.TRUE` y `TestResults.FALSE`.
- `PropertyComparatorRequirement` - Evalúa a `true` si el resultado de la colección de una propiedad analizada es menor, igual o mayor que un valor constante.
- `ProtocolRequirement` - Evalúa a `true` si se admiten ciertas versiones de protocolo.
- `ExtensionRequirement` - Evalúa a `true` si el par remoto admite ciertas extensiones.
- `OptionsRequirement` - Evalúa a `true` si se establecen flags adicionales de cli. 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.
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 sobre cómo usar los requisitos en los paquetes `probe` de `tls-client-scanner` y `tls-server-scanner`.
```java
@Override
public Requirement<ClientReport> getRequirements() {
return new ProbeRequirement<ClientReport>(TlsProbeType.CIPHER_SUITE)
.and(new PropertyTrueRequirement<>(TlsAnalyzedProperty.SUPPORTS_DHE));
}
```