syss-research/wcfproxyUn proxy para tráfico WCF basado en net.tcp.
Puedes compilar la herramienta una vez y luego usar el binario resultante, o ejecutarla "como un script" (el toolchain de Go la compilará sobre la marcha).
Para desarrollo, la última opción es conveniente.
Para uso productivo, se recomienda compilarlo una vez (desde el directorio cli) y usar el ejecutable resultante.
Gracias al compilador de Go, puedes compilar desde y para Linux o Windows.
Se requiere al menos la versión 1.18 de Go para compilar (probado con Go 1.23).
Para compilar desde Linux para Windows o Linux, simplemente establece GOOS apropiadamente (ejecuta desde el directorio cli):```
GOOS=windows GOARCH=amd64 go build -o wcfproxy.exe
* **-param** puede proporcionar un valor pero también recuperar valores del contenido de archivos o resultados de un comando:
* `-param 'aes-256-ctr'` proporcionar valor directamente
* `-param @file.txt` proporcionar valor desde el contenido del archivo
* `-param $(command)` proporcionar valor desde los resultados del comando
* **-pipe** puede pasar el contenido redirigido desde stdin al binario de destino:
* Suministrar contenido redirigido vía stdin `echo "test" | secshell -pipe -cmd 'nc localhost 1337'`
* Suministrar contenido redirigido vía redirección de archivo `secshell -pipe -cmd 'nc localhost 1337' < file.txt`
## ¿Por qué no simplemente usar el shell?
La razón principal para usar secshell es evitar dejar rastros en los registros del sistema.
Cuando ejecutas un comando como `ncat -e /bin/bash`, la cadena completa del comando se registra en varios registros del sistema (historial del shell, auditd, syslog). Esto deja un rastro forense digital claro para equipos azul/rojo.```
GOOS=linux GOARCH=amd64 go build -o wcfproxy
Para compilar desde Windows, ejecuta los comandos equivalentes, por ejemplo desde PowerShell:``` $env:GOOS='windows'; $env:GOARCH='amd64'; go build -o wcfproxy.exe
las actualizaciones se aplican automáticamente sin intervención del usuario, garantizando que el sistema esté siempre protegido contra las vulnerabilidades más recientes.```
$env:GOOS='linux'; $env:GOARCH='amd64'; go build -o wcfproxy
La configuración para wcfproxy se proporciona a través de un archivo JSON.
Por defecto, se utiliza el archivo de configuración config.json, pero la ruta a un archivo de configuración se puede especificar con el parámetro -config.
El archivo de configuración debe contener tantas configuraciones con nombre como se desee, de la siguiente manera:```json
{
"my-config": {
" ... ": " ... "
}
}
El valor de los objetos de configuración nombrados debe coincidir con la estructura `Config` (ver [Estructura de Config](#config-structure)).
Este archivo fuente con los comentarios incluidos también funciona como la documentación más precisa para las opciones de configuración de `wcfproxy`.
De toda la configuración proporcionada, la que se debe usar se identifica por nombre mediante la opción de línea de comandos `-enable`:```
wcfproxy.exe -config config.json -enable my-config
La estructura de nivel superior de cada objeto de configuración es la siguiente:```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": { " ... ": " ... " } }
Nota que no se puede proporcionar una configuración TLS (`tls-server` y/o `tls-client`) si existe una configuración NTLM.
### Opciones de configuración
+ `listen` - el punto final TCP en el que *wcfproxy* debe escuchar, p. ej. `127.0.0.1:8000` o `[::1]:8000`
+ `connect` - el punto final TCP del servidor WCF ascendente, p. ej. `127.0.0.1:9000` o `[::1]:9000`
+ `retarget` - especificación del objetivo original (y valor de reserva para `retarget-map`); para una explicación, consulte [Reescritura de objetivo](#target-rewriting)
+ `retarget-map` - generalización de `retarget`; permite realizar la reescritura de objetivo para múltiples puntos finales (solo es útil si se trabaja con múltiples servicios WCF en el mismo puerto)
+ si una de las claves en `retarget-map` coincide con el objetivo actual, la URI del objetivo se reemplazará con el valor dado para la comunicación ascendente
+ si ninguna clave de `retarget-map` coincide con el objetivo actual, se usará `retarget` en su lugar
+ `log-level` - nivel de registro; valores disponibles: `debug`, `info` (por defecto), `warn`, `error`
+ `log-file` - ruta al archivo de registro; si no se proporciona una ruta, el registro se escribe en `stdout`
+ `tls-server` - instancia de `TlsServerConfig` (consulte [Configuración del servidor TLS](#tls-server-configuration)); solo se requiere si se debe soportar la actualización TLS
+ `tls-client` - instancia de `TlsClientConfig` (consulte [Configuración del cliente TLS](#tls-client-configuration)); solo es relevante si se debe soportar la actualización TLS
+ `ntlm` - instancia de `NtlmConfig` (consulte [Configuración NTLM](#ntlm-configuration)); solo se requiere si se debe soportar la actualización NTLM (directamente o a través de SPNEGO)
+ `interceptor` - instancia de `InterceptorConfig` (consulte [Configuración del interceptor](#interceptor-configuration)); requerido
+ `ctrl` - instancia de `ControlServerConfig` (consulte [Configuración del servidor de control](#control-server-configuration)) que puede proporcionar un servidor echo HTTP por defecto (útil junto con el interceptor HTTP) así como una pequeña API para controlar el flujo de mensajes (aún en desarrollo)
### Configuración del servidor TLS
La configuración del lado del servidor TLS brinda control sobre la mayoría de los ajustes típicamente relevantes del servidor TLS.
Tiene la siguiente estructura:```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 - ruta al certificado X.509 (en formato PEM)cert-key - ruta a la clave correspondiente para el certificadomax-version - versión TLS máxima aceptable; una de 1.0, 1.1, 1.2, 1.3 (predeterminada)min-version - versión TLS mínima aceptable; una de 1.0 (predeterminada), 1.1, 1.2, 1.3client-roots - lista separada por comas de rutas a certificados raíz aceptables (PEM) para autenticación del cliente; opcionalclient-auth - política de autenticación del cliente; valores más útiles: (predeterminado), La configuración del lado del cliente TLS proporciona control sobre la mayoría de los ajustes típicamente relevantes del cliente TLS. Tiene la siguiente estructura:```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 }
#### Opciones de configuración del cliente TLS
+ análogas a las [opciones de configuración del servidor TLS](#tls-server-configuration-options)
+ `roots` - ruta a una lista separada por comas de rutas a CA raíz (PEM); opcional con `skip-verify`
+ `server-name` - nombre del servidor (SNI); opcional
+ `skip-verify` - bool; indica si el cliente debe omitir la verificación del certificado del servidor (predeterminado: `false`)
### Configuración NTLM
La configuración NTLM especifica el dominio y nombre del servidor, así como las credenciales de usuario.
Para cada usuario que deba poder autenticarse contra el proxy, se deben proporcionar credenciales válidas.```json
{
"domain": "test.local",
"server": "server.local",
"credentials": [
{
" ... ": " ... "
}
]
}
domain - dominio contra el que autenticarse, ej. test.local; si se deja en blanco, se usará el nombre del servidorserver - nombre del servidor contra el que autenticarse; si se deja en blanco, se usará el nombre de host del sistema actualcredentials - arreglo de objetos NtlmCredential (ver más abajo)Las credenciales NTLM se pasan como un arreglo de objetos NtlmCredential, que tienen la siguiente estructura:```json
{
"name": "wcflab",
"password": "Sup3rS3cr3t",
"nt-hash": "a8fc07dede90b0ec10bc1ef355f99292",
"lm-hash": "3e9cb63e11a812cbc467021088dc706f"
}
+ `name` - nombre de usuario
+ `password` - contraseña del usuario; de ella se derivarán los hashes; sobrescribe los hashes proporcionados para un usuario
+ `nt-hash` - hash NT (hex) de la contraseña del usuario; alternativa a la contraseña
+ `lm-hash` - hash LM (hex) de la contraseña del usuario; alternativa a la contraseña; no debería ser necesario en la mayoría de los casos
Si se proporciona una contraseña, el hash LM (no posible para todas las contraseñas) y el hash NT se calculan a partir de ella.
Cualquier valor de hash proporcionado para este usuario será sobrescrito por los hashes calculados.
También es posible proporcionar solo el/los hash(es) del usuario.
El hash LM no debería ser necesario en la mayoría de los escenarios.
### Configuración del interceptor
La configuración del interceptor especifica el interceptor (por nombre) que se debe utilizar y, opcionalmente, argumentos específicos del interceptor.
Para una explicación de los interceptores, consulte [Interceptors](#interceptors).
#### Interceptor de registro
Para usar el interceptor de registro, simplemente use la siguiente configuración del interceptor.
La salida se escribe en la ubicación de registro principal, que puede ser un archivo o `stdout`, según la configuración de `log-file`.```json
{
"name": "log"
}
Para usar el interceptor HTTP, usa la siguiente configuración de interceptor con opciones adecuadas para server-url y proxy-url.```json
{
"name": "http",
"args": {
"server-url": "http://127.0.0.1:9999/echo",
"proxy-url": "http://127.0.0.1:8080"
}
}
+ `args.server-url` - URL del punto de intercepción de tu servidor HTTP (por ejemplo, un endpoint echo simple); para más detalles sobre cómo funciona el interceptor HTTP, consulta [HTTP Interceptor](#http-interceptor-1)
+ `args.proxy-url` - URL del proxy HTTP; opcional
### Configuración del servidor de control
*wcfproxy* viene con un servidor web incorporado que cumple dos funciones.
Primero, puede proporcionar un endpoint HTTP que simplemente refleja todo el contenido que se le envía.
Esto es útil en combinación con el [interceptor HTTP](#http-interceptor-1).```json
{
"ctrl": {
"listen": "127.0.0.1:9999",
"enable-control": false,
"enable-echo": true
}
}
[!WARNING]
Cualquier persona que pueda acceder a la API puede autenticarse utilizando las credenciales proporcionadas (NTLM o certificados de cliente TLS). En sistemas compartidos, esto puede ser relevante incluso si la API solo está disponible localmente.
listen - el extremo TCP donde debe escuchar el servidor de controlenable-control - habilita funciones de control como la inyección de mensajes o el establecimiento de conexiones (consulte Inyección de mensajes)enable-echo - habilita un servidor HTTP echo simple en http://{listen}/echoLas siguientes secciones proporcionan información de contexto que puede ayudar a comprender mejor WCF, así como algunas opciones de configuración.
El extremo WCF previsto está codificado en el preámbulo net.tcp, así como en el encabezado To de los sobres SOAP transportados.
Los servidores pueden verificar que esta especificación de extremo coincida con la esperada.
Cuando se manipula al cliente para que se conecte al proxy en lugar del servidor original, esta especificación de extremo probablemente cambiará y el servidor puede rechazar la comunicación.
Por lo tanto, generalmente tiene sentido corregir la especificación del extremo en el tráfico saliente hacia el servidor.
Para hacer esto, proporcione la especificación del extremo original (por ejemplo, obtenida de la configuración del cliente) en la opción retarget en el archivo de configuración.
La especificación del extremo generalmente se ve así: net.tcp://some/endpoint.
Cuando se trabaja con múltiples extremos WCF simultáneamente, puede ser necesario realizar la reescritura de destino para todos ellos.
Con este propósito existe la opción retarget-map, que define el mapeo entre URIs de destino.
Cuando no se encuentra una coincidencia en el retarget-map, la URI de destino se cambiará al valor proporcionado en retarget.
El XML binario, según lo especificado por MC-NBFX, codifica información de tipo básica en el formato binario (tipos de registro).
No toda esta información se puede recuperar fácilmente de la representación XML (textual) de un documento XML binario.
Por esta razón, wcfproxy inserta sugerencias de tipo en los datos de caracteres XML (y algunos atributos) de los tokens.
Estas sugerencias de tipo toman la forma <h>: donde <h> es una cadena corta que codifica algún tipo (por ejemplo, i para entero, ch para caracteres).
Se puede encontrar una lista completa de sugerencias de tipo en typehint.go.
No se recomienda alterar las sugerencias de tipo.
Los interceptores especifican cómo se maneja el tráfico recibido y se especifican mediante la configuración del interceptor. Manejan el tráfico enviado en ambas direcciones (cliente -> servidor y servidor -> cliente). Actualmente hay dos interceptores: log y http.
El interceptor log convierte los sobres SOAP codificados en binario en sus contrapartes legibles para humanos codificadas con XML basado en texto.
No se realiza ninguna manipulación activa (excepto la reescritura de la especificación de destino).
La salida se envía a la ubicación de registro especificada (stdout por defecto).
Asegúrese de establecer el nivel de registro en info (o debug); de lo contrario, la salida relevante se suprime.
El interceptor http convierte los sobres SOAP binarios en sus contrapartes basadas en texto y los envía a un extremo HTTP especificado por -http-url.
Los mensajes SOAP decodificados se envían en el cuerpo de la solicitud.
El servidor HTTP debe devolver un sobre SOAP válido en el mismo formato que los mensajes entrantes.
Estos mensajes luego se transforman de nuevo al formato binario original y se envían al servidor ascendente.
Simplemente reflejar el mensaje original es siempre una opción válida para el servidor HTTP. Sin embargo, también se puede lograr la manipulación programática de los mensajes proporcionando un servidor HTTP personalizado que realice los reemplazos deseados. Se debe tener cuidado de no romper la estructura de los mensajes SOAP. Se recomienda no alterar el formato de los mensajes a menos que sepa lo que está haciendo. Además, no se deben alterar las sugerencias de tipo insertadas por wcfproxy, ya que esto podría romper la transformación de los mensajes SOAP basados en texto a sus contrapartes binarias o el análisis de mensajes en el extremo legítimo (cliente o servidor).
wcfproxy incluye un servidor HTTP trivial que simplemente refleja el cuerpo de las solicitudes HTTP recibidas.
Este servidor se iniciará cuando se proporcione una configuración del servidor de control y la opción enable-echo esté establecida en true.
La URL del servidor HTTP deseado se proporciona a través de la opción server-url en la configuración del interceptor http.
Para permitir la manipulación interactiva, se puede especificar un proxy HTTP (por ejemplo, BurpSuite) a través de la opción proxy-url.
Los mensajes se enviarán al servidor HTTP a través del proxy HTTP especificado.
Tenga en cuenta que para cada mensaje WCF (por ejemplo, cliente -> servidor), se produce un par solicitud-respuesta HTTP.
Para correlacionar los mensajes con la conexión net.tcp de la que se originaron, se inserta el encabezado X-Wcpf-Conn-Id en las solicitudes generadas por el interceptor http.
La siguiente imagen ilustra el flujo de datos con el interceptor http.
WCF (sobre net.tcp) puede usar TLS para la seguridad del transporte. wcfproxy admite la intercepción de conexiones TLS (solo TLS 1.0 - 1.3, sin SSL). La configuración TLS del lado del servidor y del lado del cliente se puede controlar con la configuración TLS correspondiente (consulte Configuración del servidor TLS o Configuración del cliente TLS).
wcfproxy admite la autenticación NTLM.
Actualmente, se admite la autenticación NTLM directa o la negociación a través de SPNEGO.
Debe proporcionar las credenciales del usuario o los usuarios que se autenticarán.
Estas credenciales se proporcionan en formato JSON; consulte Configuración NTLM.
Se admite el paso de hashes proporcionando hashes a través de la propiedad nt-hash.
Cuando el servidor de control está habilitado, se proporciona una pequeña API HTTP que se puede utilizar para establecer o finalizar conexiones e inyectar mensajes en conexiones existentes. Los siguientes extremos están disponibles.
/connectionMuestra las conexiones actualmente activas.
Para conexiones solo de servidor (creadas mediante POST /connection/new), el cliente se mostrará como wcfproxy.
/connection/newCrea una nueva conexión.
El cuerpo debe ser un objeto JSON que especifique la actualización prevista (TLS o Negociar (NTLM)), si la hubiera.
La URI del extremo se proporciona a través de la propiedad target-uri.
Si no se requiere ninguna actualización, la propiedad upgrade puede omitirse.```json
{
"target-uri":"net.tcp://127.0.0.1:9510/example/notes-nettcp"
}
#### Ejemplo: Actualización TLS
Para iniciar una actualización TLS, especifique el mecanismo de actualización `tls`.```json
{
"target-uri":"net.tcp://wcf-notes.local:9511/example/notes-nettcp-tls",
"upgrade": {
"mechanism":"tls"
}
}
El objeto upgrade debe especificar ntlm como mecanismo y el usuario con el que autenticarse.
Las credenciales del usuario deben ser proporcionadas con la configuración ntlm.```json
{
"target-uri":"net.tcp://localhost:8203/WCFLab/WCFDemoService/nettcp-winauth",
"upgrade": {
"mechanism": "ntlm",
"ntlmuser": "wcflab"
}
}
### POST `/connection/{id}/kill`
Destruye la conexión identificada por `{id}`.
### POST `/connection/{id}/inject`
Inyecta el mensaje proporcionado en el cuerpo de esta solicitud en la conexión identificada por `{id}`.
El cuerpo debe estar en el mismo formato que se utiliza para reenviar mensajes WCF a interceptores HTTP.
Por lo tanto, es mejor copiar un mensaje observado, modificarlo según sea necesario y luego inyectarlo a través de este endpoint.
Por defecto, las respuestas a los mensajes inyectados no se muestran.
Sin embargo, si un interceptor está activo, las respuestas deberían aparecer allí.
Para mayor comodidad, cuando se proporciona el parámetro de consulta `retrieve=true`, `wcfproxy` espera la respuesta al mensaje inyectado y la muestra.
## Límite de conexiones
Se aplica un límite superior artificial al número de conexiones activas concurrentes.
Este límite está actualmente establecido en 20.
Esto es para evitar el agotamiento accidental de recursos cuando se (mal)utiliza la API de control (ver [Inyección de mensajes y establecimiento de conexiones](#message-injection-and-connection-establishment)).
Esto rara vez debería suponer un problema para los clientes WCF legítimos.
Sin embargo, puede haber casos de uso que requieran más conexiones concurrentes.
En ese caso, modifique la constante `maxConnections` en [proxy.go](https://github.com/syss-research/wcfproxy/blob/HEAD/proxy/proxy.go) según sea necesario.
# Ejemplos
Los siguientes ejemplos muestran algunos usos básicos de *wcfproxy*.
La salida exacta puede estar sujeta a cambios, pero la idea debería quedar clara.
## Usando el interceptor de registro
Este ejemplo muestra el uso de *wcfproxy* en el entorno de pruebas de WCF para comunicación WCF simple sobre net.tcp utilizando el interceptor **log**.```json
{
"wcflab-plain": {
"listen": "127.0.0.1:7201",
"connect": "127.0.0.1:8201",
"retarget": "net.tcp://127.0.0.1:8201/WCFLab/WCFDemoService/nettcp",
"log-level": "debug",
"interceptor": {
"name": "log"
}
}
}
Con la configuración anterior (colocada en config.json), podemos usarla como se muestra a continuación.
El tráfico a través del proxy debería entonces volcarse en la consola (stdout).```
.\wcfproxy.exe -config .\config.json -enable wcflab-plain 2025/07/10 15:03:59 dbg: local time zone (for DateTime handling): CEST INFO: Listening on 127.0.0.1:7201 and connecting to 127.0.0.1:8201 INFO: No server certificates given. TLS upgrade not supported. INFO: No client certificates given. TLS client authentication not supported. INFO: Retargeting to net.tcp://127.0.0.1:8201/WCFLab/WCFDemoService/nettcp INFO: [proxy] Handling new connection 0: 127.0.0.1:50216 <-> 127.0.0.1:8201 INFO: [proxy] Connection 0 established (127.0.0.1:50216 <-> 127.0.0.1:8201) INFO: [proxy] Envelope (Connection 0, Client -> Server): <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing"> <s:Header> <a:Action s:mustUnderstand="c:1">ch:http://tempuri.org/IWCFDemoService/AddInts</a:Action> <a:MessageID>uid:urn:uuid:b2d5fc85-4bcd-6442-b701-164655365198</a:MessageID> <a:ReplyTo> <a:Address>ch:http://www.w3.org/2005/08/addressing/anonymous</a:Address> </a:ReplyTo> <a:To s:mustUnderstand="c:1">ch:net.tcp://127.0.0.1:8201/WCFLab/WCFDemoService/nettcp</a:To> </s:Header> <s:Body>
i:1234 i:37 </s:Body> </s:Envelope> INFO: [proxy] Envelope (Connection 0, Server -> Client): <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing"> <s:Header> <a:Action s:mustUnderstand="c:1">ch:http://tempuri.org/IWCFDemoService/AddIntsResponse</a:Action> <a:RelatesTo>uid:urn:uuid:b2d5fc85-4bcd-6442-b701-164655365198</a:RelatesTo> <a:To s:mustUnderstand="c:1">ch:http://www.w3.org/2005/08/addressing/anonymous</a:To> </s:Header> <s:Body> i:1271 </s:Body> </s:Envelope> INFO: [proxy] Connection 0 closed (127.0.0.1:50216 <-> 127.0.0.1:8201) ERROR: [net.tcp] Error readEnvelopeOrFaultI2R: read tcp 127.0.0.1:50217->127.0.0.1:8201: i/o timeout. Entering fault state. INFO: [proxy] Done handling connection 0: 127.0.0.1:50216 <-> 127.0.0.1:8201
## Usando el interceptor http
La siguiente configuración usa el interceptor **http** y en combinación con un proxy HTTP.```json
{
"wcflab-plain-http": {
"listen": "127.0.0.1:7201",
"connect": "127.0.0.1:8201",
"retarget": "net.tcp://127.0.0.1:8201/WCFLab/WCFDemoService/nettcp",
"log-level": "info",
"ctrl": {
"listen": "127.0.0.1:9999",
"enable-echo": true
},
"interceptor": {
"name": "http",
"args": {
"proxy-url": "http://127.0.0.1:8080"
}
}
}
}
Con esta configuración, el registro no muestra nada interesante.```
go run ./ -config .\config.json -enable wcflab-plain-http 2025/07/10 18:06:02 dbg: local time zone (for DateTime handling): CEST 2025/07/10 18:06:02 DBG - configuring intercrptor: &{http map[proxy-url:http://127.0.0.1:8080]} INFO: Listening on 127.0.0.1:7201 and connecting to 127.0.0.1:8201 INFO: No server certificates given. TLS upgrade not supported. INFO: No client certificates given. TLS client authentication not supported. INFO: Retargeting to net.tcp://127.0.0.1:8201/WCFLab/WCFDemoService/nettcp INFO: [proxy] Starting control server on 127.0.0.1:9999 (echo enabled: true, control enabled: false) INFO: [proxy] Handling new connection 0: 127.0.0.1:22664 <-> 127.0.0.1:8201 ERROR: [net.tcp] Error readEnvelopeOrFaultI2R: read tcp 127.0.0.1:22665->127.0.0.1:8201: i/o timeout. Entering fault state. INFO: [proxy] Done handling connection 0: 127.0.0.1:22664 <-> 127.0.0.1:8201
Sin embargo, el tráfico WCF se convierte en (casi) sobres SOAP regulares enviados a través de HTTP.
## Configuración de la interceptación (m)TLS
*wcfproxy* se puede configurar para interceptar tráfico WCF protegido con mTLS, siempre que haya certificados de servidor y cliente adecuados disponibles.
La configuración para TLS sin autenticación de cliente es similar; los certificados de cliente no son necesarios en este caso.
La siguiente configuración proporciona un ejemplo para este caso de uso:```json
{
"wcflab-mtls": {
"listen": "127.0.0.1:7203",
"connect": "127.0.0.1:8203",
"retarget": "net.tcp://localhost:8203/WCFLab/WCFDemoService/nettcps-mtls",
"interceptor": {
"name": "log"
},
"tls-server": {
"cert-pem": "../testdata/pki/server.pem",
"cert-key": "../testdata/pki/server.key"
},
"tls-client": {
"cert-pem": "../testdata/pki/client.pem",
"cert-key": "../testdata/pki/client.key",
"skip-verify": true
}
}
Tenga en cuenta que los clientes deben confiar en el certificado del servidor (server.pem). Además, el servidor debe confiar en el certificado presentado por la parte cliente de wcfproxy (client.pem).```
.\wcfproxy.exe -config .\config.json -enable wcflab-mtls 2025/07/10 15:01:32 dbg: local time zone (for DateTime handling): CEST INFO: Using client certificate client-01.local (SHA256-fingerprint: 9b258653a4d5f338f2be1dafe0caf892b01d271183e52f0821d80439de4b7564) INFO: Listening on 127.0.0.1:7203 and connecting to 127.0.0.1:8203 INFO: Using server certificate wcflab.local (SHA256-fingerprint: 7286ff75d3bb6dc4d96c0c8ac08dbac2204af67e0b1814b3d8c59c24d5bd781a) INFO: Server supports TLS versions 1.0 - 1.3 INFO: Using client certificate client-01.local (SHA256-fingerprint: 9b258653a4d5f338f2be1dafe0caf892b01d271183e52f0821d80439de4b7564) INFO: Client supports TLS versions 1.0 - 1.3 INFO: Retargeting to net.tcp://localhost:8203/WCFLab/WCFDemoService/nettcps-mtls INFO: [proxy] Handling new connection 0: 127.0.0.1:50214 <-> 127.0.0.1:8203 INFO: [proxy] Connection 0 established (127.0.0.1:50214 <-> 127.0.0.1:8203) INFO: [proxy] Initiating TLS upgrade INFO: [proxy] 127.0.0.1:50214 <-> 127.0.0.1:7203: negotiated TLS 1.2 (TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) INFO: [proxy] 127.0.0.1:50215 <-> 127.0.0.1:8203: negotiated TLS 1.2 (TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) INFO: [proxy] Upgrade done INFO: [proxy] Envelope (Connection 0, Client -> Server): <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing"> <s:Header> <a:Action s:mustUnderstand="c:1">ch:http://tempuri.org/IWCFDemoService/AddInts</a:Action> <a:MessageID>uid:urn:uuid:d36e17be-2cc2-a94f-83a7-cd2442dba24e</a:MessageID> <a:ReplyTo> <a:Address>ch:http://www.w3.org/2005/08/addressing/anonymous</a:Address> </a:ReplyTo> <a:To s:mustUnderstand="c:1">ch:net.tcp://localhost:8203/WCFLab/WCFDemoService/nettcps-mtls</a:To> </s:Header> <s:Body>
i:1234 i:37 </s:Body> </s:Envelope> INFO: [proxy] Envelope (Connection 0, Server -> Client): <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing"> <s:Header> <a:Action s:mustUnderstand="c:1">ch:http://tempuri.org/IWCFDemoService/AddIntsResponse</a:Action> <a:RelatesTo>uid:urn:uuid:d36e17be-2cc2-a94f-83a7-cd2442dba24e</a:RelatesTo> <a:To s:mustUnderstand="c:1">ch:http://www.w3.org/2005/08/addressing/anonymous</a:To> </s:Header> <s:Body> i:1271 </s:Body> </s:Envelope> INFO: [proxy] Connection 0 closed (127.0.0.1:50214 <-> 127.0.0.1:8203) ERROR: [net.tcp] Error readEnvelopeOrFaultI2R: read tcp 127.0.0.1:50215->127.0.0.1:8203: i/o timeout. Entering fault state. INFO: [proxy] Done handling connection 0: 127.0.0.1:50214 <-> 127.0.0.1:8203
## Configuración de la autenticación NTLM
Suponiendo que el servicio WCF depende de NTLM para la autenticación (ya sea directamente o a través de SPNEGO) la siguiente configuración se puede utilizar para interceptar el tráfico:```json
{
"wcflab-ntlm": {
"listen": "[::1]:7204",
"connect": "[::1]:8204",
"retarget": "net.tcp://localhost:8204/WCFLab/WCFDemoService/nettcp-winauth",
"interceptor": {
"name": "log"
},
"ntlm": {
"domain": "DESKTOP-65ITJF5",
"credentials": [
{
"name": "<user>",
"password": "<password>"
}
]
}
}
}
Tenga en cuenta que actualmente es más robusto proporcionar el nombre del host a través del campo server o domain que confiar en la configuración automática.
Además, la autenticación en un contexto de dominio AD no está probada y, por lo tanto, probablemente esté rota por el momento.
Cuando se usa SPNEGO, actualmente el mecanismo NTLM debe ser el preferido, de lo contrario la negociación fallará.```
.\wcfproxy.exe -config .\config.json -enable wcflab-ntlm 2025/07/10 15:15:15 dbg: local time zone (for DateTime handling): CEST INFO: Listening on [::1]:7204 and connecting to [::1]:8204 INFO: No server certificates given. TLS upgrade not supported. INFO: No client certificates given. TLS client authentication not supported. INFO: Retargeting to net.tcp://localhost:8204/WCFLab/WCFDemoService/nettcp-winauth INFO: [proxy] Handling new connection 0: [::1]:50247 <-> [::1]:8204 INFO: [proxy] Connection 0 established ([::1]:50247 <-> [::1]:8204) INFO: [proxy] Initiating Negotiate upgrade INFO: [NTLM server] User wcflab authenticated successfully INFO: [proxy] [::1]:50247 <-> [::1]:7204: negotiated NTLM INFO: [proxy] [::1]:50248 <-> [::1]:8204: negotiated NTLM INFO: [proxy] Upgrade done INFO: [proxy] Envelope (Connection 0, Client -> Server): <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing"> <s:Header> <a:Action s:mustUnderstand="c:1">ch:http://tempuri.org/IWCFDemoService/AddInts</a:Action> <a:MessageID>uid:urn:uuid:f9cc5af3-3930-9242-be3c-d36d2a0cb09e</a:MessageID> <a:ReplyTo> <a:Address>ch:http://www.w3.org/2005/08/addressing/anonymous</a:Address> </a:ReplyTo> <a:To s:mustUnderstand="c:1">ch:net.tcp://localhost:8204/WCFLab/WCFDemoService/nettcp-winauth</a:To> </s:Header> <s:Body>
i:1234 i:37 </s:Body> </s:Envelope> INFO: [proxy] Envelope (Connection 0, Server -> Client): <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing"> <s:Header> <a:Action s:mustUnderstand="c:1">ch:http://tempuri.org/IWCFDemoService/AddIntsResponse</a:Action> <a:RelatesTo>uid:urn:uuid:f9cc5af3-3930-9242-be3c-d36d2a0cb09e</a:RelatesTo> <a:To s:mustUnderstand="c:1">ch:http://www.w3.org/2005/08/addressing/anonymous</a:To> </s:Header> <s:Body> i:1271 </s:Body> </s:Envelope> INFO: [proxy] Connection 0 closed ([::1]:50247 <-> [::1]:8204) ERROR: [net.tcp] Error readEnvelopeOrFaultI2R: read tcp [::1]:50248->[::1]:8204: i/o timeout. Entering fault state. INFO: [proxy] Done handling connection 0: [::1]:50247 <-> [::1]:8204
nonerequire-and-verifykeylog - archivo para escribir secretos TLS en formato NNS