Redirectors HTTP/S

Un redirector HTTP/S recibe tráfico público, decide si coincide con el perfil operativo y reenvía solo las peticiones admitidas. Reduce la exposición directa del servicio de origen (upstream) y permite rotar el frontal. No hace invisible el C2 ni corrige un perfil incoherente.

Antes de configurar:

• FQDN y certificado válidos
• servicio de origen accesible por una ruta privada o una lista de permitidos
• ruta HTTP, método, cabeceras y comportamiento del listener
• origen de las comprobaciones de estado
• destino y retención de los registros
• acceso administrativo separado
• respuesta para tráfico no coincidente
• procedimiento de reemplazo

cliente
  -> DNS
  -> TLS/SNI at redirector
  -> filtro de método, ruta y cabeceras
       -> rechazo local
       -> proxy al listener de origen
            -> autenticación del protocolo
            -> team server

El filtro del redirector no sustituye la autenticación del listener. Una petición que conoce la ruta no debe recibir tareas sin las claves del protocolo.

Este ejemplo admite una comprobación de estado y un prefijo de ruta. access_log registra las solicitudes aceptadas por cada contexto y error_log conserva fallos de procesamiento con el nivel indicado. proxy_pass define el upstream que recibirá una ruta admitida. UPSTREAM_FQDN, los certificados y las redes son marcadores que deben sustituirse:

server {
    listen 443 ssl;
    server_name edge.example.test;

    ssl_certificate     /etc/redirector/tls/fullchain.pem;
    ssl_certificate_key /etc/redirector/tls/privkey.pem;

    access_log /var/log/nginx/redirector-access.log combined;
    error_log  /var/log/nginx/redirector-error.log warn;

    location = /health {
        access_log /var/log/nginx/health.log combined;
        return 204;
    }

    location ^~ /api/v1/ {
        limit_except GET POST { deny all; }

        proxy_set_header Host upstream.internal.example.test;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;

        proxy_ssl_server_name on;
        proxy_ssl_name upstream.internal.example.test;
        proxy_ssl_verify on;
        proxy_ssl_trusted_certificate /etc/redirector/tls/upstream-ca.pem;

        proxy_connect_timeout 5s;
        proxy_read_timeout 60s;
        proxy_next_upstream error timeout;
        proxy_pass https://UPSTREAM_FQDN;
    }

    location / {
        return 404;
    }
}

La cabecera X-Forwarded-For comunica la dirección del cliente al servicio de origen y puede terminar en registros sensibles. Elimínala o protege esos registros solo después de determinar qué datos necesita el diagnóstico y cuáles exige la coordinación operativa (deconfliction).

Restringe el servicio de origen para que acepte TCP 443 únicamente desde la IP del redirector. Si utiliza mTLS, añade un certificado de cliente y valida su ciclo de rotación.

proxy_connect_timeout limita el establecimiento de la conexión con el origen. proxy_read_timeout mide el intervalo entre operaciones de lectura, no la duración total de la respuesta. proxy_next_upstream error timeout solo permite repetir la petición ante error de conexión o timeout. Si añades varios orígenes, revisa la idempotencia del método antes de ampliar los casos de reintento.

sudo nginx -t
sudo systemctl reload nginx
sudo systemctl status nginx --no-pager

nginx -t valida la sintaxis y la apertura de los archivos. No prueba DNS, TLS hacia el servicio de origen ni el protocolo del listener.

nginx -T realiza la misma comprobación y además imprime la configuración efectiva, incluidos los archivos incorporados. Resulta útil para detectar precedencia o un include inesperado, pero puede exponer rutas, certificados, endpoints y otros datos de configuración. Conserva el resultado en un directorio de evidencia con permisos restrictivos:

sudo nginx -T > evidence/nginx-effective.conf 2> evidence/nginx-validation.log

El código de salida cero confirma que Nginx pudo analizar la configuración y abrir los archivos referenciados. El siguiente paso sigue siendo comprobar la ruta completa con una petición negativa y otra positiva.

Pruebas negativas:

curl --fail-with-body --resolve edge.example.test:443:REDIRECTOR_IP \
  https://edge.example.test/not-allowed

curl --request PUT --resolve edge.example.test:443:REDIRECTOR_IP \
  https://edge.example.test/api/v1/control

Prueba positiva:

curl --verbose --resolve edge.example.test:443:REDIRECTOR_IP \
  https://edge.example.test/api/v1/HEALTH_PATH

Una respuesta HTTP correcta solo cubre el proxy. La comprobación completa utiliza un simulador del protocolo C2 y confirma el registro de la conexión y el recorrido de ida y vuelta.

Las dimensiones habituales son:

• SNI y Host
• ruta
• método
• cabeceras y valores
• cookie
• tamaño y Content-Type
• origen
• ventana horaria

Filtrar por un valor User-Agent estático es fácil de descubrir y puede bloquear versiones legítimas. Filtrar por la IP del objetivo requiere mantenimiento y expone el alcance al frontal. Combina solo señales que el agente produzca de forma estable.

Correlaciona el registro de acceso, el registro de errores y el listener. Si la petición no aparece en el frontal, no empieces a depurar por el team server.

El redirector expone:

• IP y proveedor
• certificado y CT
• huella TLS y HTTP
• cabeceras y respuestas
• comportamiento de las rutas
• tiempos y volumen

El objetivo puede ver DNS, SNI, destino, TLS, proxy y contenido según el tipo de inspección. El proveedor ve los recursos y el tráfico. El servicio de origen ve lo que el frontal conserva o añade.

Prepara un segundo frontal antes de retirar el primero. Valida DNS, certificado, reglas, servicio de origen, registros y perfil. Reduce el TTL con antelación. Mantén ambos durante la propagación si el plan lo permite. No borres registros antes de cerrar la coordinación operativa y preservar la evidencia necesaria.

• Nginx: ngx_http_proxy_module
• Nginx: command-line parameters
• Nginx: Configuring HTTPS servers
• RFC 9110: HTTP Semantics