syss-research/wcfproxyПрокси для WCF-трафика на основе net.tcp.
Вы можете либо скомпилировать инструмент один раз и затем использовать полученный бинарный файл, либо запускать его «как скрипт» (цепочка инструментов Go скомпилирует его на лету).
Для разработки удобен последний вариант.
Для продуктивного использования рекомендуется скомпилировать его один раз (из директории cli) и использовать полученный исполняемый файл.
Благодаря компилятору Go вы можете собирать как из Linux, так и для Linux или Windows.
Для сборки требуется версия Go не ниже 1.18 (протестировано с Go 1.23).
Чтобы собрать из Linux для Windows или Linux, просто установите GOOS соответствующим образом (выполните из директории cli):```
GOOS=windows GOARCH=amd64 go build -o wcfproxy.exe
.```
GOOS=linux GOARCH=amd64 go build -o wcfproxy
Для сборки из Windows выполните эквивалентные команды, например, из PowerShell:``` $env:GOOS='windows'; $env:GOARCH='amd64'; go build -o wcfproxy.exe
> Пожалуйста, ознакомьтесь с нашими руководствами по [Kernels](https://github.com/syss-research/wcfproxy/blob/main/docs/source/install/kernels.md),
> [Drivers](https://github.com/syss-research/wcfproxy/blob/main/docs/source/install/drivers.md) или
> [Installation](https://github.com/syss-research/wcfproxy/blob/main/docs/source/install/README.md) для получения более подробной информации.
Примечание: если вы используете Windows, этот шаг можно пропустить. Поддержка Syzkaller для
Windows была нарушена некоторое время назад, и не всё может работать корректно.```
$env:GOOS='linux'; $env:GOARCH='amd64'; go build -o wcfproxy
Конфигурация для wcfproxy предоставляется через JSON-файл.
По умолчанию используется файл конфигурации config.json, но путь к файлу конфигурации можно указать с помощью параметра -config.
Файл конфигурации предназначен для хранения произвольного количества именованных конфигураций, например:```json
{
"my-config": {
" ... ": " ... "
}
}
Значение именованных объектов конфигурации должно соответствовать структуре `Config` (см. [Config structure](#config-structure)).
Этот исходный файл с включенными комментариями также служит наиболее точной документацией для опций конфигурации `wcfproxy`.
Из всей предоставленной конфигурации используемая определяется по имени с помощью опции командной строки `-enable`:```
wcfproxy.exe -config config.json -enable my-config
Структура верхнего уровня каждого объекта конфигурации следующая:```json { "listen": "[::1]:8000", "connect": "[::1]:9000", "retarget": "net.tcp://127.0.0.1:8000/WCFLab/WCFDemoService/nettcp", "retarget-map": { "nettcps": "net.tcp://localhost:8210/WCFLab/WCFDemoService/nettcps", "winauth": "net.tcp://localhost:8220/WCFLab/WCFDemoService/nettcp-winauth" }, "log-level": "debug|info|warn|error", "log-file": "path/to/log/file", "tls-server": { " ... ": " ... " }, "tls-client": { " ... ": " ... " }, "ntlm": { " ... ": " ... " }, "interceptor": { " ... ": " ... " }, "ctrl": { " ... ": " ... " } }
Обратите внимание, что конфигурация TLS (`tls-server` и/или `tls-client`) не может быть указана, если присутствует конфигурация NTLM.
### Параметры конфигурации
+ `listen` - TCP-endpoint, на котором *wcfproxy* должен прослушивать, например `127.0.0.1:8000` или `[::1]:8000`
+ `connect` - TCP-endpoint вышестоящего WCF-сервера, например `127.0.0.1:9000` или `[::1]:9000`
+ `retarget` - исходная спецификация целевого адреса (и запасной вариант для `retarget-map`); за объяснениями обратитесь к [Перезапись целевого адреса](#target-rewriting)
+ `retarget-map` - обобщение `retarget`; позволяет выполнять перезапись целевого адреса для нескольких endpoints (полезно только при работе с несколькими WCF-сервисами на одном порту)
+ если один из ключей в `retarget-map` совпадает с текущим целевым адресом, URI цели будет заменен на указанное значение для связи с вышестоящим сервером
+ если ни один ключ `retarget-map` не совпадает с текущим целевым адресом, вместо него будет использован `retarget`
+ `log-level` - уровень логирования; доступные значения: `debug`, `info` (по умолчанию), `warn`, `error`
+ `log-file` - путь к файлу журнала; если путь не указан, журнал выводится в `stdout`
+ `tls-server` - экземпляр `TlsServerConfig` (см. [Конфигурация TLS-сервера](#tls-server-configuration)); требуется только если необходимо поддерживать обновление TLS
+ `tls-client` - экземпляр `TlsClientConfig` (см. [Конфигурация TLS-клиента](#tls-client-configuration)); актуально только если необходимо поддерживать обновление TLS
+ `ntlm` - экземпляр `NtlmConfig` (см. [Конфигурация NTLM](#ntlm-configuration)); требуется только если необходимо поддерживать обновление NTLM (напрямую или через SPNEGO)
+ `interceptor` - экземпляр `InterceptorConfig` (см. [Конфигурация перехватчика](#interceptor-configuration)); обязательно
+ `ctrl` - экземпляр `ControlServerConfig` (см. [Конфигурация сервера управления](#control-server-configuration)), который может предоставлять HTTP-сервер эхо-ответов по умолчанию (полезен вместе с HTTP-перехватчиком), а также небольшой API для управления потоком сообщений (в разработке)
### Конфигурация TLS-сервера
Конфигурация на стороне TLS-сервера предоставляет контроль над наиболее типичными настройками TLS-сервера.
Она имеет следующую структуру:```json
{
"cert-pem": "path/to/certificate",
"cert-key": "path/to/certificate-key",
"max-version": "1.0|1.1|1.2|1.3",
"min-version": "1.0|1.1|1.2|1.3",
"client-roots": "path/to/client-ca1,path/to/client-ca2",
"client-auth": "none|request|require-any|verify-if-given|require-and-verify",
"keylog": "path/to/keylog-file"
}
cert-pem - путь к сертификату X.509 (в формате PEM)cert-key - путь к соответствующему ключу для сертификатаmax-version - максимальная допустимая версия TLS; одна из: 1.0, 1.1, 1.2, 1.3 (по умолчанию)min-version - минимальная допустимая версия TLS; одна из: 1.0 (по умолчанию), 1.1, 1.2, 1.3client-roots - список путей к допустимым корневым сертификатам (PEM) для аутентификации клиента, разделённый запятыми; опциональноclient-auth - политика аутентификации клиента; наиболее полезные значения: none (по умолчанию), require-and-verifykeylog - файл для записи секретов TLS в формате NNSКонфигурация на стороне TLS-клиента предоставляет контроль над наиболее типичными настройками TLS-клиента. Она имеет следующую структуру:```json { "cert-pem": "path/to/certificate", "cert-key": "path/to/certificate-key", "max-version": "1.0|1.1|1.2|1.3", "min-version": "1.0|1.1|1.2|1.3", "roots": "path/to/root-ca1,path/to/root-ca2", "server-name": "therealone.local", "skip-verify": false }
#### Параметры конфигурации TLS-клиента
+ аналогичны [параметрам конфигурации TLS-сервера](#tls-server-configuration-options)
+ `roots` - путь к разделённому запятыми списку путей к корневым центрам сертификации (PEM); опционально с `skip-verify`
+ `server-name` - имя сервера (SNI); опционально
+ `skip-verify` - логическое значение; следует ли клиенту отказаться от проверки сертификата сервера (по умолчанию: `false`)
### Конфигурация NTLM
Конфигурация NTLM указывает домен, имя сервера, а также учётные данные пользователя.
Для каждого пользователя, который должен иметь возможность аутентифицироваться через прокси, необходимо указать действительные учётные данные.```json
{
"domain": "test.local",
"server": "server.local",
"credentials": [
{
" ... ": " ... "
}
]
}
domain - домен для аутентификации, например test.local; если оставить пустым, будет использовано имя сервераserver - имя сервера для аутентификации; если оставить пустым, будет использовано имя хоста текущей системыcredentials - массив объектов NtlmCredential (см. ниже)