SantiFP: Prácticas SOM

Mostrando entradas con la etiqueta Prácticas SOM. Mostrar todas las entradas

Se ha borrado accidentalmente información importante de un disco externo

Objetivo:

Comprender y ejecutar los protocolos técnicos de recuperación de datos tras un borrado o pérdida accidental en un disco duro externo, aprendiendo a realizar un diagnóstico del dispositivo, emplear herramientas especializadas de rescate lógico y elaborar un informe estructurado de actuación.

Escenario:

Herramientas: Terminal Linux, utilidades de análisis de almacenamiento (lsblk, fdisk), herramientas de recuperación forense y lógica (testdisk, photorec o ddrescue), y procesador de textos para el informe.
Conceptos analizados: Estructura de sistemas de archivos, recuperación de tablas de particiones, persistencia de datos borrados en bloques no sobrescritos y cadena de custodia en la manipulación de soportes.
Proceso clave: Conexión segura y aislamiento del disco afectado (evitando escrituras), diagnóstico del estado físico/lógico, clonación de seguridad o escaneo directo para la recuperación de ficheros y documentación del incidente.

Escenario Real: Borrado accidental de documentación en soporte externo

Un usuario ha eliminado por error una partición entera y varios ficheros críticos de diseño en un disco duro externo USB antes de realizar el traslado a un cliente. Como técnico de soporte e incidencias, debes conectar el dispositivo bajo estrictas normas de precaución para evitar sobrescrituras, diagnosticar el alcance de los daños, recuperar la mayor cantidad posible de información y redactar un informe profesional de actuación.

Por defecto, cuando se elimina un archivo o una partición en un sistema de archivos, el sistema operativo no borra físicamente los bits, sino que marca el espacio como disponible. Actuar con rapidez y evitar escribir nuevos datos en el soporte es el factor determinante para una recuperación exitosa.

NOTA: Para realizar esta práctica con total seguridad, utiliza un disco duro externo de pruebas o una imagen virtual en la que simularás el borrado accidental, evitando manipular soportes con información real de valor crítico sin una copia previa.

Instrucciones:

Fase 1: Conexión segura y diagnóstico del dispositivo de almacenamiento:

Conectar el disco externo al equipo de diagnóstico y listar las unidades conectadas asegurándose de no montarlo en modo lectura/escritura automático para evitar alteraciones: lsblk
Identificar el nombre del dispositivo asignado por el kernel (ej. /dev/sdb) y comprobar su tabla de particiones: sudo fdisk -l /dev/sdb

Fase 2: Creación de una imagen de respaldo (Clonación forense de seguridad):

Para prevenir daños irreversibles durante el proceso de recuperación, realizar una copia sector a sector del disco afectado utilizando la herramienta ddrescue o dd hacia un almacenamiento seguro del equipo anfitrión:
```
sudo ddrescue -d -r3 /dev/sdb /home/usuario/imagen_disco_externo.img /home/usuario/rescue.log
```

Fase 3: Análisis y ejecución del proceso de recuperación de datos:

Ejecutar una herramienta de recuperación especializada (como testdisk para particiones perdidas o photorec para recuperación de ficheros por firma) apuntando a la imagen clonada o directamente al disco de pruebas:
```
sudo testdisk /home/usuario/imagen_disco_externo.img
```
Seleccionar el tipo de tabla de particiones, analizar la estructura lógica y proceder a la copia o restauración de los ficheros rescatados hacia un directorio de destino seguro y ajeno al disco dañado.

Fase 4: Elaboración del informe de actuación e incidentes:

Redactar un informe técnico detallando cronológicamente las acciones realizadas: identificación del soporte, estado inicial detectado, metodología de clonación aplicada, porcentaje de ficheros recuperados con éxito y recomendaciones preventivas futuras (como copias automatizadas y redundancia).

Verificación:

Comprobar en el directorio de destino que los archivos rescatados se encuentran íntegros, son accesibles y pueden abrirse correctamente sin corrupción de datos.
Verificar que el informe técnico recoge de manera clara y formal todas las evidencias del proceso de recuperación.

Posibles errores y resolución de problemas:

Si al intentar realizar el análisis de recuperación con TestDisk o PhotoRec observas que el sistema devuelve un error indicando que No space left on device, se debe a que estás intentando volcar los ficheros recuperados en la misma partición o disco que estás intentando escanear.

Solución: Configura siempre la ruta de destino de los archivos recuperados en un directorio independiente perteneciente al disco principal del equipo de diagnóstico (ej. /home/usuario/recuperados/).

Alternativa directa: Verificación rápida de la estructura del disco

Si necesitas comprobar de forma instantánea el estado de conexión y los puntos de montaje disponibles asociados a los dispositivos USB externos conectados al equipo de trabajo, puedes ejecutar el comando:

lsusb && df -h

Preguntas de reflexión:

¿Por qué es una norma estricta evitar escribir o guardar nuevos datos en un disco duro externo inmediatamente después de haber borrado información importante por error?
¿Qué diferencia técnica fundamental existe entre recuperar una partición borrada mediante testdisk frente a recuperar archivos sueltos por su firma mediante photorec?
¿Qué importancia tiene realizar una clonación sector a sector (imagen de disco) antes de manipular un soporte de almacenamiento dañado o con datos perdidos?
¿Qué información clave debe contener obligatoriamente un informe técnico post-incidente tras finalizar un proceso de recuperación de datos para una organización?

Haz clic aquí para ver las soluciones y explicaciones

1. ¿Por qué es una norma estricta evitar escribir o guardar nuevos datos en un disco duro externo inmediatamente después de haber borrado información importante por error?

Porque cuando se borra un archivo, el sistema operativo solo libera los punteros o inodos que referencian su ubicación, dejando los datos reales intactos en los bloques del disco. Si se escriben nuevos ficheros en ese soporte, el sistema reutilizará dichos bloques libres para almacenar la nueva información, sobrescribiendo de forma definitiva y permanente los datos originales que se deseaban recuperar.

2. ¿Qué diferencia técnica fundamental existe entre recuperar una partición borrada mediante `testdisk` frente a recuperar archivos sueltos por su firma mediante `photorec`?

TestDisk está diseñado para reconstruir tablas de particiones y recuperar sectores de arranque dañados o eliminados, restaurando la estructura lógica completa de los directorios con sus nombres originales y metadatos. Por el contrario, PhotoRec ignora la estructura del sistema de archivos y escanea el disco en busca de firmas binarias características de los ficheros (como cabeceras de JPG, PDF, DOCX), extrayendo la información en bruto pero perdiendo los nombres de archivo originales y la jerarquía de carpetas.

3. ¿Qué importancia tiene realizar una clonación sector a sector (imagen de disco) antes de manipular un soporte de almacenamiento dañado o con datos perdidos?

Garantiza la preservación de la evidencia o estado original del dispositivo (cadena de custodia). Trabajar directamente sobre el disco original conlleva el riesgo de que un fallo mecánico imprevisto o un comando erróneo durante las pruebas de recuperación destruya definitivamente la información restante. Al clonar la unidad, todas las operaciones de análisis y pruebas se ejecutan sobre un fichero de imagen seguro.

4. ¿Qué información clave debe contener obligatoriamente un informe técnico post-incidente tras finalizar un proceso de recuperación de datos para una organización?

Debe incluir los datos identificativos del soporte afectado, una descripción detallada de la causa de la pérdida, la cronología de las herramientas y comandos utilizados durante el diagnóstico, un resumen cuantitativo y cualitativo de los datos recuperados con éxito, y una sección de recomendaciones preventivas para evitar que el incidente vuelva a producirse en el futuro.

Un servidor presenta un consumo anómalo de CPU y memoria

Objetivo:

Diagnosticar y resolver una incidencia crítica de rendimiento en un servidor que experimenta un consumo anómalo y sostenido de CPU y memoria, aprendiendo a identificar procesos consumidores, auditar registros del sistema, aislar servicios desbocados y aplicar medidas correctoras efectivas.

Escenario:

Herramientas: Terminal Linux, comandos top, htop, ps, journalctl, y gestión de prioridades con renice / kill.
Conceptos analizados: Fugas de memoria (memory leaks), procesos zombis o huérfanos, bucles de ejecución en servicios web o bases de datos, y prioridades de planificación del kernel (valores nice).
Proceso clave: Detección del cuello de botella global, identificación del PID (Process ID) responsable, inspección de logs asociados, parada o limitación del recurso desbocado y verificación de la estabilización del servidor.

Escenario Real: Servidor colapsado por un proceso desbocado

Un servidor crítico de aplicaciones muestra una carga del procesador al 100% y la memoria RAM completamente agotada, provocando que el acceso remoto por SSH sea extremadamente lento o inestable. Como administrador de sistemas, debes realizar una intervención de urgencia para identificar qué proceso o demonio está consumiendo los recursos de forma anómala, auditar los registros para descubrir la causa y aplicar las medidas correctoras para recuperar la normalidad.

Por defecto, los servidores pueden sufrir caídas de rendimiento debido a procesos mal programados, ataques de denegación de servicio (DoS) locales o bucles infinitos en aplicaciones web. Saber aislar el origen del consumo excesivo es una habilidad fundamental de administración.

NOTA: Para realizar esta práctica de diagnóstico con seguridad, evita eliminar procesos críticos del núcleo del sistema (como systemd o kswapd) cuyo cierre forzoso provocaría un bloqueo total del servidor.

Instrucciones:

Fase 1: Detección global de la carga y uso de recursos:

Comprobar la carga media del sistema (Load Average) y el consumo porcentual general de CPU y memoria en tiempo real: top (o pulsar htop para una interfaz visual más avanzada).
Ordenar los procesos activos de manera interactiva pulsando la tecla P (por uso de CPU) o M (por uso de memoria) para identificar los candidatos sospechosos.

Fase 2: Identificación precisa del proceso y sus metadatos:

Listar los procesos del sistema filtrando aquellos que devoren más recursos mediante el comando ps con formato personalizado:
```
ps aux --sort=-%cpu,%mem | head -n 10
```
Anotar el identificador del proceso (PID), el usuario propietario, el tiempo de ejecución y la ruta del binario en ejecución.

Fase 3: Auditoría de registros (logs) asociados al servicio:

Inspeccionar el registro del sistema o los logs específicos del demonio sospechoso para descubrir errores recurrentes, excepciones o avisos de falta de memoria (Out Of Memory): sudo journalctl -u [nombre_servicio] -n 50 --no-pager
Comprobar si el kernel ha lanzado avisos de OOM killer en el búfer general: dmesg -T | grep -i oom

Fase 4: Aplicación de medidas correctoras y mitigación:

Si el proceso responde, intentar una parada controlada mediante systemctl o enviar una señal de terminación limpia al PID: sudo kill -15 [PID]
Si el proceso está congelado y continúa devorando los recursos, forzar su cierre inmediato: sudo kill -9 [PID]
Si se trata de un servicio legítimo sobrecargado, ajustar su prioridad de ejecución en el procesador utilizando un valor nice positivo o reiniciar el demonio correspondiente.

Verificación:

Comprobar mediante top o htop que la carga media del procesador ha descendido a valores nominales y que el consumo de memoria se ha estabilizado.
Verificar que los servicios principales de la aplicación operan con normalidad tras la eliminación del proceso anómalo.

Posibles errores y resolución de problemas:

Si al intentar finalizar un proceso desbocado mediante el comando kill el sistema devuelve un error indicando que Operation not permitted, se debe a que estás ejecutando el comando con una cuenta de usuario sin privilegios suficientes para gestionar procesos de otros usuarios o del sistema.

Solución: Eleva tus privilegios ejecutando la orden anteponiendo el comando de administración, por ejemplo: sudo kill -9 [PID].

Alternativa directa: Visualización rápida de los procesos más pesados

Si necesitas obtener una lista instantánea y limpia de los procesos que más memoria RAM están absorbiendo sin interactuar con herramientas de pantalla completa como htop, puedes ejecutar el comando optimizado:

ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%mem | head -n 6

Preguntas de reflexión:

¿Qué diferencia técnica existe entre enviar una señal de terminación suave (SIGTERM o kill -15) frente a una señal de cierre forzoso (SIGKILL o kill -9) a un proceso desbocado?
¿Cómo influye una fuga de memoria (memory leak) en el rendimiento a largo plazo de un servidor hasta obligar al kernel a actuar mediante el mecanismo OOM Killer?
¿Qué significado técnico aportan los tres valores que componen la carga media del sistema (Load Average) en intervalos de 1, 5 y 15 minutos?
¿Qué utilidad aporta modificar la prioridad de planificación (valores nice) de un proceso pesado en un servidor multitarea saturado?

Haz clic aquí para ver las soluciones y explicaciones

1. ¿Qué diferencia técnica existe entre enviar una señal de terminación suave (`SIGTERM` o `kill -15`) frente a una señal de cierre forzoso (`SIGKILL` o `kill -9`) a un proceso desbocado?

La señal SIGTERM (15) solicita amablemente al proceso que finalice su ejecución, dándole la oportunidad de liberar recursos abiertos, cerrar conexiones de red y guardar ficheros temporales de forma limpia. Por el contrario, la señal SIGKILL (9) es interceptada directamente por el kernel del sistema operativo, el cual detiene y elimina el proceso de inmediato sin permitirle realizar ninguna tarea de limpieza previa.

2. ¿Cómo influye una fuga de memoria (memory leak) en el rendimiento a largo plazo de un servidor hasta obligar al kernel a actuar mediante el mecanismo OOM Killer?

Una fuga de memoria ocurre cuando una aplicación solicita bloques de RAM al sistema operativo pero olvida liberarlos al terminar sus tareas, haciendo que su consumo crezca de manera constante con el tiempo. Cuando la memoria física y el espacio de intercambio (swap) se agotan por completo, el kernel activa el mecanismo OOM (Out Of Memory) Killer para asesinar de forma automática al proceso que más recursos consume con el fin de evitar un bloqueo general del servidor.

3. ¿Qué significado técnico aportan los tres valores que componen la carga media del sistema (Load Average) en intervalos de 1, 5 y 15 minutos?

Representan el número medio de procesos que se encuentran en estado ejecutable (utilizando la CPU) o en espera ininterrumpida de recursos (como operaciones de E/S de disco) durante los últimos 1, 5 y 15 minutos. Comparar estos tres valores permite discernir si un pico de carga es un evento puntual y transitorio o un problema estructural sostenido en el tiempo.

4. ¿Qué utilidad aporta modificar la prioridad de planificación (valores nice) de un proceso pesado en un servidor multitarea saturado?

Los valores nice oscilan generalmente entre -20 (máxima prioridad) y 19 (mínima prioridad). Asignar un valor positivo alto a un proceso secundario pesado pero no urgente permite degradar su prioridad en la cola del procesador, cediendo de manera justa los ciclos de cálculo de la CPU a los servicios críticos de la organización.

Un equipo público de biblioteca debe quedar protegido frente a un uso indebido

Objetivo:

Comprender y aplicar los mecanismos de endurecimiento (hardening) y protección de un equipo informático de acceso público (como el de una biblioteca), aprendiendo a restringir privilegios de usuario, configurar políticas estrictas de contraseñas, activar sistemas de cortafuegos y establecer mecanismos de restauración automática del entorno ante modificaciones no deseadas.

Escenario:

Herramientas: Terminal Linux, gestores de usuarios y grupos, configuración de iptables / UFW, herramientas de control de acceso y software de congelación de estado (o políticas de sesión invitada).
Conceptos analizados: Principio de mínimo privilegio, restricciones de inicio de sesión, reglas de filtrado de paquetes de red, bloqueo de interfaces de administración y sistemas de persistencia temporal (Ephemeral / Deep Freeze).
Proceso clave: Creación de un usuario público con privilegios limitados, establecimiento de restricciones en el perfil, configuración de reglas de cortafuegos corporativo, bloqueo de accesos físicos/remotos y congelación del sistema de ficheros.

Escenario Real: Estación de consulta pública expuesta a manipulación

Una biblioteca municipal habilita varios ordenadores para el uso libre de los ciudadanos en la consulta de catálogos e internet. Sin embargo, los usuarios tienden a descargar software no deseado, modificar configuraciones de red o dejar sesiones abiertas con datos personales. Como administrador de sistemas, debes blindar los equipos configurando cuentas restringidas, cerrando puertos innecesarios en el cortafuegos y asegurando que cualquier cambio realizado en el sistema desaparezca automáticamente al reiniciar.

Por defecto, los sistemas operativos vienen configurados con un enfoque abierto y flexible para entornos de escritorio domésticos o de oficina, lo cual resulta totalmente inseguro en un entorno público expuesto a usuarios malintencionados o descuidados.

NOTA: Para realizar esta práctica con total seguridad, asegúrate de aplicar las restricciones sobre una cuenta de usuario de pruebas secundaria, evitando bloquear tu propio usuario administrador de la sesión principal.

Instrucciones:

Fase 1: Creación del usuario público restringido:

Crear una cuenta de usuario específica para el público (ej. usuario_publico) limitando su acceso a la shell y asignándole un directorio personal controlado:
```
sudo useradd -m -s /bin/bash usuario_publico
sudo passwd usuario_publico
```
Verificar rigurosamente que este usuario no pertenece al grupo sudo ni dispone de permisos para elevar privilegios mediante comandos administrativos.

Fase 2: Aplicación de políticas de contraseñas y caducidad:

Configurar políticas estrictas de caducidad de claves y restricciones de complejidad para las cuentas del sistema modificando los parámetros en /etc/login.defs o mediante el comando chage:
```
sudo chage -M 90 -m 7 -W 14 usuario_publico
```

Fase 3: Configuración del cortafuegos y bloqueo de servicios de red:

Activar el cortafuegos del sistema (UFW) y establecer una política por defecto restrictiva que bloquee todo el tráfico entrante no autorizado:
```
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
```
Deshabilitar servicios de acceso remoto innecesarios (como SSH o compartición de ficheros local) si la estación no requiere soporte remoto directo.

Fase 4: Restricción de software y protección del entorno:

Bloquear el acceso a las terminales de comandos (Ctrl+Alt+F1 a F6) o a los menús de configuración del sistema mediante las políticas del entorno de escritorio (GNOME/KDE) o herramientas de control parental/políticas de grupo.
Configurar un sistema de sesión invitada o persistencia temporal (o herramientas de congelación de disco como OverlayFS / Deep Freeze) para que cualquier fichero descargado o alteración del sistema se elimine de forma automática al apagar o reiniciar el equipo.

Verificación:

Iniciar sesión con la cuenta usuario_publico y comprobar que no es posible ejecutar comandos de administración ni acceder a particiones protegidas.
Verificar mediante sudo ufw status verbose que el cortafuegos se encuentra activo y bloquea las conexiones entrantes no deseadas.

Posibles errores y resolución de problemas:

Si tras configurar las restricciones en el perfil del usuario público, descubres que este todavía puede ejecutar comandos administrativos utilizando el comando sudo, se debe a un error en la asignación de grupos suplementarios durante la creación de la cuenta.

Solución: Comprueba los grupos a los que pertenece el usuario ejecutando groups usuario_publico y elimínalo inmediatamente del grupo sudo o wheel mediante sudo gpasswd -d usuario_publico sudo.

Alternativa directa: Comprobación rápida del estado del cortafuegos

Si necesitas verificar de manera inmediata qué puertos se encuentran abiertos y si el cortafuegos de la biblioteca está protegiendo correctamente la estación de trabajo frente a intrusiones externas, puedes ejecutar:

sudo ufw status numbered

Preguntas de reflexión:

¿Por qué es fundamental aplicar el principio de mínimo privilegio creando cuentas de usuario totalmente desacopladas del grupo de administración en equipos informáticos de acceso público?
¿Qué ventajas de seguridad aporta configurar una política de cortafuegos restrictiva que bloquee todo el tráfico entrante por defecto en una estación de biblioteca?
¿Cómo actúan a nivel técnico los sistemas de congelación de estado (como OverlayFS o sistemas efímeros) para garantizar que el equipo vuelva a su estado original tras cada reinicio?
¿Qué riesgos implica para la privacidad de los usuarios y la seguridad de la red que un equipo público mantenga activos servicios de acceso remoto como SSH o escritorios compartidos sin restricciones?

Haz clic aquí para ver las soluciones y explicaciones

1. ¿Por qué es fundamental aplicar el principio de mínimo privilegio creando cuentas de usuario totalmente desacopladas del grupo de administración en equipos informáticos de acceso público?

Porque los usuarios públicos pueden tener intenciones maliciosas o cometer errores por desconocimiento. Si una persona accede con una cuenta con privilegios administrativos, podría instalar programas maliciosos (malware), modificar la configuración de red, borrar ficheros esenciales del sistema operativo o comprometer la seguridad de toda la red de la institución.

2. ¿Qué ventajas de seguridad aporta configurar una política de cortafuegos restrictiva que bloquee todo el tráfico entrante por defecto en una estación de biblioteca?

Garantiza que ningún agente externo en la red pueda realizar escaneos de puertos ni intentar conexiones no solicitadas hacia los servicios internos de la estación de trabajo. Al permitir únicamente el tráfico saliente necesario para la navegación web (HTTP/HTTPS), se minimiza drasticamente la superficie de exposición a ataques de red.

3. ¿Cómo actúan a nivel técnico los sistemas de congelación de estado (como OverlayFS o sistemas efímeros) para garantizar que el equipo vuelva a su estado original tras cada reinicio?

Montan el sistema de ficheros raíz en modo de solo lectura y superponen una capa temporal en memoria RAM o en un almacenamiento volátil (Copy-on-Write). Cualquier modificación, descarga o eliminación que realice el usuario público durante su sesión se almacena únicamente en esa capa efímera, la cual se destruye por completo al apagar o reiniciar el equipo, dejando el sistema base intacto.

4. ¿Qué riesgos implica para la privacidad de los usuarios y la seguridad de la red que un equipo público mantenga activos servicios de acceso remoto como SSH o escritorios compartidos sin restricciones?

Deja una puerta abierta para que atacantes externos puedan adivinar credenciales mediante ataques de fuerza bruta, secuestrar la sesión del equipo o utilizar la estación como nodo intermediario para lanzar ataques informáticos hacia otros sistemas corporativos de la red de la biblioteca.

Un equipo nuevo debe quedar preparado para un empleado

Objetivo:

Comprender y dominar el proceso integral de aprovisionamiento y puesta a punto de un equipo informático nuevo para su entrega a un empleado, abarcando desde el particionamiento avanzado del almacenamiento y la instalación del sistema operativo hasta la creación de cuentas de usuario seguras, despliegue de software corporativo y configuración de políticas de copias de seguridad.

Escenario:

Herramientas: Medio de instalación USB del sistema operativo, asistente de particionado, terminal Linux para gestión de usuarios y paquetes, y herramientas de automatización de respaldos.
Conceptos analizados: Esquemas de particionado (particiones raíz, home y swap), creación de usuarios con privilegios acotados, despliegue de software esencial mediante gestores de paquetes y automatización de respaldos mediante tareas programadas (cron).
Proceso clave: Preparación del almacenamiento, instalación desatendida o asistida del sistema, configuración de credenciales del empleado, instalación de herramientas de productividad y establecimiento de un plan de backup periódico.

Escenario Real: Preparación integral de una estación de trabajo corporativa

Un nuevo empleado se incorpora al departamento técnico y requiere una estación de trabajo configurada desde cero bajo estrictos estándares de seguridad y productividad. Como administrador de sistemas, debes realizar todo el ciclo de aprovisionamiento: estructurar los discos de manera profesional, instalar el sistema operativo, crear su cuenta de usuario sin privilegios innecesarios, instalar el software ofimático y de desarrollo requerido, y programar copias de seguridad automáticas de sus documentos.

Por defecto, entregar un equipo sin una estructura de particiones organizada o con configuraciones de usuario genéricas expone a la organización a pérdida de datos y brechas de seguridad. Estandarizar el despliegue asegura la trazabilidad y el rendimiento óptimo del parque informático.

NOTA: Para realizar esta práctica con total seguridad, utiliza una máquina virtual de pruebas con un disco duro virtual dedicado para simular el particionamiento completo sin afectar los datos de tu equipo anfitrión.

Instrucciones:

Fase 1: Planificación y particionamiento avanzado del almacenamiento:

Iniciar el equipo o la máquina virtual con el medio de instalación del sistema operativo Linux y acceder al asistente de particionado manual.

Diseñar una estructura de particiones desacoplada para garantizar la seguridad y facilitar futuras recuperaciones:

Partición EFI (/boot/efi): ~500 MB (en sistemas UEFI)
Partición Raíz (/): 30 GB a 50 GB (para el sistema operativo y binarios)
Partición de Intercambio (swap): 2 GB a 4 GB (para gestión de memoria virtual)
Partición de Usuario (/home): El espacio restante (para aislar los datos del empleado)

Fase 2: Instalación del sistema operativo y configuración regional:

Completar los parámetros de instalación seleccionando el idioma, la distribución de teclado y la zona horaria corporativa.
Asignar un nombre de host estandarizado y descriptivo al equipo (ej. PC-EMP-042) y proceder a la instalación de los ficheros del sistema.

Fase 3: Creación de cuentas de usuario y control de privilegios:

Crear la cuenta de usuario nominal para el empleado asignándole un nombre de usuario corporativo y una contraseña segura.
Verificar que el usuario creado no pertenece por defecto al grupo de administradores (sudo o wheel), aplicándose el principio de mínimo privilegio.
Otorgar privilegios de administración exclusivamente de forma temporal y controlada mediante el grupo sudoers si el puesto lo requiere.

Fase 4: Despliegue de software corporativo esencial:

Actualizar los repositorios de paquetes del sistema operativo para asegurar la estabilidad y parches de seguridad vigentes: sudo apt update && sudo apt upgrade -y
Instalar las herramientas de software estándar de la organización (navegadores web, suites ofimáticas, clientes de correo y herramientas de desarrollo o conectividad remota).

Fase 5: Configuración de copias de seguridad automatizadas:

Diseñar un script básico de respaldo utilizando herramientas como rsync para empaquetar y sincronizar el contenido del directorio personal del usuario (/home/usuario) hacia un directorio o almacenamiento externo seguro.
Programar la ejecución automatizada del script de respaldo mediante el planificador de tareas del sistema (cron) para que se ejecute de forma periódica (ej. diariamente a las 20:00 horas).

Verificación:

Comprobar mediante el comando lsblk que las particiones /, /home y la zona de intercambio están montadas y dimensionadas correctamente.
Verificar que el usuario creado puede iniciar sesión con éxito y que las tareas automatizadas de respaldo (cron) se encuentran registradas en el sistema.

Posibles errores y resolución de problemas:

Si al intentar programar la tarea automatizada de respaldo en cron observas que el script no se ejecuta a la hora establecida y no genera ficheros de destino, se debe a problemas con las rutas absolutas o falta de permisos de ejecución en el script.

Solución: Asegúrate de utilizar siempre rutas absolutas en el interior del script de respaldo (ej. /usr/bin/rsync en lugar de rsync) y otorga permisos de ejecución al fichero mediante chmod +x /ruta/del/script.sh.

Alternativa directa: Comprobación rápida del espacio montado por particiones

Si necesitas verificar de forma inmediata cómo se encuentra distribuido el almacenamiento y el porcentaje de ocupación real en cada una de las particiones creadas para el empleado, puedes ejecutar el comando:

df -Th

Preguntas de reflexión:

¿Qué ventajas operativas y de seguridad aporta separar la partición raíz (/) de la partición de usuario (/home) al aprovisionar un equipo para un empleado?
¿Por qué es una buena práctica de seguridad no otorgar permisos permanentes de administración (grupo sudo) a los usuarios finales en sus estaciones de trabajo diarias?
¿Qué implicaciones tiene utilizar una herramienta como rsync frente a una simple copia manual mediante el comando cp a la hora de realizar copias de seguridad incrementales?
¿Qué finalidad cumple la configuración de un nombre de host estandarizado y estructurado en los equipos informáticos dentro de una red corporativa?

Haz clic aquí para ver las soluciones y explicaciones

1. ¿Qué ventajas operativas y de seguridad aporta separar la partición raíz (`/`) de la partición de usuario (`/home`) al aprovisionar un equipo para un empleado?

Separar /home permite aislar los documentos y ficheros personales del empleado del resto del sistema operativo. Si el sistema operativo se corrompe y es necesario formatear o reinstalar la partición raíz (/), los datos del usuario permanecen intactos. Además, evita que un uso excesivo de almacenamiento por parte del usuario sature los ficheros críticos del núcleo del sistema.

2. ¿Por qué es una buena práctica de seguridad no otorgar permisos permanentes de administración (grupo sudo) a los usuarios finales en sus estaciones de trabajo diarias?

Porque aplicando el principio de mínimo privilegio se reduce drásticamente el riesgo de que el empleado, de forma accidental o debido a la ejecución de software malicioso o páginas web comprometidas, instale programas no autorizados, modifique configuraciones críticas del núcleo o comprometa la seguridad global del equipo y de la red corporativa.

3. ¿Qué implicaciones tiene utilizar una herramienta como `rsync` frente a una simple copia manual mediante el comando `cp` a la hora de realizar copias de seguridad incrementales?

rsync utiliza un algoritmo de transferencia eficiente que compara los ficheros de origen y destino, copiando únicamente aquellos bloques o archivos que han sufrido modificaciones (respaldo incremental o diferencial). Por el contrario, el comando cp copiaría la totalidad de los ficheros una y otra vez, consumiendo un tiempo y un espacio de almacenamiento innecesarios.

4. ¿Qué finalidad cumple la configuración de un nombre de host estandarizado y estructurado en los equipos informáticos dentro de una red corporativa?

Permite identificar de forma unívoca, rápida y organizada cada estación de trabajo dentro del inventario de la organización y de los sistemas de monitorización de red, facilitando las tareas de soporte remoto, auditoría de seguridad y gestión de dominios o políticas de grupo.

Después de una actualización el sistema ya no arranca

Objetivo:

Comprender y dominar los procedimientos críticos de recuperación de un sistema Linux que ha quedado completamente inoperativo tras una actualización fallida, aprendiendo a restaurar el gestor de arranque GRUB, reparar el sistema de archivos y verificar la integridad de los paquetes mediante un entorno Live USB de rescate.

Escenario:

Herramientas: Medio de rescate Live USB, terminal Linux, comandos chroot, grub-install, update-grub, fsck y herramientas de gestión APT.
Conceptos analizados: Arquitectura de arranque UEFI/BIOS, reescrescritura del sector de arranque o partición EFI, consistencia de sistemas de archivos ext4 y reparación de dependencias rotas del sistema operativo.
Proceso clave: Arranque externo, comprobación y reparación de bloques con fsck, montaje y vinculación de directorios virtuales, cambio de raíz mediante chroot, reinstalación del gestor GRUB y reconfiguración del sistema de paquetes.

Escenario Real: Servidor bloqueado con pantalla negra tras actualizar el kernel

Un administrador aplicó una actualización masiva del sistema que incluyó el núcleo de Linux y el gestor de arranque. Durante el proceso, la actualización se interrumpió, dejando al servidor incapaz de arrancar y mostrando un error de GRUB o una pantalla en negro permanente. Como administrador de sistemas, debes utilizar un entorno de rescate externo para reparar el almacenamiento, reinstalar el gestor de arranque y devolver la operatividad al servidor.

Por defecto, los fallos en el gestor de arranque o las interrupciones durante la actualización del kernel dejan el sistema inaccesible desde el disco duro. Dominar las técnicas de reconstrucción de GRUB mediante chroot es la competencia definitiva para solventar este tipo de colapsos.

NOTA: Para realizar esta práctica con total seguridad, asegúrate de utilizar una máquina virtual de prácticas o un medio Live USB compatible con el modo de arranque (BIOS o UEFI) de tu sistema dañado.

Instrucciones:

Fase 1: Arranque externo (Live USB) y verificación del almacenamiento:

Arrancar el equipo utilizando un medio de rescate externo (Live USB) y abrir una terminal.
Listar los discos y particiones para localizar la partición raíz (ej. /dev/sda2) y la partición EFI si procede (ej. /dev/sda1): lsblk
Asegurarse de que la partición raíz no está montada y ejecutar una comprobación y reparación de bloques dañados: sudo fsck -f -y /dev/sda2

Fase 2: Montaje de particiones y vinculación de directorios virtuales:

Crear el directorio temporal de rescate y montar en él la partición raíz reparada:
```
sudo mkdir -p /mnt/rescate
sudo mount /dev/sda2 /mnt/rescate
```
Si el sistema utiliza arranque UEFI, montar la partición EFI en su ruta correspondiente dentro del directorio de rescate: sudo mount /dev/sda1 /mnt/rescate/boot/efi

Vincular los sistemas de archivos virtuales del kernel para compartirlos con el entorno de rescate:

sudo mount --bind /dev /mnt/rescate/dev
sudo mount --bind /proc /mnt/rescate/proc
sudo mount --bind /sys /mnt/rescate/sys
sudo mount --bind /run /mnt/rescate/run

Fase 3: Cambio de raíz (chroot) y reparación de paquetes rotos:

Acceder al interior del sistema dañado mediante el comando de cambio de raíz: sudo chroot /mnt/rescate
Copiar el fichero de resolución DNS si necesitas acceso a la red: cp /etc/resolv.conf /etc/resolv.conf (dentro de chroot)
Forzar la configuración de paquetes pendientes y corregir posibles dependencias interrumpidas por la actualización fallida:
```
dpkg --configure -a
apt --fix-broken install
```

Fase 4: Reinstalación y actualización del gestor de arranque (GRUB):

Reinstalar GRUB en el disco principal (ej. /dev/sda para sistemas BIOS o el directorio EFI correspondiente para sistemas UEFI):

grub-install /dev/sda # En entornos BIOS tradicionales
# O bien: grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=debian --recheck # En entornos UEFI

Actualizar la configuración de GRUB para detectar todos los núcleos y sistemas operativos instalados: update-grub

Salir del entorno chroot, desmontar ordenadamente todos los recursos y reiniciar el equipo:

exit
sudo umount /mnt/rescate/dev /mnt/rescate/proc /mnt/rescate/sys /mnt/rescate/run
sudo umount /mnt/rescate/boot/efi # Si procede
sudo umount /mnt/rescate
sudo reboot

Verificación:

Comprobar que tras retirar el medio externo, el equipo muestra el menú de GRUB con normalidad y permite seleccionar y arrancar el sistema operativo.
Verificar que el sistema inicia sesión correctamente y que los paquetes del kernel se encuentran estables.

Posibles errores y resolución de problemas:

Si al ejecutar el comando grub-install dentro del entorno chroot el sistema devuelve un error crítico indicando que EFI variables are not supported on this system, significa que has iniciado el Live USB en modo BIOS tradicional mientras que el sistema operativo instalado utiliza particionado UEFI.

Solución: Reinicia el equipo físico, accede al menú de arranque de la BIOS/UEFI y asegúrate de iniciar el medio Live USB en modo UEFI antes de volver a montar las particiones y ejecutar el cambio de raíz (chroot).

Alternativa directa: Actualización rápida de GRUB desde un sistema operativo accesible

Si el sistema arranca pero no detecta un segundo sistema operativo o un nuevo núcleo instalado, puedes actualizar el archivo de configuración de GRUB de forma directa sin necesidad de entrar en modo rescate ejecutando:

sudo update-grub

Preguntas de reflexión:

¿Por qué es indispensable vincular los directorios virtuales del kernel (como /dev, /proc y /sys) antes de ejecutar el comando chroot en el sistema de rescate?
¿Qué diferencia técnica existe a la hora de reinstalar GRUB entre un sistema con particionado tradicional MBR y un sistema moderno basado en UEFI?
¿Qué función cumple exactamente el comando update-grub tras reinstalar el gestor de arranque en el disco duro?
¿Por qué una interrupción abrupta durante la actualización del núcleo de Linux suele invalidar el arranque del equipo?

Haz clic aquí para ver las soluciones y explicaciones

1. ¿Por qué es indispensable vincular los directorios virtuales del kernel (como `/dev`, `/proc` y `/sys`) antes de ejecutar el comando `chroot` en el sistema de rescate?

Porque el entorno chroot cambia la raíz lógica del sistema, pero los comandos avanzados de reparación (como grub-install o el gestor APT) necesitan interactuar directamente con los dispositivos de hardware (/dev), la información del núcleo en ejecución (/proc) y los parámetros del sistema (/sys). Sin estos puntos montados mediante bind, los programas no podrán acceder al disco físico ni configurar el cargador.

2. ¿Qué diferencia técnica existe a la hora de reinstalar GRUB entre un sistema con particionado tradicional MBR y un sistema moderno basado en UEFI?

En sistemas MBR tradicionales, GRUB se instala directamente en el sector de arranque maestro (MBR) o en los primeros bloques de sectores ocultos del disco duro físico (ej. /dev/sda). En cambio, en sistemas UEFI no se escribe código en el sector de arranque, sino que se copian los ficheros binarios correspondientes dentro de la partición EFI montada en /boot/efi y se registra la ruta de arranque en la NVRAM de la placa base mediante variables UEFI.

3. ¿Qué función cumple exactamente el comando `update-grub` tras reinstalar el gestor de arranque en el disco duro?

Escanea el directorio /boot en busca de las imágenes de núcleos de Linux y ficheros initramfs disponibles, y genera un fichero de configuración actualizado (/boot/grub/grub.cfg), asegurando que el menú de arranque refleje correctamente las versiones vigentes del sistema operativo.

4. ¿Por qué una interrupción abrupta durante la actualización del núcleo de Linux suele invalidar el arranque del equipo?

Porque durante la actualización de un kernel se descargan los ficheros de imagen, se generan los discos virtuales temporales (initramfs) y se actualizan los enlaces del gestor de arranque de forma secuencial. Si el proceso se corta a mitad, los ficheros de arranque pueden quedar incompletos, corruptos o desincronizados, impidiendo que GRUB localice y cargue correctamente el núcleo del sistema operativo.

No se puede acceder a una carpeta compartida

Objetivo:

Diagnosticar y resolver un fallo de acceso denegado a una carpeta o recurso compartido en un sistema Linux, aprendiendo a auditar y corregir de forma metódica los permisos tradicionales de usuario/grupo/otros, la propiedad de los archivos, los permisos avanzados mediante ACLs (Access Control Lists) y las restricciones a nivel de exportación de red.

Escenario:

Herramientas: Terminal Linux, comandos ls -l, getfacl / setfacl, chown, chmod, y auditoría de accesos.
Conceptos analizados: Máscaras de permisos POSIX, herencia de directorios, pertenencia a grupos suplementarios, listas de control de acceso extendidas y verificación de permisos de red (NFS/Samba).
Proceso clave: Comprobación de la identidad del usuario y sus grupos activos, inspección de permisos y propietario de la ruta compartida, análisis de ACLs aplicadas y reconfiguración de los accesos necesarios.

Escenario Real: Usuario sin privilegios para consultar un recurso departamental

Un empleado de la organización intenta acceder a una carpeta compartida en el servidor para consultar documentación de su departamento, pero el sistema le devuelve de forma persistente un error de "Permiso denegado" (Permission denied). Como administrador de sistemas, debes realizar un diagnóstico estructurado para identificar si el fallo proviene del propietario, de los permisos de grupo o de una ACL restrictiva.

Por defecto, los sistemas operativos protegen los recursos mediante esquemas estrictos de seguridad basados en privilegios. Saber aislar dónde se produce el bloqueo de acceso es indispensable para resolver incidencias de colaboración en red.

NOTA: Para realizar esta práctica con total seguridad, utilizaremos comandos de consulta e inspección sobre los metadatos de los ficheros y directorios, evitando modificar configuraciones sin antes comprender el origen del fallo.

Instrucciones:

Fase 1: Verificación de la identidad del usuario y grupos activos:

Comprobar el identificador de usuario y los grupos suplementarios a los que pertenece el usuario afectado: id
Verificar si el usuario forma parte del grupo de trabajo propietario del recurso compartido.

Fase 2: Inspección de permisos tradicionales y propietario del directorio:

Listar los permisos detallados, el usuario propietario y el grupo asignado al directorio compartido: ls -ld /ruta/de/la/carpeta/compartida
Comprobar si los permisos de lectura (r), escritura (w) o ejecución (x) están correctamente asignados para el usuario, el grupo o el resto del sistema.

Fase 3: Auditoría de permisos avanzados (ACL - Access Control Lists):

Verificar si la carpeta utiliza listas de control de acceso avanzadas que modifiquen o amplíen los permisos tradicionales: getfacl /ruta/de/la/carpeta/compartida
Comprobar si existen restricciones heredadas en los subdirectorios o ficheros internos del recurso compartido.

Fase 4: Corrección de privilegios y propiedad de la ruta:

Modificar el grupo propietario del recurso para adaptarlo al departamento correspondiente si existía una discrepancia: sudo chown -R :nombre_grupo /ruta/de/la/carpeta/compartida
Otorgar los permisos de acceso y ejecución necesarios mediante comandos de permisos tradicionales o estableciendo una ACL específica para el usuario o grupo: sudo setfacl -R -m u:nombre_usuario:rwx /ruta/de/la/carpeta/compartida

Verificación:

Comprobar con el usuario afectado que ahora puede acceder al directorio compartido, listar su contenido y modificar o crear ficheros según sus funciones.
Verificar mediante getfacl que las reglas de control de acceso aplicadas se han propagado correctamente.

Posibles errores y resolución de problemas:

Si a pesar de haber otorgado permisos de lectura y escritura en una carpeta a un usuario, este sigue sin poder acceder al interior de la misma obteniendo un error de acceso denegado, se debe a la ausencia del permiso de ejecución en el directorio.

Solución: En Linux, el permiso de ejecución (x) en un directorio es obligatorio para poder atravesarlo o consultar los metadatos de sus ficheros internos. Aplica el permiso de ejecución con sudo chmod +x /ruta/de/la/carpeta/compartida.

Alternativa directa: Comprobación rápida de permisos detallados

Si necesitas auditar de forma inmediata los permisos detallados y la estructura completa de un directorio compartido y sus niveles inferiores sin ejecutar consultas complejas, puedes emplear el listado recursivo optimizado:

ls -lR /ruta/de/la/carpeta/compartida

Preguntas de reflexión:

¿Por qué un usuario con permisos de lectura (r) sobre los ficheros internos de un directorio no puede acceder a los mismos si carece del permiso de ejecución (x) en la carpeta contenedora?
¿Qué diferencia técnica fundamental existe entre los permisos tradicionales de Linux (Usuario/Grupo/Otros) y las Listas de Control de Acceso (ACLs)?
¿Qué implicaciones de seguridad tiene asignar permisos de acceso globales excesivamente laxos (como 777) en una carpeta compartida frente a utilizar grupos o ACLs específicas?
¿Cómo influye el mapeo de identidades y UID/GID al acceder a una carpeta compartida a través de protocolos de red como NFS o Samba en comparación con el acceso local en la misma máquina?

Haz clic aquí para ver las soluciones y explicaciones

1. ¿Por qué un usuario con permisos de lectura (`r`) sobre los ficheros internos de un directorio no puede acceder a los mismos si carece del permiso de ejecución (`x`) en la carpeta contenedora?

Porque en los sistemas de ficheros UNIX/Linux, el permiso de ejecución sobre un directorio otorga el derecho de "búsqueda" o traversia; es decir, la capacidad de atravesar el directorio para resolver las rutas internas y consultar los inodos de los ficheros que contiene. Sin el bit x activo, el sistema bloquea el acceso a cualquier ruta situada dentro de esa carpeta, independientemente de los permisos que tengan los ficheros en sí.

2. ¿Qué diferencia técnica fundamental existe entre los permisos tradicionales de Linux (Usuario/Grupo/Otros) y las Listas de Control de Acceso (ACLs)?

Los permisos tradicionales limitan el control de acceso a un único usuario propietario y a un único grupo asignado al fichero, lo que resulta restrictivo para entornos colaborativos complejos. Por el contrario, las ACLs permiten definir reglas de permisos granulares específicas para múltiples usuarios y grupos adicionales de forma independiente sobre un mismo objeto.

3. ¿Qué implicaciones de seguridad tiene asignar permisos de acceso globales excesivamente laxos (como `777`) en una carpeta compartida frente a utilizar grupos o ACLs específicas?

Asignar permisos 777 significa que cualquier usuario local o proceso del sistema puede leer, modificar y borrar el contenido de la carpeta compartida sin restricciones, lo que vulnera el principio de mínimo privilegio y expone los datos confidenciales a modificaciones accidentales o maliciosas por parte de usuarios no autorizados.

4. ¿Cómo influye el mapeo de identidades y UID/GID al acceder a una carpeta compartida a través de protocolos de red como NFS o Samba en comparación con el acceso local en la misma máquina?

En local, el kernel evalúa los permisos basándose en los UID y GID numéricos del usuario autenticado en el sistema. En entornos de red (como NFS), si los identificadores numéricos (UID) no coinciden entre el cliente y el servidor, o si no se configuran correctamente las políticas de mapeo de usuarios anónimos o invitados, el servidor interpretará las peticiones con privilegios erróneos, denegando el acceso aunque los permisos locales parezcan correctos.

No queda espacio en disco y nadie sabe por qué

Objetivo:

Diagnosticar y resolver una incidencia crítica de saturación de almacenamiento en un sistema Linux donde el espacio en disco se ha agotado por completo, aprendiendo a localizar de forma metódica ficheros ocultos de gran tamaño, directorios temporales descontrolados, registros inflados y copias de seguridad antiguas mediante el uso avanzado de comandos de análisis.

Escenario:

Herramientas: Terminal Linux, comandos df, du, find, ncdu y gestión de inodos con df -i.
Conceptos analizados: Ocupación de bloques en sistemas de archivos ext4/XFS, ficheros abiertos retenidos por procesos zombie o detenidos, volúmenes de logs acumulados y directorios temporales (/tmp, /var/tmp, /var/log).
Proceso clave: Identificación del punto de montaje saturado, búsqueda estructurada de los directorios y ficheros que más espacio consumen, detección de ficheros fantasmas retenidos por demonios activos y purga controlada de elementos obsoletos.

Escenario Real: Servidor con caída de servicios por espacio al 100%

Un servidor web de producción ha dejado de registrar accesos y las bases de datos han sufrido un bloqueo repentino. Al intentar acceder por SSH, el sistema emite errores continuos indicando falta de espacio de almacenamiento. Como administrador de sistemas, debes realizar una auditoría de urgencia para localizar qué elementos están consumiendo el 100% de la capacidad y liberar espacio de forma segura sin comprometer la estabilidad del sistema.

Por defecto, la acumulación silenciosa de ficheros temporales, rotaciones de logs fallidas o descargas huérfanas puede colapsar el almacenamiento sin que las alertas tradicionales lo detecten a tiempo. Dominar las herramientas de inspección de espacio es un recurso vital para la continuidad operativa.

NOTA: Para realizar esta práctica de limpieza con total seguridad, utilizaremos comandos de consulta analítica y exclusión de ficheros protegidos del kernel, evitando eliminar dependencias esenciales del sistema operativo.

Instrucciones:

Fase 1: Identificación del volumen o partición saturada:

Comprobar de forma global el estado del espacio ocupado y disponible en todos los puntos de montaje del sistema: df -h
Verificar si el problema se debe al agotamiento estricto de bloques de datos o a la saturación total de inodos (ficheros máximos permitidos): df -i

Fase 2: Localización de los mayores consumidores de espacio con du y find:

Analizar el consumo detallado de los subdirectorios principales dentro de la partición raíz ordenándolos de mayor a menor tamaño: sudo du -h --max-depth=1 / | sort -hr
Buscar de forma específica en todo el sistema aquellos ficheros cuyo tamaño supere un umbral crítico (por ejemplo, mayores de 100 MB): sudo find / -type f -size +100M -exec ls -lh {} \; 2>/dev/null

Fase 3: Auditoría de directorios críticos (Logs, Temporales y Backups):

Inspeccionar el directorio de registros del sistema para detectar ficheros de log sobredimensionados: sudo du -sh /var/log/* | sort -hr
Revisar el contenido de los directorios temporales en busca de ficheros residuales acumulados durante semanas: sudo du -sh /tmp/* /var/tmp/* 2>/dev/null
Localizar copias de seguridad antiguas, ficheros comprimidos (.tar.gz, .zip) o imágenes ISO olvidadas en directorios de usuarios o rutas raíz.

Fase 4: Detección de ficheros fantasmas retenidos por procesos activos:

Identificar aquellos ficheros que han sido borrados desde la terminal pero cuyos procesos asociados los siguen manteniendo abiertos en memoria (consumiendo espacio oculto): sudo lsof +L1
Reiniciar o recargar los servicios asociados a dichos procesos liberadores para recuperar de inmediato el espacio fantasma ocupado en el disco.

Verificación:

Comprobar mediante el comando df -h que el punto de montaje afectado ha recuperado un porcentaje de espacio libre seguro (por debajo del 85-90% de ocupación).
Verificar que los servicios críticos del sistema (como bases de datos o servidores web) han reanudado su actividad normal tras la liberación de almacenamiento.

Posibles errores y resolución de problemas:

Si tras eliminar ficheros voluminosos de registros o copias de seguridad observas que el comando df -h sigue indicando que el espacio ocupado está al 100% y no se ha liberado ningún bloque en el disco, se debe al fenómeno de retención por procesos en ejecución.

Solución: Un proceso sigue escribiendo o manteniendo abierto el descriptor del fichero eliminado. Utiliza sudo lsof +L1 para localizar el PID responsable y reinicia el servicio correspondiente para forzar la liberación definitiva del espacio.

Alternativa directa: Inspección visual interactiva con ncdu

Si necesitas navegar de forma rápida, intuitiva y visual por la jerarquía de directorios para detectar qué carpetas están devorando el espacio del disco sin recurrir a comandos complejos de consola, puedes instalar y ejecutar la utilidad de análisis interactivo:

sudo apt install ncdu -y && sudo ncdu /

Preguntas de reflexión:

¿Por qué un sistema Linux puede reportar que el disco está totalmente lleno (100% de ocupación) a pesar de haber borrado ficheros pesados recientemente?
¿Qué diferencia técnica existe entre auditar la ocupación del almacenamiento mediante bloques de datos (df -h) frente a la comprobación de inodos disponibles (df -i)?
¿Qué riesgos implica para la estabilidad del sistema operativo eliminar de forma indiscriminada ficheros temporales activos en el directorio /tmp sin verificar su uso actual?
¿Por qué se recomienda configurar políticas automatizadas de rotación de registros (como logrotate) en los servidores de producción?

Haz clic aquí para ver las soluciones y explicaciones

1. ¿Por qué un sistema Linux puede reportar que el disco está totalmente lleno (100% de ocupación) a pesar de haber borrado ficheros pesados recientemente?

Ocurre porque el comando de borrado (rm) elimina la ruta o el enlace del fichero, pero si un proceso en ejecución mantiene abierto el descriptor de ese mismo fichero en memoria, el sistema de archivos no libera físicamente los bloques de disco hasta que el proceso se cierra por completo o se reinicia.

2. ¿Qué diferencia técnica existe entre auditar la ocupación del almacenamiento mediante bloques de datos (`df -h`) frente a la comprobación de inodos disponibles (`df -i`)?

El espacio en bloques mide la capacidad total en megabytes o gigabytes ocupada por el contenido de los ficheros. Por el contrario, los inodos son las estructuras de metadatos que identifican a cada fichero de manera unívoca. Un sistema puede tener espacio físico libre en bloques, pero si se generan millones de ficheros diminutos, se agotan los inodos y el sistema deja de permitir la creación de nuevos archivos.

3. ¿Qué riesgos implica para la estabilidad del sistema operativo eliminar de forma indiscriminada ficheros temporales activos en el directorio `/tmp` sin verificar su uso actual?

Muchos demonios en ejecución, bases de datos o entornos de compilación utilizan ficheros temporales y sockets de comunicación activos (Unix sockets) albergados en /tmp o /var/tmp. Borrarlos de forma agresiva puede congelar procesos en curso, corromper sesiones de usuario o provocar fallos inesperados en las aplicaciones.

4. ¿Por qué se recomienda configurar políticas automatizadas de rotación de registros (como `logrotate`) en los servidores de producción?

Porque los servicios escriben mensajes de depuración e información de forma continua en los ficheros de log. Sin una herramienta automatizada que comprima, archive y elimine periódicamente los registros antiguos, los ficheros crecerán de manera infinita hasta agotar por completo el espacio libre del disco duro del servidor.

El ordenador tarda 15 minutos en arrancar

Objetivo:

Diagnosticar y resolver de forma metódica un problema de rendimiento crítico en el que el equipo o servidor experimenta un tiempo de arranque excesivo (15 minutos), aprendiendo a correlacionar cuellos de botella mediante el análisis de servicios, procesos, estado del disco, registros del sistema y la secuencia de inicialización de systemd.

Escenario:

Herramientas: Terminal Linux, comandos systemd-analyze, systemctl, journalctl, top / htop, y smartctl / iostat.
Conceptos analizados: Tiempos de espera (timeouts) de servicios caídos, unidades bloqueadas en el arranque, saturación de E/S de almacenamiento (I/O wait), errores de montaje en /etc/fstab y consumo excesivo de recursos de inicio.
Proceso clave: Medición y desglose analítico del tiempo de arranque, identificación de demonios colgados con retardos de timeout, inspección del búfer de errores del kernel y comprobación de la salud física del disco duro.

Escenario Real: Servidor con retardo extremo y bloqueo en la inicialización

Un servidor crítico corporativo tarda exactamente 15 minutos en completar su proceso de arranque tras un reinicio programado. Una vez finalizada la carga, el sistema operativo opera con una lentitud desesperante. Como administrador de sistemas, debes aplicar un proceso de diagnóstico exhaustivo para descubrir qué componente del hardware o qué servicio software está provocando este cuello de botella masivo durante la secuencia de inicio.

Por defecto, los sistemas modernos no muestran los retardos internos en la pantalla de bienvenida. Saber auditar las fases de inicialización mediante las herramientas analíticas de Systemd y el rendimiento del almacenamiento es la única vía profesional para resolver bloqueos de este tipo.

NOTA: Para realizar esta práctica con total seguridad, utilizaremos comandos de consulta e inspección sobre los registros y métricas del sistema, evitando alterar configuraciones críticas antes de identificar la causa raíz.

Instrucciones:

Fase 1: Análisis global del tiempo de arranque (systemd-analyze):

Comprobar el tiempo total acumulado por el núcleo y el espacio de usuario en completar el arranque del sistema: systemd-analyze
Desglosar y ordenar cronológicamente de mayor a menor el consumo de tiempo de cada servicio individual para detectar cuellos de botella: systemd-analyze blame
Analizar el grafo crítico de dependencias para descubrir qué servicio exacto obligó al sistema a esperar durante minutos: systemd-analyze critical-chain

Fase 2: Auditoría de servicios fallidos y unidades bloqueadas por timeout:

Listar todas las unidades de systemd que se encuentran en estado de error o que han superado su tiempo máximo de espera: systemctl --failed
Comprobar si existen montajes de discos de red (como NFS o CIFS) o particiones secundarias mal configuradas en /etc/fstab que provoquen bloqueos de espera indefinidos al no estar disponibles durante el arranque.
Deshabilitar temporalmente aquellos servicios no esenciales que presenten retardos críticos en el inicio: sudo systemctl disable [nombre_servicio]

Fase 3: Inspección de registros del kernel y búfer de inicio (journalctl):

Consultar los mensajes de error crítico registrados específicamente durante el arranque actual para identificar advertencias de hardware o fallos de drivers: sudo journalctl -b 0 -p err
Inspeccionar el búfer de mensajes del kernel en busca de bloqueos de E/S o problemas de respuesta del controlador de almacenamiento: dmesg -T | grep -iE 'error|timeout|fail|block'

Fase 4: Diagnóstico del rendimiento y salud del almacenamiento (Disco y I/O):

Verificar el estado de salud física y los parámetros SMART del disco duro o unidad SSD para descartar fallos mecánicos o de sectores defectuosos: sudo smartctl -H /dev/sda
Analizar la carga de E/S y el nivel de espera de disco (iowait) para comprobar si el almacenamiento está saturado: iostat -xz 1 10

Verificación:

Comprobar mediante un nuevo reinicio y la ejecución de systemd-analyze que el tiempo total de arranque se ha reducido drásticamente a valores normales (segundos en lugar de 15 minutos).
Verificar mediante systemctl --failed que el sistema ya no arrastra unidades colgadas ni servicios en estado de error.

Posibles errores y resolución de problemas:

Si al ejecutar smartctl para comprobar la salud del disco el sistema devuelve un error indicando que command not found, significa que la utilidad de diagnóstico SMART no está instalada en el sistema operativo.

Solución: Instala el paquete de utilidades de control de almacenamiento ejecutando en la terminal: sudo apt update && sudo apt install smartmontools -y (o el gestor de paquetes correspondiente a tu distribución).

Alternativa directa: Localización instantánea de servicios lentos

Si necesitas aislar de forma ultra rápida los 5 servicios que más retrasan el arranque del sistema sin volcar listas interminables de dependencias por la pantalla, puedes ejecutar el siguiente comando optimizado:

systemd-analyze blame | head -n 5

Preguntas de reflexión:

¿Por qué un fallo en el montaje de una unidad de red remota dentro del fichero /etc/fstab puede congelar el arranque de un sistema Linux durante varios minutos?
¿Qué diferencia técnica existe entre auditar los tiempos muertos con systemd-analyze blame frente a analizar el flujo de dependencias críticas con systemd-analyze critical-chain?
¿Cómo influye un valor elevado de iowait en el rendimiento general del procesador y en la lentitud extrema de un equipo durante y después del arranque?
¿Qué relación directa puede existir entre un disco duro con sectores defectuosos (detectados mediante SMART) y un tiempo de arranque excesivamente prolongado?

Haz clic aquí para ver las soluciones y explicaciones

1. ¿Por qué un fallo en el montaje de una unidad de red remota dentro del fichero `/etc/fstab` puede congelar el arranque de un sistema Linux durante varios minutos?

Porque por defecto el sistema operativo intenta montar las particiones y recursos declarados en /etc/fstab de forma síncrona durante las fases iniciales. Si la red remota no está accesible, el servicio de montaje espera de forma indefinida hasta agotar un tiempo de espera (timeout) muy elevado antes de permitir que el arranque continúe, provocando una demora masiva.

2. ¿Qué diferencia técnica existe entre auditar los tiempos muertos con `systemd-analyze blame` frente a analizar el flujo de dependencias críticas con `systemd-analyze critical-chain`?

El comando systemd-analyze blame enumera de forma aislada cuánto tiempo total ha consumido cada servicio individual desde el inicio. Por el contrario, systemd-analyze critical-chain muestra el camino crítico de dependencias en cadena; es decir, qué servicios se han tenido que ejecutar obligatoriamente de forma secuencial retrasando el tiempo real del reloj de arranque.

3. ¿Cómo influye un valor elevado de iowait en el rendimiento general del procesador y en la lentitud extrema de un equipo durante y después del arranque?

El indicador iowait representa el porcentaje de tiempo que la CPU permanece inactiva esperando obligatoriamente a que finalicen las operaciones de lectura o escritura en el almacenamiento secundario. Un valor alto indica que el disco es extremadamente lento o está saturado, provocando que la CPU se quede bloqueada sin poder procesar tareas aunque su uso de cálculo puro parezca bajo.

4. ¿Qué relación directa puede existir entre un disco duro con sectores defectuosos (detectados mediante SMART) y un tiempo de arranque excesivamente prolongado?

Cuando un disco duro físico presenta sectores deteriorados o problemas de lectura en los bloques donde se ubican los ficheros del sistema operativo o los registros de inicio, el controlador de almacenamiento y el kernel realizan múltiples reintentos automáticos (retries) y operaciones de recuperación de errores a bajo nivel, ralentizando de forma drástica la velocidad de lectura y congelando la secuencia de arranque.

Simulación de incidencias en entornos aislados

Objetivo:

Comprender y ejecutar metodologías controladas para la simulación de fallos e incidencias críticas en entornos de pruebas aislados, aprendiendo a evaluar la resiliencia del sistema, medir tiempos de recuperación y aplicar protocolos estructurados de respuesta ante emergencias tecnológicas.

Escenario:

Herramientas: Entorno virtualizado aislado (Red Interna), terminal Linux, herramientas de inyección de fallos (generación artificial de carga, saturación de disco, parada forzosa de demonios).
Conceptos analizados: Gestión de incidentes, alta disponibilidad, tolerancia a fallos, redundancia y análisis post-mortem (post-incident review).
Proceso clave: Diseño de un escenario de fallo controlado en una máquina virtual aislada, ejecución de la incidencia, detección mediante monitorización, aplicación del plan de contingencia y validación de la recuperación del servicio.

Escenario Real: Pruebas de estrés y respuesta ante caídas de servicios críticos

Una organización desea comprobar cómo reacciona su infraestructura ante la caída inesperada de un servidor web en producción y la saturación de espacio en disco. Como administrador de sistemas, debes diseñar un escenario de simulación en un entorno de laboratorio totalmente aislado donde provocarás de manera controlada una incidencia de indisponibilidad, midiendo los tiempos de detección y aplicando los procedimientos de recuperación establecidos para garantizar la continuidad del negocio.

Por defecto, los sistemas están expuestos a imprevistos técnicos de diversa índole. Realizar simulacros controlados en entornos aislados es la única manera fiable de comprobar la eficacia de los planes de contingencia antes de que ocurra una emergencia real en producción.

NOTA: Asegúrate de que las simulaciones de incidencias destructivas se ejecutan exclusivamente en máquinas virtuales dotadas de red interna aislada y con su correspondiente instantánea (snapshot) previa para evitar daños colaterales.

Instrucciones:

Fase 1: Diseño del escenario de prueba y aislamiento del entorno:

Preparar una máquina virtual de prácticas configurando su adaptador de red en modo Red Interna para garantizar el aislamiento absoluto respecto a la red de producción real.
Crear una instantánea (snapshot) de seguridad previa en el hipervisor denominada "Punto de partida simulación".
Definir los parámetros clave a medir: Tiempo Medio de Detección (MTTD) y Tiempo Medio de Recuperación (MTTR).

Fase 2: Inyección controlada de la incidencia en el sistema:

Simular un fallo crítico de servicio deteniendo de forma abrupta y deshabilitando el demonio principal del servidor web (ej. Apache o Nginx): sudo systemctl stop apache2 && sudo systemctl disable apache2
Simular una saturación de disco creando un fichero temporal masivo que consuma el 100% de los inodos o espacio libre del sistema de ficheros de pruebas:
```
sudo dd if=/dev/zero of=/var/log/fichero_saturacion.img bs=1M count=5000
```

Fase 3: Detección, diagnóstico y ejecución del plan de respuesta:

Detectar el origen del fallo utilizando las herramientas de auditoría y logs previamente estudiadas (como systemctl --failed, journalctl o df -h).
Ejecutar los procedimientos correctivos de emergencia para solucionar la incidencia (por ejemplo, liberar el espacio en disco eliminando el fichero artificial y reactivar los servicios detenidos):
```
sudo rm /var/log/fichero_saturacion.img
sudo systemctl enable --now apache2
```

Fase 4: Auditoría post-incidente y elaboración de métricas:

Verificar que los servicios recuperados responden de manera óptima y que el almacenamiento vuelve a disponer de los niveles de espacio seguros.
Calcular los indicadores de rendimiento del simulacro (MTTD y MTTR) y documentar los puntos débiles detectados durante el proceso de resolución.

Verificación:

Comprobar mediante comandos de estado que todos los servicios inyectados vuelven a encontrarse activos y operativos (active (running)).
Verificar que el uso del almacenamiento físico ha retornado a los valores normales y estables previos a la simulación.

Posibles errores y resolución de problemas:

Si al intentar solucionar la saturación de disco provocada durante la simulación descubres que el sistema operativo se ha bloqueado por completo y no permite ejecutar comandos en la terminal, se debe a la falta total de espacio para alojar ficheros temporales del kernel.

Solución: Apaga la máquina virtual desde el hipervisor o restaura de forma inmediata la instantánea de seguridad (snapshot) previa creada en la Fase 1 para recuperar el control operativo del sistema de forma instantánea.

Alternativa directa: Comprobación rápida del estado de servicios críticos

Si necesitas realizar una verificación instantánea de la disponibilidad de múltiples demonios de red tras la ejecución de una incidencia simulada, puedes consultar su estado de ejecución combinando comandos de systemctl:

sudo systemctl is-active apache2 ssh ufw

Preguntas de reflexión:

¿Por qué es un requisito indispensable realizar simulaciones de incidencias destructivas exclusivamente en entornos aislados de red y no directamente sobre servidores en producción?
¿Qué métricas operativas fundamentales (como MTTD y MTTR) se evalúan durante un simulacro de fallo y qué importancia tienen para la gestión de la calidad del servicio (SLA)?
¿Qué riesgos implica para la estabilidad del núcleo del sistema operativo una saturación completa del almacenamiento (disco al 100% de su capacidad)?
¿Qué utilidad aporta la elaboración de un informe post-mortem tras finalizar una simulación o incidencia real en la infraestructura tecnológica?

Haz clic aquí para ver las soluciones y explicaciones

1. ¿Por qué es un requisito indispensable realizar simulaciones de incidencias destructivas exclusivamente en entornos aislados de red y no directamente sobre servidores en producción?

Porque la inyección de fallos como caídas de servicios, corrupción de ficheros o saturación de almacenamiento puede provocar interrupciones masivas en los servicios reales que utilizan los usuarios, pérdida irreversible de datos de negocio o brechas de seguridad involuntarias si el fallo se propaga hacia el resto de la red corporativa.

2. ¿Qué métricas operativas fundamentales (como MTTD y MTTR) se evalúan durante un simulacro de fallo y qué importancia tienen para la gestión de la calidad del servicio (SLA)?

El MTTD (Mean Time to Detect) mide el tiempo medio que se tarda en detectar que se ha producido una incidencia, mientras que el MTTR (Mean Time to Repair/Recovery) mide el tiempo medio requerido para solucionar el problema y restaurar el servicio. Ambas métricas son vitales para cumplir con los Acuerdos de Nivel de Servicio (SLA) comprometidos con los clientes o departamentos de la organización.

3. ¿Qué riesgos implica para la estabilidad del núcleo del sistema operativo una saturación completa del almacenamiento (disco al 100% de su capacidad)?

Cuando el disco se llena por completo, el sistema operativo y las aplicaciones dejan de poder escribir ficheros temporales, registros (logs) o estructuras en la memoria virtual (swap). Esto provoca congelaciones repentinas de procesos, corrupción de bases de datos activas y la caída generalizada de los servicios del servidor.

4. ¿Qué utilidad aporta la elaboración de un informe post-mortem tras finalizar una simulación o incidencia real en la infraestructura tecnológica?

Permite analizar de forma objetiva qué falló en los protocolos de respuesta, identificar las debilidades técnicas de la infraestructura, medir la eficacia del equipo humano y proponer medidas correctoras o automatizaciones preventivas para evitar que el mismo tipo de incidencia vuelva a repetirse en el futuro.

Uso de instantáneas (snapshots) para recuperación rápida

Objetivo:

Comprender y dominar el uso táctico de las instantáneas (snapshots) en entornos de virtualización (como VirtualBox, KVM o Proxmox), aprendiendo a registrar estados estables del sistema, simular pruebas de riesgo y ejecutar operaciones de reversión rápida ante fallos críticos de configuración o actualización.

Escenario:

Herramientas: Hipervisor de virtualización (VirtualBox / KVM / Virt-Manager), terminal Linux y asistente de gestión de instantáneas.
Conceptos analizados: Arquitectura de copias delta (CoW - Copy-on-Write), gestión de árboles de instantáneas, puntos de restauración en caliente y validación de integridad post-reversión.
Proceso clave: Creación de una instantánea base, ejecución de una prueba destructiva o modificación indeseada en el sistema, reversión inmediata al estado anterior y consolidación o limpieza del árbol de snapshots.

Escenario Real: Recuperación instantánea tras una prueba de software fallida

Un administrador de sistemas va a aplicar una actualización experimental de paquetes y a modificar configuraciones críticas del servidor web que podrían dejar el sistema completamente inaccesible. Como medida de seguridad preventiva, debes generar una instantánea antes de iniciar la intervención. Si el proceso de prueba falla y corrompe los servicios, podrás revertir todo el sistema al estado anterior en cuestión de segundos sin necesidad de reinstalar desde cero.

Por defecto, los cambios aplicados en los sistemas operativos son acumulativos e irreversibles de forma sencilla. Saber utilizar las instantáneas como red de seguridad temporal es una técnica indispensable para mitigar riesgos en entornos de laboratorio, pruebas y desarrollo.

NOTA: Recuerda que una instantánea congela el estado del disco virtual en un momento exacto y almacena únicamente los cambios posteriores, pero nunca sustituye a una copia de seguridad tradicional (backup) extraída a un soporte independiente.

Instrucciones:

Fase 1: Preparación del sistema y generación de la instantánea base:

Comprobar que la máquina virtual de pruebas se encuentra en un estado totalmente estable, limpio y con los servicios principales funcionando correctamente.
Apagar la máquina virtual de forma segura o mantenerla encendida (las instantáneas en caliente guardan también el estado de la memoria RAM si el hipervisor lo soporta).
Acceder al gestor de instantáneas del hipervisor y crear un nuevo punto de restauración indicando un nombre descriptivo y una etiqueta clara (ej. Snapshot: "Estado limpio previo a actualización").

Fase 2: Simulación de un fallo crítico o modificación de riesgo:

Encender la máquina virtual y simular una catástrofe operativa o una modificación destructiva (por ejemplo, alterar ficheros de configuración esenciales del sistema o desinstalar un paquete crítico de red).
Comprobar que, tras la modificación, el servidor presenta fallos graves de funcionamiento o incapacidad para iniciar sesión correctamente.

Fase 3: Ejecución de la reversión rápida (Rollback):

Apagar la máquina virtual si se encuentra en un bucle de bloqueo o congelada.
Seleccionar en el árbol de instantáneas del hipervisor el punto de restauración creado previamente en la Fase 1.
Ejecutar la orden de Restaurar / Revertir (Rollback) a esa instantánea, aceptando la advertencia sobre la pérdida de los cambios posteriores no guardados.

Fase 4: Verificación del estado recuperado y gestión del árbol:

Encender nuevamente la máquina virtual y comprobar que el sistema ha retornado exactamente al mismo estado estable anterior a la prueba.
Analizar la estructura del árbol de instantáneas para comprobar cómo se gestionan las ramas temporales y eliminar los puntos obsoletos si ya no son necesarios para liberar espacio en el disco del anfitrión.

Verificación:

Comprobar mediante la revisión de ficheros y servicios que la modificación destructiva realizada en la Fase 2 ha desaparecido por completo tras la reversión.
Verificar que el hipervisor reporta que la máquina virtual se encuentra sincronizada correctamente con el snapshot base seleccionado.

Posibles errores y resolución de problemas:

Si tras acumular numerosas instantáneas a lo largo del tiempo observas que el rendimiento de la máquina virtual decae drásticamente y el disco duro de tu equipo anfitrión se queda sin espacio libre, se debe al crecimiento descontrolado de los ficheros delta de almacenamiento.

Solución: Fusiona y consolida las instantáneas antiguas o elimina los puntos intermedios innecesarios desde el hipervisor para que el sistema combine los cambios y recupere el espacio de almacenamiento ocupado.

Alternativa directa: Gestión de snapshots en KVM mediante virsh

Si utilizas un entorno de virtualización basado en KVM en Linux sin interfaz gráfica, puedes crear una instantánea rápida de la máquina virtual ejecutando el siguiente comando en la terminal del anfitrión:

sudo virsh snapshot-create-as [nombre_vm] --name "snapshot_base" --description "Estado inicial estable"

Preguntas de reflexión:

¿Cómo actúan a nivel interno los ficheros de diferencias o deltas (Copy-on-Write) cuando un hipervisor gestiona múltiples instantáneas encadenadas en una máquina virtual?
¿Por qué las instantáneas (snapshots) no deben considerarse bajo ningún concepto un sustituto válido de un sistema de copias de seguridad (backups) tradicionales?
¿Qué implicaciones de rendimiento y almacenamiento provoca en el equipo anfitrión mantener un árbol complejo con decenas de instantáneas antiguas acumuladas durante semanas?
¿Qué diferencia operativa existe entre realizar una instantánea con la máquina apagada (offline snapshot) frente a realizarla con la máquina encendida incluyendo el estado de la memoria RAM (online snapshot)?

Haz clic aquí para ver las soluciones y explicaciones

1. ¿Cómo actúan a nivel interno los ficheros de diferencias o deltas (Copy-on-Write) cuando un hipervisor gestiona múltiples instantáneas encadenadas en una máquina virtual?

Cuando se toma una instantánea, el disco virtual base se congela dejándose en modo de solo lectura. A partir de ese momento, cualquier escritura o modificación posterior de los datos no altera el disco original, sino que se almacena en un fichero delta independiente (CoW). Si existen varias instantáneas encadenadas, el hipervisor lee los bloques consultando la cadena de ficheros en orden cronológico inverso hasta localizar la versión vigente del dato.

2. ¿Por qué las instantáneas (snapshots) no deben considerarse bajo ningún concepto un sustituto válido de un sistema de copias de seguridad (backups) tradicionales?

Porque una instantánea depende totalmente de la integridad del disco virtual y de la cadena de ficheros delta originales. Si el almacenamiento físico del hipervisor sufre un fallo crítico de bloques, se corrompe el disco base o se elimina por error el contenedor principal, absolutamente todas las instantáneas asociadas se vuelven inservibles. Un backup real reside de forma independiente en un medio de almacenamiento externo y seguro.

3. ¿Qué implicaciones de rendimiento y almacenamiento provoca en el equipo anfitrión mantener un árbol complejo con decenas de instantáneas antiguas acumuladas durante semanas?

Provoca una degradación severa del rendimiento de E/S (Input/Output) del disco, ya que el hipervisor debe realizar múltiples saltos y operaciones de lectura complejas a través de una larga cadena de ficheros delta para localizar un simple bloque de datos. Además, los ficheros deltas crecen de tamaño de forma descontrolada ocupando todo el espacio libre disponible en el almacenamiento del anfitrión.

4. ¿Qué diferencia operativa existe entre realizar una instantánea con la máquina apagada (offline snapshot) frente a realizarla con la máquina encendida incluyendo el estado de la memoria RAM (online snapshot)?

Una instantánea en frío (apagada) guarda únicamente el estado estático del disco en un momento consistente sin actividad en curso, siendo muy segura pero requiriendo interrumpir el servicio. Una instantánea en caliente (online) captura tanto el disco como el contenido completo de la memoria RAM y las conexiones activas en ese instante, permitiendo restaurar el equipo exactamente en el punto de ejecución exacto, aunque requiere mayor espacio de almacenamiento temporal y tiempo de procesamiento.

Páginas

Objetivo:

Escenario:

Escenario Real: Borrado accidental de documentación en soporte externo

Instrucciones:

Fase 1: Conexión segura y diagnóstico del dispositivo de almacenamiento:

Fase 2: Creación de una imagen de respaldo (Clonación forense de seguridad):

Fase 3: Análisis y ejecución del proceso de recuperación de datos:

Fase 4: Elaboración del informe de actuación e incidentes:

Verificación:

Posibles errores y resolución de problemas:

Alternativa directa: Verificación rápida de la estructura del disco

Preguntas de reflexión:

1. ¿Por qué es una norma estricta evitar escribir o guardar nuevos datos en un disco duro externo inmediatamente después de haber borrado información importante por error?

2. ¿Qué diferencia técnica fundamental existe entre recuperar una partición borrada mediante testdisk frente a recuperar archivos sueltos por su firma mediante photorec?

3. ¿Qué importancia tiene realizar una clonación sector a sector (imagen de disco) antes de manipular un soporte de almacenamiento dañado o con datos perdidos?

4. ¿Qué información clave debe contener obligatoriamente un informe técnico post-incidente tras finalizar un proceso de recuperación de datos para una organización?

Objetivo:

Escenario:

Escenario Real: Servidor colapsado por un proceso desbocado

Instrucciones:

Fase 1: Detección global de la carga y uso de recursos:

Fase 2: Identificación precisa del proceso y sus metadatos:

Fase 3: Auditoría de registros (logs) asociados al servicio:

Fase 4: Aplicación de medidas correctoras y mitigación:

Verificación:

Posibles errores y resolución de problemas:

Alternativa directa: Visualización rápida de los procesos más pesados

Preguntas de reflexión:

1. ¿Qué diferencia técnica existe entre enviar una señal de terminación suave (SIGTERM o kill -15) frente a una señal de cierre forzoso (SIGKILL o kill -9) a un proceso desbocado?

2. ¿Cómo influye una fuga de memoria (memory leak) en el rendimiento a largo plazo de un servidor hasta obligar al kernel a actuar mediante el mecanismo OOM Killer?

3. ¿Qué significado técnico aportan los tres valores que componen la carga media del sistema (Load Average) en intervalos de 1, 5 y 15 minutos?

4. ¿Qué utilidad aporta modificar la prioridad de planificación (valores nice) de un proceso pesado en un servidor multitarea saturado?

Objetivo:

Escenario:

Escenario Real: Estación de consulta pública expuesta a manipulación

Instrucciones:

Fase 1: Creación del usuario público restringido:

Fase 2: Aplicación de políticas de contraseñas y caducidad:

Fase 3: Configuración del cortafuegos y bloqueo de servicios de red:

Fase 4: Restricción de software y protección del entorno:

Verificación:

Posibles errores y resolución de problemas:

Alternativa directa: Comprobación rápida del estado del cortafuegos

Preguntas de reflexión:

1. ¿Por qué es fundamental aplicar el principio de mínimo privilegio creando cuentas de usuario totalmente desacopladas del grupo de administración en equipos informáticos de acceso público?

2. ¿Qué ventajas de seguridad aporta configurar una política de cortafuegos restrictiva que bloquee todo el tráfico entrante por defecto en una estación de biblioteca?

3. ¿Cómo actúan a nivel técnico los sistemas de congelación de estado (como OverlayFS o sistemas efímeros) para garantizar que el equipo vuelva a su estado original tras cada reinicio?

4. ¿Qué riesgos implica para la privacidad de los usuarios y la seguridad de la red que un equipo público mantenga activos servicios de acceso remoto como SSH o escritorios compartidos sin restricciones?

Objetivo:

Escenario:

Escenario Real: Preparación integral de una estación de trabajo corporativa

Instrucciones:

Fase 1: Planificación y particionamiento avanzado del almacenamiento:

Fase 2: Instalación del sistema operativo y configuración regional:

Fase 3: Creación de cuentas de usuario y control de privilegios:

Fase 4: Despliegue de software corporativo esencial:

Fase 5: Configuración de copias de seguridad automatizadas:

Verificación:

Posibles errores y resolución de problemas:

Alternativa directa: Comprobación rápida del espacio montado por particiones

Preguntas de reflexión:

1. ¿Qué ventajas operativas y de seguridad aporta separar la partición raíz (/) de la partición de usuario (/home) al aprovisionar un equipo para un empleado?

2. ¿Por qué es una buena práctica de seguridad no otorgar permisos permanentes de administración (grupo sudo) a los usuarios finales en sus estaciones de trabajo diarias?

3. ¿Qué implicaciones tiene utilizar una herramienta como rsync frente a una simple copia manual mediante el comando cp a la hora de realizar copias de seguridad incrementales?

4. ¿Qué finalidad cumple la configuración de un nombre de host estandarizado y estructurado en los equipos informáticos dentro de una red corporativa?

Objetivo:

Escenario:

Escenario Real: Servidor bloqueado con pantalla negra tras actualizar el kernel

Instrucciones:

Fase 1: Arranque externo (Live USB) y verificación del almacenamiento:

Fase 2: Montaje de particiones y vinculación de directorios virtuales:

Fase 3: Cambio de raíz (chroot) y reparación de paquetes rotos:

Fase 4: Reinstalación y actualización del gestor de arranque (GRUB):

Verificación:

Posibles errores y resolución de problemas:

Alternativa directa: Actualización rápida de GRUB desde un sistema operativo accesible

Preguntas de reflexión:

1. ¿Por qué es indispensable vincular los directorios virtuales del kernel (como /dev, /proc y /sys) antes de ejecutar el comando chroot en el sistema de rescate?

2. ¿Qué diferencia técnica existe a la hora de reinstalar GRUB entre un sistema con particionado tradicional MBR y un sistema moderno basado en UEFI?

2. ¿Qué diferencia técnica fundamental existe entre recuperar una partición borrada mediante `testdisk` frente a recuperar archivos sueltos por su firma mediante `photorec`?

1. ¿Qué diferencia técnica existe entre enviar una señal de terminación suave (`SIGTERM` o `kill -15`) frente a una señal de cierre forzoso (`SIGKILL` o `kill -9`) a un proceso desbocado?

1. ¿Qué ventajas operativas y de seguridad aporta separar la partición raíz (`/`) de la partición de usuario (`/home`) al aprovisionar un equipo para un empleado?

3. ¿Qué implicaciones tiene utilizar una herramienta como `rsync` frente a una simple copia manual mediante el comando `cp` a la hora de realizar copias de seguridad incrementales?

1. ¿Por qué es indispensable vincular los directorios virtuales del kernel (como `/dev`, `/proc` y `/sys`) antes de ejecutar el comando `chroot` en el sistema de rescate?

3. ¿Qué función cumple exactamente el comando `update-grub` tras reinstalar el gestor de arranque en el disco duro?

1. ¿Por qué un usuario con permisos de lectura (`r`) sobre los ficheros internos de un directorio no puede acceder a los mismos si carece del permiso de ejecución (`x`) en la carpeta contenedora?

3. ¿Qué implicaciones de seguridad tiene asignar permisos de acceso globales excesivamente laxos (como `777`) en una carpeta compartida frente a utilizar grupos o ACLs específicas?

2. ¿Qué diferencia técnica existe entre auditar la ocupación del almacenamiento mediante bloques de datos (`df -h`) frente a la comprobación de inodos disponibles (`df -i`)?

3. ¿Qué riesgos implica para la estabilidad del sistema operativo eliminar de forma indiscriminada ficheros temporales activos en el directorio `/tmp` sin verificar su uso actual?

4. ¿Por qué se recomienda configurar políticas automatizadas de rotación de registros (como `logrotate`) en los servidores de producción?

1. ¿Por qué un fallo en el montaje de una unidad de red remota dentro del fichero `/etc/fstab` puede congelar el arranque de un sistema Linux durante varios minutos?

2. ¿Qué diferencia técnica existe entre auditar los tiempos muertos con `systemd-analyze blame` frente a analizar el flujo de dependencias críticas con `systemd-analyze critical-chain`?