Comandos en Background en Linux: Guía Práctica para Pentesters

—

Disclaimer legal:Todo lo descrito en este artículo debe aplicarse únicamente en entornos autorizados: máquinas de HackTheBox, TryHackMe, laboratorios propios o sistemas con permiso explícito por escrito. Ejecutar procesos en sistemas sin autorización es ilegal.

—

Dominar los **comandos en background en Linux** es una habilidad práctica imprescindible para cualquier pentester que trabaje con sesiones remotas y herramientas de larga duración. Si llevas tiempo en pentesting, ya conoces la situación: tienes una sesión SSH en una máquina comprometida, lanzas un escaneo largo con `nmap` o un fuzzer, y en cuanto cierras la terminal o se cae la conexión, el proceso muere. Todo el trabajo perdido. O peor — estás en medio de una auditoría con múltiples herramientas corriendo en paralelo y no puedes tener 15 terminales abiertas sin volverse loco.

La gestión de procesos en background no es un tema de administración de sistemas — es una habilidad operacional que diferencia a alguien que trabaja de forma caótica de alguien que mantiene control real sobre lo que está corriendo en un sistema.

Qué vas a aprender aquí:

Cómo mandar procesos al background y traerlos de vuelta
nohup y por qué es crítico en sesiones remotas
screen y tmux como solución real para sesiones persistentes
Flujos de trabajo concretos con herramientas de pentesting: nmap, gobuster, msfconsole
Los errores que yo cometí y que tú no tienes que repetir

**Qué necesitas saber antes:** Manejo básico de terminal Linux, familiaridad con bash, y haber usado SSH al menos un par de veces. Si estás empezando desde cero, primero lee nuestra [guía de comandos básicos de Linux para hackers](/comandos-basicos-linux-hackers).

—

Tabla de contenidos

¿Qué son los procesos en segundo plano y por qué te importan como pentester?
&, jobs, fg y bg: el control básico desde bash
nohup: el comando que salva auditorías remotas
disown: desvincula procesos que ya lanzaste
screen y tmux: sesiones persistentes para trabajo serio
Flujos de trabajo reales en pentesting con procesos en background
Errores comunes y cómo evitarlos
Próximos pasos
FAQ

—

¿Qué son los procesos en segundo plano y por qué te importan como pentester?

Cuando ejecutas un comando en la terminal, por defecto corre en **foreground**: bloquea tu shell hasta que termina. Para la mayoría de tareas del día a día eso está bien. Para pentesting, no.

Los procesos en background son procesos que corren desacoplados de tu terminal interactiva, permitiéndote seguir usando la shell mientras ellos trabajan. Conocer los comandos en background en Linux y gestionarlos correctamente es parte del flujo operacional en cualquier auditoría seria.

—

`&`, `jobs`, `fg` y `bg`: el control básico desde bash

El operador `&` al final de un comando lo manda directamente al background cuando lo lanzas:

bash
nmap -sV -p- 10.10.10.50 &

La shell te devuelve algo así:

[1] 4823

Eso es el **job number** entre corchetes y el **PID** del proceso. Puedes seguir usando la terminal mientras `nmap` trabaja. Para ver qué tienes corriendo en background:

bash
jobs -l

[1]+ 4823 Running nmap -sV -p- 10.10.10.50 & [2]- 4891 Running gobuster dir -u http://10.10.10.50 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt &

La columna de la izquierda es el job number, luego el PID, el estado y el comando. El `+` indica el job «actual» (el que `fg` traería por defecto) y el `-` el siguiente en la cola.

Para traer un proceso al foreground:

bash
fg %1 # trae el job número 1
fg %2 # trae el job número 2

Para mandar al background un proceso que ya está corriendo en foreground: `Ctrl+Z` lo pausa (estado `Stopped`) y luego:

bash
bg %1 # lo reanuda en background

El flujo típico que uso cuando me olvido de poner el `&`:

bash
# Lancé gobuster sin &, está bloqueando la terminal
# Ctrl+Z para pausarlo
^Z
[1]+ Stopped gobuster dir -u http://10.10.10.50 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt

# Lo mando al background
bg %1
[1]+ gobuster dir -u http://10.10.10.50 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt &

**Limitación que casi nadie menciona:** Estos jobs están vinculados a tu sesión de shell actual. Si cierras la terminal o se cae la conexión SSH, todos los jobs en background mueren igualmente. El `&` solo te da multitarea dentro de la sesión, no persistencia.

`nohup`: el comando que salva auditorías remotas

nohup (no hangup) hace exactamente lo que dice: le dice al proceso que ignore la señal SIGHUP. Cuando tu sesión SSH termina, el proceso sigue corriendo porque no responde a esa señal. Es uno de los comandos en background en Linux más importantes para trabajo remoto.

bash
nohup nmap -sV -p- 10.10.10.50 &

Por defecto, `nohup` redirige stdout y stderr a un archivo llamado `nohup.out` en el directorio actual. Para especificar tu propio archivo de salida:

bash
nohup nmap -sV -p- 10.10.10.50 > /tmp/nmap_resultado.txt 2>&1 &

El `2>&1` redirige stderr al mismo lugar que stdout — importante porque si no, los errores se pierden o van a `nohup.out` de todas formas.

Un ejemplo real de mi flujo cuando tengo que dejar un escaneo corriendo en una máquina de HTB antes de dormir:

bash
# Lanzo el escaneo completo con nohup
nohup nmap -sV -sC -p- --min-rate 5000 -oA /tmp/full_scan 10.10.11.200 > /tmp/nmap_log.txt 2>&1 &

# Verifico que arrancó
echo $! # PID del último proceso en background
ps aux | grep nmap

[1] 7432

kali 7432 99.0 0.8 123456 34567 pts/0 R 22:14 0:03 nmap -sV -sC -p- --min-rate 5000 -oA /tmp/full_scan 10.10.11.200

Cuando vuelves a conectarte por SSH al día siguiente, el proceso sigue corriendo (o ya terminó y tienes los resultados en `/tmp/full_scan.*`).

**Observación técnica propia:** Prefiero `nohup` combinado con `-oA` de nmap (que guarda en los tres formatos: normal, grepable y XML) en lugar de solo redirigir stdout. El motivo es que si el proceso termina inesperadamente, los archivos `.gnmap` y `.xml` ya tienen la información parcial parseada y son más fáciles de procesar con otras herramientas que el output raw de `nohup.out`. Con solo `> archivo.txt` pierdes el formato estructurado.

`disown`: desvincula procesos que ya lanzaste

Situación: lanzaste algo con & pero olvidaste el nohup, y ahora necesitas cerrar la terminal. disown elimina el job de la tabla de jobs de bash, lo que significa que cuando la shell termine, no le enviará SIGHUP al proceso.

bash# Proceso corriendo en backgroundjobs -l[1]+ 8901 Running gobuster dir -u http://10.10.10.50 -w /usr/share/wordlists/rockyou.txt &

# Verificamos que ya no aparece en jobs
jobs
# (output vacío)

# Pero sigue corriendo
ps aux | grep gobuster kali 8901 45.2 0.3 98765 12345 pts/0 R 22:30 2:15 gobuster dir -u http://10.10.10.50 -w /usr/share/wordlists/rockyou.txt

La diferencia entre `disown` y `nohup` es el momento de aplicación: `nohup` va antes de lanzar el proceso, `disown` va después. Ambos logran el mismo resultado en términos de supervivencia al cierre de sesión.

Para disownear todos los jobs de golpe:

bash
disown -a

`screen` y `tmux`: sesiones persistentes para trabajo serio

## `screen` y `tmux`: sesiones persistentes para trabajo serio {#screen-tmux}

nohup y disown son soluciones puntuales. Si vas a hacer pentesting real con múltiples herramientas corriendo en paralelo, necesitas un multiplexor de terminal. Estas herramientas llevan la gestión de comandos en background en Linux a otro nivel.

`screen`

There are screens on:
12345.pentest_htb (22/01/25 22:15:00) (Detached)
12389.enum_web (22/01/25 22:20:00) (Detached)
2 Sockets in /run/screen/S-kali.

screen crea sesiones de terminal virtuales que persisten independientemente de tu conexión SSH:

bash# Crear una sesión nueva con nombrescreen -S pentest_htb # Dentro de la sesión, lanzas tus herramientas normalmentenmap -sV -p- 10.10.11.200 # Para «despegarte» de la sesión sin matarla# Ctrl+A, luego D

`tmux` es más moderno, más configurable y tiene mejor soporte para dividir paneles. En mis auditorías actuales uso `tmux` por defecto:

bash
# Nueva sesión
tmux new -s recon

# Dividir la ventana horizontalmente (dos paneles)
# Ctrl+B, luego %

bash# Para reconectarte a una sesiónscreen -r pentest_htb

# Despegarse de la sesión
# Ctrl+B, luego D

# Listar sesiones
tmux ls

recon: 1 windows (created Wed Jan 22 22:15:00 2025)
exploit: 2 windows (created Wed Jan 22 22:30:00 2025)

# Dividir verticalmente# Ctrl+B, luego » # Cambiar entre paneles# Ctrl+B, luego flechas

Mi setup habitual en una auditoría: una sesión `tmux` llamada `recon` con tres paneles — uno para nmap, uno para gobuster/ffuf, y uno libre para comandos rápidos. Una sesión separada llamada `exploit` para Metasploit o exploits manuales.

Flujos de trabajo reales en pentesting con procesos en background

## Flujos de trabajo reales en pentesting con procesos en background {#flujos-trabajo}

Reconocimiento paralelo desde el primer momento

### Reconocimiento paralelo desde el primer momento

Mi setup habitual en una auditoría: una sesión tmux llamada recon con tres paneles — uno para nmap, uno para gobuster/ffuf, y uno libre para comandos rápidos. Una sesión separada llamada exploit para Metasploit o exploits manuales.

Aquí están los patrones que uso en máquinas reales, no ejemplos de libro:

Reconocimiento paralelo desde el primer momento

### Msfconsole en background durante explotación

Cuando tienes un listener de Metasploit esperando una shell reversa y necesitas hacer otras cosas:

bash
# Lanzas msfconsole en una sesión screen
screen -S msf msfconsole -q -x "use exploit/multi/handler; set PAYLOAD windows/x64/meterpreter/reverse_tcp; set LHOST 10.10.14.5; set LPORT 4444; run"

Monitorear el output de procesos en background

El truco que más uso: tail -f sobre el archivo de salida para seguir el progreso sin interrumpir el proceso:

bash# En un panel de tmux, sigo el progreso de gobustertail -f /tmp/gobuster.txt /admin (Status: 301) [Size: 315] [-> http://10.10.11.200/admin/]/images (Status: 301) [Size: 315] [-> http://10.10.11.200/images/]/login (Status: 200) [Size: 4523]/backup (Status: 403) [Size: 277]/api (Status: 301) [Size: 315] [-> http://10.10.11.200/api/]

La solución que implementé desde entonces: siempre uso `nohup` + `-oA` para nmap, y verifico que el proceso arrancó correctamente antes de cerrar la terminal:

Cuando tienes un listener de Metasploit esperando una shell reversa y necesitas hacer otras cosas:

Error 1: Usar `&` sin `nohup` en sesiones SSH remotas

# Ctrl+A, D para despegarte# Sigues trabajando en otra terminal# Cuando llegue la shell, te reconectasscreen -r msf

Error 2: Olvidar redirigir stderr con `nohup`

bash
# MAL: los errores van a nohup.out por defecto, mezclados
nohup gobuster dir -u http://10.10.10.50 -w wordlist.txt &

# BIEN: output limpio y separado
nohup gobuster dir -u http://10.10.10.50 -w wordlist.txt > /tmp/gobuster.txt 2>&1 &

Error 3: Perder el PID de un proceso en background y no poder matarlo

bashnohup nmap -sV -sC -p- –min-rate 5000 -oA /tmp/scan_$(date +%Y%m%d_%H%M) 10.10.11.200 > /tmp/nmap_$(date +%Y%m%d_%H%M).log 2>&1 & # Verificación inmediatasleep 2 && ps aux | grep nmap | grep -v grep

### Error 3: Perder el PID de un proceso en background y no poder matarlo

Lanzas algo, cierras la terminal, vuelves a conectarte y no recuerdas el PID. Si usaste `nohup`, el proceso sigue corriendo pero no aparece en `jobs`.

bash
# Encontrar el proceso por nombre
ps aux | grep nmap

Errores comunes y cómo evitarlos

Error 1: Usar & sin nohup en sesiones SSH remotas

Ya lo mencioné, pero vale la pena repetirlo porque es el error más frecuente. Si tu sesión SSH termina (timeout, VPN caída, cierre accidental de terminal), todos los procesos con & mueren. Siempre usa nohup cuando el proceso deba sobrevivir al cierre de sesión.

bash
# MAL: sesiones sin nombre, difícil saber cuál es cuál
screen
tmux new

# BIEN: nombres descriptivos
screen -S recon_htb_scrambled
tmux new -s exploit_phase

Cuando tienes tres sesiones de `screen` sin nombre y llevas 6 horas en una auditoría, distinguirlas por PID es un dolor innecesario.

Próximos pasos

Si este flujo de trabajo con comandos en background en Linux te resulta útil, estos son los temas que lógicamente vienen después:

2. **[Redirección y pipes en bash para pentesters](/redireccion-pipes-bash-pentesters)** — La combinación de `|`, `>`, `>>`, `2>&1` y herramientas como `tee` es lo que convierte comandos individuales en pipelines de análisis. Directamente relacionado con cómo manejas el output de tus procesos en background.

¿Cuál es la diferencia entre `nohup` y `disown`?

## FAQ {#faq}

¿Puedo ver el output de un proceso que mandé al background con `&`?

`nohup` se usa antes de lanzar el proceso y hace que el proceso ignore la señal `SIGHUP` desde el inicio. `disown` se usa después de que el proceso ya está corriendo en background — lo elimina de la tabla de jobs de bash, así que cuando la shell termina, no le envía `SIGHUP`. El resultado práctico es similar, pero `disown` es tu salvavidas cuando olvidaste usar `nohup` al principio.

bashnohup nmap -sV -p- 10.10.11.200 > /tmp/nmap.txt 2>&1 &
echo $! > /tmp/nmap.pid
cat /tmp/nmap.pid
# 7432

Sí, si redirigiste el output a un archivo puedes hacer `tail -f archivo.txt`. Si no redirigiste nada, el output del proceso en background aparecerá mezclado en tu terminal actual de forma desordenada — lo que es molesto pero no impide ver los resultados. La práctica correcta es siempre redirigir: `comando > /tmp/output.txt 2>&1 &`.

`tmux` en casi todos los casos. Tiene mejor soporte para dividir paneles, mejor documentación, scripting más sencillo y está activamente mantenido. `screen` sigue siendo útil cuando estás en un sistema donde no puedes instalar nada (`screen` viene preinstalado en más distribuciones). En Kali y Parrot, instala `tmux` y aprende sus atajos — vale la inversión de tiempo.

Presiona ESC para cerrar