Entorno de trabajo reproducible

Un entorno reproducible puede reconstruirse desde una fuente conocida y deja constancia de qué se instaló. La personalización no es el objetivo principal. Una terminal, un editor o un tema pueden cambiar sin alterar el procedimiento, mientras que una dependencia sin versión o un instalador sin procedencia sí cambia el resultado.

La configuración base (baseline) es una instalación mínima, actualizada y validada. No contiene datos de cliente, historiales de otros laboratorios ni herramientas añadidas para un caso concreto. A partir de ella se crea una VM o un volumen de trabajo que sí puede cambiar durante la actividad.

Esta separación permite retirar la copia de trabajo sin perder la receta de construcción. También evita convertir una snapshot antigua en la única forma de recuperar el sistema.

Guarda los manifest y scripts fuera de la imagen que reconstruyen. Si el disco virtual se pierde, la receta debe seguir disponible.

Linux es una base frecuente para herramientas de red, automatización y utilidades Unix. Windows aporta comportamiento nativo para PowerShell, Active Directory, SMB, autenticación integrada y herramientas que dependen de APIs del sistema. Mantener ambas estaciones tiene sentido cuando la evaluación necesita esas dos perspectivas.

WSL 2 combina herramientas Linux con un host Windows y resulta útil para desarrollo o administración. No sustituye una VM dedicada cuando el propósito es separar código, credenciales y red del host. Aislamiento y virtualización desarrolla esa frontera.

Un nodo remoto añade un origen de red estable o presencia en otra región. No debería convertirse por defecto en el almacén de evidencia. Antes de aprovisionarlo, registra imagen, región, direcciones, consola de recuperación, identidad administrativa, cifrado disponible, retención del proveedor y procedimiento de retirada. Las tablas de precios y productos caducan demasiado rápido para formar parte de la configuración base.

En Debian y derivados, apt-mark showmanual enumera los paquetes marcados como instalados manualmente. LC_ALL=C fija un orden de clasificación estable y sort guarda la lista ordenada:

LC_ALL=C apt-mark showmanual | sort > packages-apt.txt

Esa lista no conserva versiones ni garantiza que todos los paquetes procedan del mismo repositorio. dpkg-query -W consulta los paquetes instalados. El formato imprime nombre y versión separados por una tabulación:

LC_ALL=C dpkg-query -W -f='${binary:Package}\t${Version}\n' |
  sort > packages-dpkg.tsv

La primera lista ayuda a reconstruir la intención. La segunda permite comparar el estado exacto. No alimentes directamente apt install con un archivo que no hayas revisado. Los comentarios, nombres retirados, cambios de repositorio y arquitecturas diferentes exigen adaptar el manifiesto.

En Windows, Windows Package Manager puede exportar las aplicaciones que consigue asociar con sus orígenes. --output define el archivo JSON y --include-versions añade la versión instalada:

winget export --output packages-winget.json --include-versions

El comando avisa cuando no puede relacionar una aplicación instalada con un package identifier. Revisa esos avisos y registra por separado controladores, características opcionales, módulos de PowerShell y herramientas portables.

Un orden de preferencia práctico es:

1. repositorio firmado del sistema o del fabricante
2. release oficial con firma o checksum publicado por otro canal
3. código fuente revisado y fijado a un tag o commit
4. instalador remoto solo después de descargarlo, inspeccionarlo y verificarlo.

curl URL | sh y su equivalente con Invoke-Expression ocultan el artefacto que se ejecuta y hacen que la misma receta pueda entregar código distinto mañana. Descargar primero no garantiza legitimidad, pero permite conservar el hash, revisar el contenido y repetir exactamente la entrada.

Para una herramienta clonada con Git, registra el commit resuelto desde su directorio. -C indica a Git dónde operar y rev-parse HEAD imprime el identificador del commit actual:

git -C tools/TOOL rev-parse HEAD

Para reconstruir esa revisión, checkout selecciona el objeto indicado. --detach evita asociar el directorio de trabajo a una rama móvil y COMMIT_SHA representa el identificador completo que registraste:

git -C tools/TOOL checkout --detach COMMIT_SHA

Un tag aporta un nombre legible, pero solo una firma verificada relaciona ese tag con una identidad en la que confías. Define en el manifest si has verificado firma, checksum o ambos.

Las dependencias de lenguaje deben quedar fuera del Python o Node global cuando el ecosistema admita entornos aislados. En Python, -m venv ejecuta el módulo que crea el entorno a partir del intérprete actual y .venv es el directorio de destino:

python3 -m venv .venv

La carpeta .venv no es portable. Conserva el archivo de dependencias y la versión del intérprete para poder recrearla.

Un manifiesto Compose describe contenedores, redes, volúmenes y archivos montados. Antes de arrancarlo, config --quiet analiza y valida la configuración resuelta. --project-name PROJECT_NAME fija el namespace de los recursos. --file COMPOSE_FILE evita depender del directorio actual:

docker compose \
  --project-name PROJECT_NAME \
  --file COMPOSE_FILE \
  config --quiet

docker compose \
  --project-name PROJECT_NAME \
  --file COMPOSE_FILE \
  up --detach --wait

--detach deja los contenedores en segundo plano. --wait espera a que estén en ejecución o saludables y activa ese modo. Después, ps muestra el estado resuelto y logs --since START_TIME acota el diagnóstico al periodo relevante:

docker compose \
  --project-name PROJECT_NAME \
  --file COMPOSE_FILE \
  ps

docker compose \
  --project-name PROJECT_NAME \
  --file COMPOSE_FILE \
  logs --since START_TIME

El procedimiento de retirada debe utilizar el mismo nombre y archivo. down --remove-orphans retira contenedores y redes del proyecto, incluidos servicios que ya no aparecen en el manifiesto. Añade --volumes únicamente cuando esos volúmenes sean desechables y la pérdida esté prevista:

docker compose \
  --project-name PROJECT_NAME \
  --file COMPOSE_FILE \
  down --remove-orphans

Un up correcto demuestra que Docker alcanzó el estado declarado. La comprobación funcional sigue siendo una petición o interacción con el servicio. Conserva la salida de docker version y docker compose version, los digests de imagen y el hash del manifiesto cuando condicionen la reproducción.

No encadenes una actualización completa, la retirada automática de paquetes y la limpieza de caché sin inspeccionar qué propone el gestor. Antes de una nueva evaluación:

1. clona la configuración base o crea un punto de reversión
2. actualiza índices y revisa cambios propuestos
3. aplica actualizaciones del sistema y reinicia cuando corresponda
4. actualiza las herramientas en grupos pequeños
5. ejecuta las comprobaciones del entorno
6. registra las versiones y crea una nueva configuración base

Una herramienta que cambia durante un encargo puede alterar la sintaxis, el tráfico o el procesamiento. Conserva la versión funcional hasta validar la nueva y documenta cualquier actualización necesaria durante el trabajo.

En Windows, una detección de Microsoft Defender no se resuelve creando exclusiones amplias para Downloads, repositorios o carpetas temporales. Cada exclusión elimina cobertura para esa ruta. Si una herramienta necesita un tratamiento distinto, usa una VM dedicada, reduce la exclusión al archivo y contexto necesarios, registra el motivo y retírala después.

La validación comprueba comportamiento, no solo que los binarios existan:

• fecha, hora, zona horaria y sincronización
• DNS, rutas, proxy y resolución dentro de la VM
• VPN y origen de red esperado
• versiones de las herramientas esenciales
• creación y lectura de outputs en la estructura de trabajo
• acceso al gestor de secretos sin copiar secretos al manifiesto
• integraciones del hipervisor y dispositivos desactivados o justificados
• ausencia de datos de otro laboratorio o encargo

Haz la prueba con sistemas propios. La configuración base no necesita descubrir nada para demostrar que su red, la captura de outputs y las herramientas básicas funcionan.

Prueba una reconstrucción periódica en una VM vacía. Si depende de una cuenta olvidada, un enlace que ya no existe o una clave guardada dentro de la imagen original, la configuración base no es reproducible.

Cuando la restauración falla, conserva el punto exacto en el que se detuvo y separa la causa. Un paquete ausente exige revisar el repositorio o la versión fijada. Una credencial caducada pertenece al procedimiento de recuperación de secretos. Un servicio que arranca pero no supera su comprobación funcional indica que la receta recreó procesos, aunque todavía no haya recreado el sistema útil. Esa diferencia evita responder a todos los fallos restaurando otra snapshot de origen incierto.

La continuidad y recuperación explica RTO, RPO y pruebas de restauración. En un entorno de pentesting, la recuperación también debe respetar la separación y retención definidas para los datos del encargo.

Elige terminal, shell, editor y multiplexor por compatibilidad, accesibilidad, consumo medido y capacidad de restaurar sesiones. Tmux resulta útil en conexiones SSH porque la sesión puede desacoplarse y continuar en el servidor. Un multiplexor integrado en un emulador local no proporciona por sí solo esa persistencia remota.

Versiona dotfiles y atajos solo después de entenderlos. No guardes tokens, claves privadas, historial ni rutas de cliente en ese repositorio. Si una personalización añade latencia o requiere una cadena larga de plugins, debe poder desactivarse sin impedir el trabajo.

• Debian manpages: apt-mark(8)
• Microsoft Learn: export command for WinGet
• Microsoft Learn: Exclusions in Microsoft Defender Antivirus
• Python documentation: venv
• Git documentation: Signing your work
• tmux: Getting Started
• CISA: StopRansomware Guide
• Docker Compose CLI reference