Operar un servidor web implica más que servir una página: debes controlar cómo escucha, proteger el acceso administrativo, investigar el tráfico y demostrar que los datos importantes pueden restaurarse. Este proyecto basado en desafíos conecta esas responsabilidades en cuatro escenarios Linux cuyo estado final se verifica.
Aprovisionarás Nginx en un puerto personalizado, instalarás una clave pública SSH, auditarás sockets en escucha, reducirás un log de acceso a su cliente más activo y ejecutarás una prueba destructiva de restauración desde un archivo comprimido. Las tareas proporcionan requisitos y pistas, pero tú eliges los comandos y la verificación.
Lo que aprenderás
- Instalar Nginx, cambiar su escucha predeterminada al puerto
8080, desplegar el contenido indicado y reiniciar el servicio - Generar un par de claves SSH RSA, autorizar la clave pública y aplicar permisos
700y600a las rutas SSH - Listar numéricamente sockets TCP en escucha y confirmar que el puerto SSH
22está expuesto - Construir una tubería de texto que cuente solicitudes por IP de origen y extraiga el cliente más activo
- Archivar
/var/www/htmly/var/log/nginxen un tar comprimido con gzip e inspeccionar su contenido - Simular la pérdida de la raíz web, extraer el archivo en
/y verificar que regresa el contenido crítico
A quién va dirigido este curso
Este proyecto está dirigido a estudiantes de Linux y DevOps preparados para aplicar habilidades de servicios web, SSH, procesamiento de logs y copias sin comandos paso a paso.
Requisitos previos: Familiaridad con paquetes y servicios, edición de texto, tuberías shell, archivos SSH, permisos, inspección de sockets y tar; es un proyecto de evaluación.
Entorno de aprendizaje: Un host Ubuntu accesible desde el navegador con sudo, APT, Nginx, herramientas OpenSSH, Zsh, utilidades GNU/Linux y datos web y de logs preparados; no requiere nube ni servidor remoto.
Preguntas frecuentes
¿El desafío SSH desactiva completamente la autenticación por contraseña?
No. Genera /home/labex/.ssh/id_rsa, añade la clave pública a authorized_keys y corrige permisos. No modifica sshd_config, desactiva contraseñas ni prueba un inicio remoto.
¿Cerraré puertos de red inesperados?
No. Usas ss o netstat para listar puertos TCP en escucha numéricamente y confirmar el 22; no se cambian cortafuegos ni se detienen servicios.
¿Cómo se identifica el cliente más activo?
Analizas el primer campo de /var/log/nginx/access.log, agrupas y cuentas las IP, ordenas por frecuencia y guardas solo la principal, 203.0.113.42, en /home/labex/attacker_ip.txt.
¿Qué se elimina y restaura realmente en la prueba?
El archivo incluye la raíz web y los logs de Nginx, pero la pérdida simulada elimina /var/www/html. Extraes el archivo en la raíz y verificas que reaparece index.html con Critical Web Content.
