tls-attacker/tls-scannerАвтоматизированный сканер конфигураций TLS-серверов и клиентов для пентестеров и исследователей. Оценивает наборы шифров, версии протоколов и рекомендации по безопасности с настраиваемой глубиной сканирования и машинно-читаемым выводом.
# TLS-Scanner
[](https://hydrogen.cloud.nds.rub.de/job/TLS-Scanner/)
TLS-Scanner — это инструмент, помогающий пентестерам и исследователям безопасности в оценке конфигураций TLS-серверов и клиентов.
**Обратите внимание:** *TLS-Scanner — это исследовательский инструмент, предназначенный для разработчиков TLS, пентестеров, администраторов и исследователей. Графический интерфейс отсутствует. Это первая версия, и она может содержать некоторые ошибки.*
# Компиляция
Чтобы скомпилировать и использовать TLS-Scanner, необходимо выполнить:
```bash
$ cd TLS-Scanner
$ git submodule update --init --recursive
$ mvn clean package
```
Либо, если вы торопитесь, можно пропустить тесты, используя:
```bash
$ mvn clean package -DskipTests=true
```
Если вы хотите использовать TLS-Scanner как библиотеку, необходимо установить её следующей командой:
```bash
$ mvn clean install
```
# Запуск
Чтобы запустить TLS-Scanner, необходимо запустить один из jar-файлов в папке apps/.
Их можно получить, скомпилировав приложение самостоятельно или
[скачав выпущенные jar-файлы с GitHub](https://github.com/tls-attacker/TLS-Scanner/releases).
```bash
$ java -jar apps/TLS-Server-Scanner.jar -connect localhost:4433
```
TLS-Scanner проанализирует указанный сервер (здесь `localhost` на порту `4433`) и в конце выведет отчёт.
В отчёте используются цвета для передачи серьёзности обнаруженных проблем:
- Зелёный: хороший результат.
- Жёлтый: предупреждение, которое может быть потенциальной проблемой.
- Жёлтый фон: результаты, в которых сканер не уверен, уязвима ли цель.
- Красный: серьёзная проблема, которую следует исправить.
- Цвет по умолчанию (в зависимости от вашего терминала, вероятно, чёрный или белый): нейтральный результат, который не является ни хорошим, ни плохим. Сюда входят информационные результаты.
- Синий: сканер не смог просканировать сервер для этого конкретного теста. Вероятно, это связано с тем, что предварительное условие для этого теста не поддерживается.
- Фиолетовый: сканер столкнулся с ошибкой при сканировании сервера для этого конкретного теста. Это может быть результатом ошибки в сканере, но также и из-за того, что сервер не поддерживает требуемую функцию.
- Голубой: используется для структурирования отчёта (заголовки, ...).
## Важные параметры
Необходимо указать хост, который вы хотите просканировать, с помощью параметра -connect.
Если вы хотите улучшить производительность сканирования, можно использовать параметр `-threads`, чтобы увеличить количество используемых потоков.
Ещё один важный параметр по причинам производительности — `-scanDetail`, который можно использовать для настройки детализации сканирования. Возможные значения от быстрого до очень детального: QUICK, NORMAL, DETAILED, ALL.
Детализацию вывода можно настроить с помощью параметра `-reportDetail`. Чтобы увидеть больше деталей о Guidelines, используйте `-reportDetail ALL`.
По умолчанию результаты выводятся только в консоль. Если вам нужен машиночитаемый вывод, можно использовать `-outputFile output.json`, чтобы автоматически записать результаты в JSON-файл.
## Сценарии использования
Наиболее важные параметры для изменения — `-scanDetail` и `-reportDetail`. Ниже мы объясним некоторые сценарии использования этих параметров.
### Сканирование по умолчанию
В большинстве случаев наших настроек параметров по умолчанию достаточно. Это выполняет сканирование с обоими уровнями детализации, установленными в `NORMAL`.
### Быстрое сканирование
Если вы хотите выполнить быстрое сканирование и получить быстрый обзор вашей системы, мы рекомендуем установить оба уровня детализации в `QUICK`. Это ограничивает объём некоторых выполняемых проверок для снижения времени выполнения и ограничивает детализацию отчёта, исключая очень подробную и техническую информацию.
### Детальное сканирование
Если вы хотите полностью оценить вашу систему и выполнить всё, что у нас есть, мы рекомендуем установить оба уровня детализации в `ALL`. Это выполняет все существующие проверки полностью и выводит очень подробную информацию для дальнейшего анализа и оценки.
## Профили сканирования
Вместо (или в дополнение к) индивидуальной настройке таких параметров, как `-scanDetail`, вы можете объединить
выбор проверок для запуска и используемых параметров в переиспользуемый JSON-профиль сканирования с
помощью параметра `-profile <path/to/profile.json>`. Он доступен как в `TlsServerScanner`, так и в
`TlsClientScanner`.
Профиль — это JSON-файл со следующими полями:
- `inheritedFromProfiles`: пути к другим профилям, из которых объединяются проверки, разрешаемые относительно
директории файла профиля, в котором они объявлены (абсолютный путь используется как есть).
- `probes`: проверки для запуска в виде отображения из полного имени класса перечисления `ProbeType`
в список имён его констант для запуска. Это группирует проверки по типу вместо повторения
типа для каждой отдельной проверки, при этом один профиль всё ещё может свободно комбинировать проверки из
разных реализаций `ProbeType`, например `TlsProbeType` и `QuicProbeType`. Каждый список для типа
также принимает `"*"` (все константы этого типа) и `"!CONSTANT_NAME"` (удалить константу, ранее добавленную по имени или через `"*"`), обрабатываемые по порядку — см. `Everything.json` и
`demo.json` в [`scan-profiles/`](https://github.com/tls-attacker/tls-scanner/blob/main/scan-profiles) для примеров.
- `settings` (необязательно): переопределения для таких параметров, как `-scanDetail`, `-reportDetail`,
`-postAnalysisDetail`, `-noColor`, `-outputFile`, `-probeTimeout`, `-parallelProbes` и
`-threads`. Любое пропущенное поле сохраняет своё обычное значение по умолчанию (или то, что было передано в командной
строке). **В отличие от `probes`, `settings` не наследуются** — применяются только настройки, объявленные непосредственно в
профиле, на который вы указываете `-profile`, даже если он наследует проверки из других профилей.
Выполняются только проверки, разрешённые из активного профиля (и всего, что он наследует);
всё остальное пропускается.
Пример, объединяющий проверки базового профиля с вашими собственными и настраивающий детализацию сканирования:
`base.json`:
```json
{
"probes": {
"de.rub.nds.tlsscanner.core.constants.TlsProbeType": ["PROTOCOL_VERSION", "CIPHER_SUITE"]
}
}
```
`quic.json` (в той же директории, что и `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
```
Это запускает `PROTOCOL_VERSION`, `CIPHER_SUITE` и `SUPPORTED_VERSIONS` с `-scanDetail QUICK`.
Чтобы увидеть все проверки, доступные для сканера (без подключения к цели), используйте `-listProbes`.
Он выводит их, сгруппированными по классу `ProbeType`, в точном синтаксисе JSON, который ожидает поле `probes`
профиля, так что вы можете скопировать и вставить его прямо в профиль:
```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", ... ]
}
```
## Все параметры
Чтобы получить подробную информацию обо всех возможных параметрах, используйте параметр `-help` или запустите jar без каких-либо заданных параметров.
# Docker
Мы предоставляем готовые docker-образы для удобного использования TLS-Server-Scanner.
```bash
$ docker run -it --network host ghcr.io/tls-attacker/tlsscanner -connect localhost:4433
```
Образ предназначен для сканирования серверов, но также содержит другие jar-файлы.
Доступ к ним можно получить, изменив entrypoint.
```bash
$ docker run -it --network host --entrypoint java ghcr.io/tls-attacker/tlsscanner -jar TLS-Client-Scanner.jar
```
Мы также предоставляем вам Dockerfile, чтобы собрать контейнер самостоятельно:
```bash
$ docker build . -t tlsscanner
$ docker run -t tlsscanner
```
**Обратите внимание:** *Я отнюдь не знаком с лучшими практиками Docker. Если вы знаете, как улучшить Dockerfile,
не стесняйтесь отправить pull request*
# Система требований
( TLS) проверки иногда имеют предварительные условия, необходимые для выполнения этой конкретной проверки. Система требований позволяет вам определять наборы таких требований, которые должны быть выполнены для того, чтобы проверка была выполнена.
Каждое требование предоставляет функцию `evaluate`, которая возвращает логическое значение, указывающее, было ли требование выполнено.
Требования можно объединять несколькими способами, используя общеизвестные логические операции. Каждое требование предоставляет методы экземпляра `and`, `or`, `not` и `xor`
для объединения нескольких требований. В настоящее время реализованы следующие проверки, которые можно использовать сразу:
- `FulfilledRequirement` — всегда вычисляется в `true`, полезно для указания отсутствия требования.
- `UnfulfillableRequirement` — всегда вычисляется в `false`, предотвращает выполнение проверок.
- `ProbeRequirement` — вычисляется в `true`, если указанная проверка(и) была выполнена.
- `PropertyRequirement` — вычисляется в `true`, если указанные проанализированные свойства имеют предопределённое значение. Значение может быть предоставлено либо как параметр конструктора, либо можно использовать `PropertyTrueRequirement` и `PropertyFalseRequirement` как сокращение для `TestResults.TRUE` и `TestResults.FALSE`.
- `PropertyComparatorRequirement` — вычисляется в `true`, если результат коллекции проанализированного свойства меньше, равен или больше константного значения.
- `ProtocolRequirement` — вычисляется в `true`, если поддерживаются определённые версии протокола.
- `ExtensionRequirement` — вычисляется в `true`, если определённые расширения поддерживаются удалённым узлом.
- `OptionsRequirement` — вычисляется в `true`, если установлены дополнительные флаги cli. В настоящее время используется в некоторых клиентских проверках (ALPN, SNI, возобновление сессии).
- `WorkingConfigRequirement` — вычисляется в `true`, если найдена рабочая конфигурация.
Помимо этих предопределённых требований, можно также расширить класс `Requirement` анонимно внутри метода `getRequirements`. Если ничего не требуется, вы можете вернуть `FulfilledRequirement`, который всегда вычисляется в true.
Примеры использования требований можно найти в пакетах `probe` в `tls-client-scanner` и `tls-server-scanner`.
```java
@Override
public Requirement<ClientReport> getRequirements() {
return new ProbeRequirement<ClientReport>(TlsProbeType.CIPHER_SUITE)
.and(new PropertyTrueRequirement<>(TlsAnalyzedProperty.SUPPORTS_DHE));
}
```