Preguntas de entrevista de Linux Internals
Processes, permissions, the file system, syscalls and Linux-specific attack and defence.
¿Es 127.0.0.1 la única dirección de loopback?
No. Todo el rango 127.0.0.0/8 está reservado para loopback, así que 127.0.0.2, 127.1.1.1, etc., resuelven todas al host local. Importa para el SSRF y el bypass de listas de permitidos — un atacante puede usar 127.0.0.2 u otras codificaciones para esquivar un control ingenuo de «bloquear 127.0.0.1» — y para enlazar varios servicios locales. (En IPv6, el loopback es la única dirección ::1.)
Durante una respuesta a incidentes encuentras un vacío sospechoso en los registros de autenticación. ¿Qué concluyes y qué haces?
Un vacío en los registros locales durante un incidente puede significar registros borrados o manipulados, un paso antiforense común, así que no trates la ausencia de registros como ausencia de actividad. Coteja con registros centralizados/reenviados, EDR y datos de red que el atacante probablemente no pudo alterar, y documenta el vacío de integridad como un hallazgo. Suponer que el servidor estaba inactivo confía en pruebas que el atacante puede controlar, tratar el vacío como prueba de que no pasó nada es justo la conclusión que él quiere, y borrar más registros destruye lo que queda. Corrobora en su lugar con telemetría independiente.
Investigando un servidor Linux comprometido, ¿dónde buscas la persistencia del atacante?
La persistencia en Linux se esconde en las rutas de ejecución programada y de arranque: cron y timers/unidades de systemd, claves añadidas en authorized_keys SSH, archivos rc del shell y scripts de perfil modificados, y binarios de servicio o bibliotecas precargadas troyanizados. Revísalos sistemáticamente. El historial del navegador y la configuración del fondo de pantalla no son mecanismos de persistencia, y reiniciar no eliminará nada que se restablezca en el arranque — solo lo relanza. El propósito de la persistencia es sobrevivir a los reinicios, así que un reinicio no demuestra nada.
En un host Linux encuentras un archivo escribible por todos, propiedad de root y con el bit SUID activado. ¿Cuál es el riesgo y tu acción?
Un binario SUID-root se ejecuta con privilegios de root, y si es escribible por todos un atacante puede reemplazarlo o modificarlo para ejecutar código arbitrario como root — una vía clásica de escalada de privilegios local. Retira el bit SUID, corrige el propietario y los permisos, e investiga cómo apareció esta mala configuración, ya que puede indicar un compromiso. Cifrar el archivo deja intacta la ruta ejecutable, y renombrarlo solo traslada el problema sin eliminar la escalada. Ninguna de estas opciones aborda la causa raíz.
Explica el orden de volatilidad y por qué dicta la secuencia de recopilación de evidencia en DFIR.
El orden de volatilidad clasifica la evidencia según lo rápido que se desvanece, para recopilar primero lo más frágil. A grandes rasgos: registros/caché de CPU, luego RAM y estado en ejecución (procesos, conexiones de red, ARP), luego archivos temporales/swap, luego disco, luego registro y datos de monitorización remotos y, por último, soportes de archivo y copias de seguridad. También trabajas sobre copias forenses, las hasheas y mantienes una cadena de custodia para que la evidencia siga siendo admisible.
¿Dónde se almacenan los hashes de contraseñas de usuario en Windows y en Linux, y por qué los atacantes apuntan a esos archivos?
En Windows, los hashes de cuentas locales (NTLM) viven en la subárbol SAM en C:\Windows\System32\config\SAM, protegido mientras el SO está en marcha; las credenciales vivas residen en la memoria de LSASS, y los hashes de dominio están en NTDS.dit en un controlador de dominio. En Linux, los hashes están en /etc/shadow (legible solo por root), mientras que /etc/passwd guarda los metadatos de la cuenta. Los atacantes los roban para crackear contraseñas sin conexión o hacer pass-the-hash.
Explícame cómo enumeras una máquina objetivo recién aparecida.
Se empieza con un escaneo completo de puertos TCP y luego se enumera en profundidad cada servicio abierto —banners, versiones, credenciales por defecto, acceso anónimo y contenido web— antes de tocar ningún exploit. La mayoría de las máquinas caen por una enumeración minuciosa, no por exploits ingeniosos, que es el núcleo de la mentalidad «try harder».
Tienes un shell de bajos privilegios en una máquina Linux. ¿Cómo escalas?
Enumera de forma sistemática: revisa sudo -l, los binarios SUID/SGID, las tareas cron, la versión del kernel y del SO, los archivos escribibles en rutas privilegiadas, las capabilities y las credenciales almacenadas. Herramientas como LinPEAS automatizan el barrido, pero aun así verificas cada hallazgo contra GTFOBins o una técnica conocida.
¿Cómo encuentras y usas de forma segura un exploit público contra un objetivo?
Identifica el servicio y la versión exactos, busca en Exploit-DB o searchsploit un PoC que coincida, y luego lee el código línea por línea antes de ejecutarlo: corrige la IP objetivo, el puerto y la dirección del reverse shell, regenera cualquier shellcode y entiende qué hace para que no se vuelva en tu contra.
Consigues un reverse shell pero es inestable. ¿Cómo lo mejoras?
Se lanza un pseudoterminal (normalmente python -c 'import pty; pty.spawn("/bin/bash")'), se envía a segundo plano con Ctrl-Z, se ejecuta stty raw -echo en el lado local, se trae al primer plano y se reinician TERM y el número de filas/columnas. Así obtienes un TTY completo con control de trabajos, autocompletado con tabulador y editores funcionales.
Tienes una shell con pocos privilegios en una máquina Linux. Explícame cómo escalarías a root.
Enumera primero: privilegios actuales, derechos de sudo, binarios SUID/SGID, tareas cron, archivos escribibles en el PATH, versión del kernel y credenciales almacenadas. Luego explota la ruta más sencilla y fiable — a menudo una regla de sudo mal configurada o un GTFOBin SUID — antes de recurrir a un exploit del kernel.
Explica las reverse shells frente a las bind shells y cuándo elegirías cada una.
Una bind shell abre un puerto de escucha en el objetivo y espera a que te conectes a él. Una reverse shell hace que el objetivo se conecte hacia fuera a un listener que tú controlas. Las reverse shells suelen ganar porque el tráfico saliente esquiva las reglas de cortafuegos entrantes y el NAT.
Explícame cómo endurecerías un servidor Linux nuevo expuesto a Internet.
Reducir la superficie de ataque (eliminar paquetes y servicios sin uso), forzar SSH solo por clave sin inicio de sesión root, mantener el sistema parcheado, ejecutar un cortafuegos de denegación por defecto que exponga solo los puertos necesarios, aplicar privilegios mínimos mediante sudo y permisos de archivos, habilitar auditd y registro centralizado, y añadir monitorización de integridad más un MAC como SELinux o AppArmor.
Consigue 100 preguntas de entrevista de ciberseguridad + respuestas
Déjanos tu correo y te enviaremos el pack en PDF gratuito y el mazo de flashcards.
Sin spam. Cancela tu suscripción cuando quieras.