Checklist de readiness operacional

Esta checklist convierte «la máquina funciona» en condiciones verificables. Se ejecuta después de construir el entorno y antes de generar tráfico de evaluación. Cada resultado se registra con hora, sistema, interfaz y responsable. Un OK sin evidencia no permite distinguir una validación real de una suposición.

• La copia de trabajo tiene un identificador único de encargo o laboratorio.
• El hostname, el prompt y el directorio de trabajo muestran ese identificador.
• No existen notas, claves, VPN, montajes ni artefactos de otro cliente.
• La cuenta utilizada no sincroniza historial, marcadores o portapapeles con una cuenta personal.
• Los secretos están en la colección correspondiente y se ha probado el acceso de recuperación.
• El navegador de pruebas usa un perfil separado, sin extensiones ni sesiones personales.

Registra el inventario inicial:

hostnamectl
id
uname -a
date --iso-8601=seconds

En PowerShell, Get-ComputerInfo aporta versión y build. Get-Date -Format o produce una fecha ISO 8601 que conserva el desplazamiento horario:

$env:COMPUTERNAME
whoami /all
Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber
Get-Date -Format o

• La zona horaria registrada coincide con la usada en el plan de comunicación.
• La sincronización NTP está activa.
• La desviación frente a la fuente acordada está dentro del margen requerido por Kerberos, certificados, logs y correlación.
• Las capturas, notas y herramientas utilizan una convención horaria conocida.

En Linux, timedatectl status muestra zona y estado de sincronización. En Windows, w32tm /query /status muestra fuente, estrato y última sincronización. Si existe desviación, corrígela antes de comparar eventos o iniciar autenticaciones. No alteres la hora del objetivo para compensar un problema del operador.

• Se han identificado la interfaz de administración, la VPN, la interfaz de laboratorio y cualquier red de contenedores.
• La ruta a cada CIDR de alcance sale por la interfaz prevista.
• La ruta por defecto no ha sido sustituida de forma inesperada por la VPN.
• No existe solapamiento entre la red local, Docker, WSL y el espacio de direcciones del objetivo.
• La dirección de origen visible coincide con la lista comunicada.
• IPv4 e IPv6 se han considerado por separado.

ip route get consulta la decisión que el kernel tomaría para un destino concreto sin enviar el paquete. Sustituye TARGET_IP por una dirección de validación acordada:

ip -brief address
ip route
ip route get TARGET_IP

En Windows, Get-NetRoute muestra rutas y métricas. Test-NetConnection con -InformationLevel Detailed revela la interfaz y dirección de origen elegidas para la prueba:

Get-NetIPConfiguration
Get-NetRoute | Sort-Object DestinationPrefix, RouteMetric
Test-NetConnection TARGET_IP -Port TARGET_PORT -InformationLevel Detailed

Un timeout no confirma filtrado. Registra la ruta, captura el intento y distingue entre falta de ruta, resolución incorrecta, pérdida, rechazo y silencio del servicio.

• Se conoce qué resolver usa el sistema, la VPN y cada herramienta relevante.
• Los dominios internos se resuelven por el canal previsto.
• Las búsquedas externas no se filtran accidentalmente hacia un resolver del cliente.
• /etc/hosts, hosts, split DNS y suffix search no contienen entradas residuales.
• Se han registrado respuestas positivas y negativas de prueba.

resolvectl status muestra servidores y dominios asociados por interfaz en sistemas con systemd-resolved. dig permite especificar el servidor con @DNS_SERVER y evita atribuir una respuesta a un resolver desconocido:

resolvectl status
dig @DNS_SERVER VALIDATION_NAME A
dig @DNS_SERVER NONEXISTENT.VALIDATION_NAME A

La respuesta negativa importa. Un wildcard, un sinkhole o un DNS que sintetiza direcciones puede convertir cualquier nombre inventado en un falso activo.

• La VPN autentica desde la cuenta y host esperados.
• Se ha registrado interfaz, dirección, rutas instaladas y DNS recibido.
• El kill switch y la reconexión se comportan como se espera.
• HTTP_PROXY, HTTPS_PROXY, ALL_PROXY y la configuración de ProxyChains están vacíos o documentados.
• No quedan túneles SSH, SOCKS, port forwards o procesos de una sesión anterior.
• La desconexión no deja rutas o resolvers persistentes.

Comprueba los procesos y listeners locales antes de abrir los necesarios:

ss -lntup
env | grep -E '^(HTTP|HTTPS|ALL|NO)_PROXY='

En macOS usa lsof -nP -iTCP -sTCP:LISTEN. En Windows usa Get-NetTCPConnection -State Listen.

• La estructura de directorios del encargo existe y tiene permisos correctos.
• Notas, outputs originales, evidencia seleccionada y material temporal tienen ubicaciones distintas.
• El volumen está cifrado cuando el modelo de datos lo requiere.
• Hay espacio para capturas, escaneos y snapshots sin agotar el disco del host.
• La copia protegida tiene destino, frecuencia, retención y responsable.
• La restauración de un archivo de prueba se ha completado.

Un backup que nunca se ha restaurado es una hipótesis. La prueba mínima crea un archivo no sensible, ejecuta el mecanismo previsto, elimina la copia de trabajo y recupera el archivo en otra ruta. Registra hash, tiempos y ubicación.

• La cuenta puede capturar en la interfaz prevista o se ha preparado el privilegio necesario.
• La captura conserva timestamps, direcciones, puertos y tamaño suficiente para la pregunta técnica.
• El transcript de terminal guarda tanto comandos como output.
• Las herramientas que escriben archivos tienen una ruta explícita.
• La rotación evita llenar el volumen.
• Se ha comprobado que los logs no registran secretos en texto claro.

Antes de la actividad real, captura una conexión propia y comprueba que puede abrirse:

sudo tcpdump -i INTERFACE -c 20 -w readiness.pcap host VALIDATION_IP
capinfos readiness.pcap

-i selecciona la interfaz, -c 20 detiene la captura tras veinte paquetes, -w conserva los paquetes y el filtro limita la captura a la dirección de validación. Si capinfos no está disponible, abre el archivo con Wireshark o tcpdump -r readiness.pcap.

• Existe acceso a consola o recuperación fuera del canal que se está modificando.
• Se ha probado restaurar la VM, la configuración o el nodo desde la configuración base.
• El equipo sabe detener automatizaciones, listeners, túneles y capturas.
• Los contactos y criterios de parada están disponibles sin depender del mismo sistema.
• El procedimiento de limpieza enumera procesos, cuentas, claves, reglas, DNS, certificados, datos y recursos cloud.

La checklist termina con un registro firmado por quien la ejecutó:

engagement: ENGAGEMENT_ID
checked_at: 2026-07-28T09:30:00+02:00
operator: OPERATOR_ID
workstation: WORKSTATION_ID
network_origin: EXPECTED_SOURCE_IP
vpn_profile_hash: SHA256_REDACTED
time_source: NTP_SOURCE
dns_servers:
  - DNS_SERVER
storage_free_gib: 120
capture_test: evidence/readiness.pcap
restore_test: passed
exceptions: []
decision: go

Una excepción no se oculta marcando el control como completo. Se describe, se asigna un responsable y se registra la decisión de continuar, limitar o detener la actividad.

• NIST SP 800-115: Technical Guide to Information Security Testing and Assessment
• NIST SP 800-125: Guide to Security for Full Virtualization Technologies
• OpenVPN: Setting Up Routing
• Microsoft Learn: Windows Time Service tools and settings