Autor: ciberkaos

  • Montando un Servidor Web con Ubuntu

    Montando un Servidor Web con Ubuntu

    En este documento veremos el proceso y comandos básicos para instalar servicios en un sistema operativo Ubuntu.


    Partiremos de un Ubuntu Server al cual accederemos vía SSH.

    Tecnologías a implementar

    SERVER – HOST

    En la primera fase prepararemos el sistema para acceso remoto con seguridad baja. En la segunda fase securizaremos el servidor.

    Servicios y herramientas:

    • SSH
    • Apache2
    • PHP
    • MySQL
    • FTP
    • CMD o PuTTY para conexión SSH
    • Workbench
    • VS Code vía SSH
    • FileZilla cliente

    1. Conexión SSH

    Primero comprobamos si SSH está instalado:

    dpkg -l | grep openssh-server
    

    Si aparece openssh-server, está instalado. Si no:

    sudo apt install ssh
    

    Una vez instalado, desde Windows o PuTTY:

    ssh usuario@ipdelservidor
    

    2. Instalación de Apache2

    Instalamos Apache:

    sudo apt install apache2
    

    Esto permitirá responder a peticiones HTTP por el puerto 80.

    Si la máquina usa IP dinámica, consulta la IP con:

    ifconfig
    

    (Instalar net-tools si no lo tienes: sudo apt install net-tools)

    Al acceder desde un navegador a la IP del servidor, deberías ver la página por defecto de Apache.

    La carpeta web se encuentra en:

    /var/www/html
    

    Aquí podrás crear tus documentos HTML.


    3. Instalación de MySQL Server

    Instalamos MySQL:

    sudo apt install mysql-server
    

    Ejecutamos script de configuración:

    mysql_secure_installation
    

    Las preguntas:

    1. Set root password? → Y
    2. Remove anonymous users? → Y
    3. Disallow root login remotely? → Y
    4. Remove test database? → Y
    5. Reload privilege tables now? → Y

    Reinicia el servicio:

    sudo systemctl restart mysql
    

    Acceso:

    sudo mysql -u root -p
    

    3.1 Conexión remota a MySQL

    Debemos modificar el archivo mysqld.cnf:

    sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf
    

    Busca:

    bind-address = 127.0.0.1
    

    Cámbialo por:

    0.0.0.0
    

    (Así permitimos conexiones remotas.)

    Políticas de contraseñas MySQL

    Valores: LOW = 0, MEDIUM = 1, STRONG = 2.

    Ver configuración actual:

    SHOW VARIABLES LIKE 'validate_password%';
    

    Cambiar política:

    SET GLOBAL validate_password.policy=LOW;
    

    También puedes personalizar los requisitos:

    SET GLOBAL validate_password.length = 6;
    SET GLOBAL validate_password.number_count = 0;
    

    Según queramos podemos cambiar el valor por LOW, MEDIUM o STRONG
    Ejemplos de contraseñas:

    LOW:
    12345678
    password

    MEDIUM
    Estudiante123@
    Codificador NINZA$100
    demoPass#00

    Esta es la recomendada, por defecto solicita

    • La contraseña debe tener al menos 8 caracteres.
    • El recuento de mayúsculas y minúsculas es 1 (al menos 1 letra en minúscula y 1 letra enmayúscula)
    • El recuento de números es 1
    • El número mínimo de caracteres especiales es 1

    Otra forma de cambiar la politica de contraseñas sería:

    mysql>SET GLOBAL validate_password.policy=0;
    mysql>SET GLOBAL validate_password.policy=1;
    mysql>SET GLOBAL validate_password.policy=2;

    Tambien podemos personalizar los requisitos de cada una, ejemplo:

    mysql>SET GLOBAL validate_password.length = 6;
    mysql>SET GLOBAL validate_password.number_count = 0;

    Ahora que las reglas para una contraseña válida están claras, puedes crear un usuario con
    una contraseña válida


    3.2 Creación de usuario MySql

    Crear usuario:

    CREATE USER 'user'@'127.0.0.1' IDENTIFIED BY 'Estudiante123@';
    CREATE USER 'user'@'%' IDENTIFIED BY 'Estudiante123@';
    

    Al crear el usuario ponemos entre la @ primero el nombre y luego desde donde vamos a
    permitir que se conecte. si es desde localhost, una ip determinada o cualquier sitio.

    Ejemplos:

    CREATE USER ‘user’@’127.0.0.1’ IDENTIFIED BY ‘Estudiante123@’;

    crearemos un usuario con contraseña MEDIUM y que solo se pueda conectar desde
    localhost

    CREATE USER ‘user’@’%%’ IDENTIFIED BY ‘Estudiante123@’;

    Asignar permisos:

    GRANT CREATE, ALTER, DROP, INSERT, UPDATE, DELETE, SELECT, REFERENCES, RELOAD 
    ON *.* TO 'user'@'%' WITH GRANT OPTION;
    

    Aplicar cambios:

    FLUSH PRIVILEGES;
    

    3.3 Conexión desde Workbench

    Ahora que ya tenemos configurado nuestro gestor de mysql y hemos puesto que se pueda
    acceder desde cualquier Ip, instalamos Workbench en nuestro host y nos conectamos.

    En el cliente, instala Workbench y conecta usando:

    • IP del servidor
    • Puerto 3306
    • Usuario creado
    • Contraseña asignada

    4. Instalación del servicio FTP (VSFTPD)

    Instalar:

    sudo apt install vsftpd
    

    Hacemos backup del archivo de configuración:

    sudo cp /etc/vsftpd.conf /etc/vsftpd.conf_old
    

    Editar configuración:

    sudo nano /etc/vsftpd.conf
    

    Pegar:

    listen=NO
    listen_ipv6=YES
    anonymous_enable=NO
    local_enable=YES
    write_enable=YES
    local_umask=022
    dirmessage_enable=YES
    use_localtime=YES
    xferlog_enable=YES
    connect_from_port_20=YES
    chroot_local_user=YES
    secure_chroot_dir=/var/run/vsftpd/empty
    pam_service_name=vsftpd
    rsa_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
    rsa_private_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
    ssl_enable=NO
    pasv_enable=YES
    pasv_min_port=10000
    pasv_max_port=10100
    allow_writeable_chroot=YES
    

    Como hemos realizado una copia de seguridad podemos borrar su contenido, otro truco
    para muchos archivos de configuración en linux es comentar las lineas anteriores con #, o
    simplemente poner la nueva configuración al final del documento.


    *Ubuntu en algunas versiones, viene con un firewall llamado UFW. En este caso le debemos
    de decir que abra el puerto 20, 21 y los del 10000 al 10100 para su correcto funcionamiento

    Abrir puertos en UFW:

    sudo ufw allow from any to any port 20,21,10000:10100 proto tcp
    

    Reiniciar servicio:

    sudo systemctl restart vsftpd
    

    4.1 Acceso vía FTP desde el cliente

    Para transmitir archivos via FTP al servidor podemos usar cualquier programa de
    transmisión de archivos como Filezilla-client

    Utiliza FileZilla-client y conecta usando:

    • IP del servidor
    • Usuario FTP
    • Contraseña
    • Puerto 21

    Cada usuario tendrá acceso a su carpeta.


    4.2 Acceso FTP a la carpeta web de Apache

    Dado que nuestro objetivo es montar un servidor web, debemos tener la opción de poder
    acceder a las carpetas de de apache html, para poder transmitir los archivos de una web,
    imagenes, etc.


    Existe varios modos, veamos el que considero mas sencillo para inicial. Que consiste en
    crear un usuario donde su carpeta personal sea la www de Apache2 y dar permisos a esta
    carpeta.

    Creamos un usuario cuyo directorio sea la carpeta web:

    sudo useradd -m ftpuser
    sudo passwd ftpuser
    

    *Con la opción -m indicamos que nos cree una carpeta para el usuario

    Finalmente, podemos editar el archivo /etc/passwd para cambiar la carpeta al que el usuario
    tendrá acceso.

    sudo nano /etc/passwd   ← Cambia el directorio del usuario.
    

    También podrías jugar con los grupos de usuarios en Linux, para dar acceso a diferentes
    usuarios, algunos comandos útiles que podrías repasar podrían ser:

    Modificar grupos/permisos:

    sudo chgrp -R ftpuser www
    sudo groupadd grupo
    sudo adduser usuario grupo
    sudo chmod -R 775 www
    

    5. Instalación del intérprete PHP

    Instalamos PHP y módulos:

    sudo apt install php libapache2-mod-php php-mysql php-cli
    

    php: el propio interprete, si queremos una versión especifica podriamos poner php8.1, php7,
    etc.


    libapache2-mod-php: Libreria que permite trabajar a apache2 con php (Imprescindible en
    nuestro caso)

    php-mysql: Libreria que permite hacer conexiones desde php a mysql (Imprescindible si
    hacemos app con acceso a bases de datos).

    php-cli: Aunque para un servidor web no es necesario, si es util para ejecutar scripts de php
    directamente en la terminal, para temas de mantenimiento, tareas crontab, envio de
    mensajes, etc.

    Una vez instalado puede comprobar la versión instalada con:

    php -v
    

    Crear archivo de prueba:

    sudo nano /var/www/html/version.php
    

    Contenido:

    <?php
    phpinfo();
    ?>
    

    Dar permisos:

    sudo chmod 775 version.php
    

    Probar desde el navegador: http://IP/version.php


    Ejecución PHP desde terminal

    Crear archivo:

    sudo nano infosys.php
    

    Contenido:

    <?php 
    $os = php_uname(); 
    $cpu = shell_exec('cat /proc/cpuinfo | grep "model name" | head -n 1'); 
    $memTotal = shell_exec('cat /proc/meminfo | grep MemTotal'); 
    $memFree = shell_exec('cat /proc/meminfo | grep MemFree'); 
    $disk = shell_exec('df -h'); 
    
    echo "Información del Sistema:\n";
    echo "Sistema Operativo: $os\n";
    echo "Procesador: $cpu\n"; 
    echo "Memoria Total: $memTotal"; 
    echo "Memoria Libre: $memFree\n"; 
    echo "Espacio en Disco:\n$disk\n"; 
    ?>
    

    Ejecutar:

    php infosys.php
    

    6. Acceso por SSH desde un IDE – Visual Studio Code

    Instalar VSCode: https://code.visualstudio.com/Download

    Instalar extensión: Remote – SSH

    Crear conexión:

    1. Clic en icono de conexión remota.
    2. Add New SSH Host.
    3. Indicar un nombre sin espacios.
    4. Elegir dónde guardar el archivo de configuración.
    5. Indicar sistema operativo remoto (Linux).
    6. Escribir parámetros:
    Host Mi_conexion
      HostName 192.168.x.x
      User ubuntu
    

    Una vez guardado, podrás acceder desde VS Code, abrir carpetas del servidor y usar la terminal integrada.

  • UFW- Securizando  servicios de servidor WEB

    UFW- Securizando servicios de servidor WEB

    Configuración del Firewall en linux UFW

    Mediante el comando ufw podemos configurar el firewall de Linux de forma sencilla. Lo primero que debemos de hacer es ver si esta activo o no.

    sudo ufw status

    Esto nos mostrará la lista de puertos, o en su defecto si esta inactivo. El hecho de estar inactivo supone que tenemos todos los puertos abiertos, lo que es una seria vulnerabilidad.
    ![[Snag_5bd2428.png]]
    Para activarlo, escribimos:

    sudo ufw enable

    NOTA: Debemos tener en cuenta que si estamos conectados vía SSH por el puerto 22, al activar el firewall puede ser que nos expulse, si anteriormente no hemos abierto el puerto.

    Ahora podemos poner, sudo ufw status y nos retornara la configuración actual.

    ![[Snag_5c08db1.png]]
    En este caso, vemos que ya tenemos varios puertos abiertos dado que hemos instalado diferentes servicios.

    Lista de puertos comunes.
    Algunos de los puertos más importantes de los sistemas Linux suelen estar activados por defecto, aunque en algunos casos esto no se da. Hay que tener en cuenta que mantener SSH en el puerto 22 es considerado un riesgo a nivel de seguridad, por lo que se recomienda cambiarlo.

    | Puertos comunes |

    21 > FTP
    22 > SSH
    23 > SFTP
    25 > SMTP
    43 > WHOIS
    53 > Nameservers (sistema DNS)
    80 > HTTP (servidor web, ya sea Apache, Nginx u otro)
    110 > Protocolo POP utilizado para mail.
    111 > rpcbind
    143 > Protocolo IMAP utilizado para mail.
    443 > HTTP seguro (utilizado por certificados SSL a nivel web, https://)
    953 > rndc
    993 > IMAP bajo SSL
    995 > Protocolo POP con SSL
     
    2082 > Panel cPanel
    2083 > cPanel con SSL
    2086 > Panel WHM
    2087 > WHM con SSL
    2095 > Webmail
    2096 > Webmail con SSL
     
    3306 > MySQL
    4643 > Virtuosso
    9999 > Urchin
     
    Panel Plesk > 8443
    Panel DirectAdmin > 2222
    Panel Webmin > 10000 |
    Veamos ahora como abrir o cerrar los puertos según las necesidades de cada servidor.

    Una forma sencilla es indicar directamente el nombre del servicio utilizando la opción de allow.

    sudo ufw allow ssh

    Sin embargo, podemos escribir la regla equivalente especificando el puerto en vez del nombre del servicio. Por ejemplo, este comando funciona como el anterior:

    sudo ufw allow 22

    Si deseamos ver algo mas de información del estado de los puertos, podemos poner

    sudo ufw status verbose

    Otra opción si deseamos habilitar varios puertos que estan consecutivos, podemos indicar el rango.

    sudo ufw allow 6000:6007 /tcp
    sudo ufw allow 6000:6007 /udp

    Esto abriría los puertos del 6000 al 6007

    Cerrar puertos.

    Si deseamos cerrar un puerto que tengamos abierto, podemos cerrarlo con.

    sudo ufw deny 80 

    Esto cerraría el puerto 80 de http evitando conexiones al servidor.

    Habilitar o cerrar puertos con orígenes definidos.

    En ocasiones para mayor seguridad queremos abrir los puertos, pero solo para acceder desde una dirección ip concreta, esto lo realizaremos añadiendo la opción from

      sudo ufw allow from 03.0.113.4

    De este modo solo daremos acceso al equipo con la ip designada. Aunque lo mas común es determinar el o los puertos concretos que queremos que pueda acceder.

     Por ejemplo, si desea permitir que 203.0.113.4 se conecte al puerto 22 (SSH), utilice este comando:

    sudo ufw allow from 203.0.113.4 to any port 22

    Por último si estamos en una infraestructura con diferentes subredes, podemos determinar cual de ellas pueden acceder o no. Por ejemplo una subred para un departamento de una empresa en concreto.

    sudo ufw allow from 203.0.113.0/24

    o si queremos especificar el puerto

    sudo ufw allow from 203.0.113.0/24 to any port 22

    Por numero de regla

    Si utiliza el número de regla para eliminar reglas de firewall, lo primero que le convendrá hacer es obtener una lista de reglas de firewall. El comando “UFW status” tiene una opción para mostrar números junto a cada regla, como se muestra aquí:

    sudo ufw status numbered
    Numbered Output:Status: active
    
         To                         Action      From
         --                         ------      ----
    [ 1] 22                         ALLOW IN    15.15.15.0/24
    [ 2] 80                         ALLOW IN    Anywhere

    Si queremos eliminar la regla 2, que permite las conexiones del puerto 80 (HTTP), podemos especificarlo en un comando “UFW delete”

    sudo ufw delete 2

    Otra forma es hacerlo sin numerar poniendo directamente el servicio a borrar o el numero de puerto. Por ejemplo: desea eliminar la regla allow http, podría escribir lo siguiente:

    sudo ufw delete allow http

    También podría especificar la regla mediante allow 80 en vez de hacerlo por nombre de servicio:

    sudo ufw delete allow 80

    Otros comandos útiles pueden ser:

    Si decide que no desea utilizar UFW, puede desactivarlo con este comando:

    sudo ufw disable

    Si ya configuró reglas de UFW y decide que desea empezar de nuevo, puede utilizar el comando “reset”:

    sudo ufw reset
  • .htaccess EN APACHE (Control, Seguridad y SEO)

    .htaccess EN APACHE (Control, Seguridad y SEO)

    El objetivo de esta práctica es aprender a utilizar archivos .htaccess en un servidor Apache para configurar:

    • Autenticación
    • Gestión de errores
    • Redirecciones
    • Reescritura de URLs
    • Cabeceras de seguridad
    • Control de indexación en buscadores
    • Ocultación y restricción de carpetas
    • Optimización mediante caché y compresión

    Se realizará de forma práctica para observar los efectos directamente.


    Requisitos

    • Apache instalado y funcionando
    • Permisos para editar archivos en /var/www/html/ o carpeta equivalente

    Parte 1: Activación de .htaccess en Apache

    1. Editar el VirtualHost y localizar:
    <Directory /var/www/html>
       AllowOverride None
       Require all granted
    </Directory>
    
    1. Cambiar None por All:
    AllowOverride All
    
    1. Reiniciar Apache:
    sudo systemctl restart apache2
    
    1. Crear un archivo /var/www/html/.htaccess con este contenido:
    AddDefaultCharset UTF-8
    

    Si no hay errores, el .htaccess está funcionando.

    Para editar el VirtualHost típico en Ubuntu/Debian:

    1. Abrir el archivo de sitio por defecto:
    sudo nano /etc/apache2/sites-available/000-default.conf
    
    1. Buscar un bloque <VirtualHost *:80> que contiene algo como:
    <VirtualHost *:80>
        DocumentRoot /var/www/html
        ...
        <Directory /var/www/html>
            Options Indexes FollowSymLinks
            AllowOverride None
            Require all granted
        </Directory>
    </VirtualHost>
    
    1. Aquí vive la línea “AllowOverride” que decide si .htaccess es un ciudadano con derechos o un fantasma ignorado. Cambiar AllowOverride None por AllowOverride All.
    2. Guardar, cerrar y reiniciar Apache:
    sudo systemctl restart apache2
    

    Parte 2: Autenticación Básica con .htaccess

    1. Crear una carpeta /var/www/html/admin/ con un index.html.
    2. Crear /var/www/html/.htpasswd generando un usuario:
    htpasswd -c /var/www/html/.htpasswd admin
    
    1. Crear /var/www/html/admin/.htaccess:
    AuthType Basic
    AuthName "Zona restringida"
    AuthUserFile /var/www/html/.htpasswd
    Require valid-user
    

    Entrar a http://servidor/admin y probar el acceso.

    htpasswd

    htpasswd es una pequeña herramienta de Apache que fabrica archivos de credenciales para la autenticación HTTP básica. Básica significa sin florituras: usuario/contraseña codificados en Base64 y enviados en cabecera; útil para poner una puerta rápida delante de una carpeta, una página de administración o un endpoint casero.

    Funciona generando un fichero (normalmente .htpasswd) con uno o varios usuarios y sus contraseñas hash. Este fichero luego lo consumes desde .htaccess o desde la configuración del VirtualHost.

    1. Abres la terminal en tu servidor.
    2. Ejecutas:
    htpasswd -c /ruta/al/fichero/.htpasswd nombreusuario
    

    El -c crea el fichero. Si ya existe y quieres añadir otro usuario, lo omites:

    htpasswd /ruta/al/fichero/.htpasswd otro_usuario
    

    Al ejecutar, te pedirá contraseña y te la meterá en el fichero con hash. El algoritmo por defecto suele ser bcrypt/MD5 APR según versión; lo importante es que nunca guarda contraseñas en claro.

    Un .htpasswd típico se ve así:

    juan:$apr1$9tDRSv/.v8BxP1kF/Np7A.
    maria:$apr1$OQy4dRxr$2aCdBORded8HNoo.t2GxU.
    

    Luego en .htaccess pones la compuerta:

    AuthType Basic
    AuthName "Zona restringida"
    AuthUserFile /ruta/al/fichero/.htpasswd
    Require valid-user
    

    El navegador, al entrar en esa carpeta, lanzará un cuadro de login del siglo pasado (que sigue cumpliendo su función). En HTTPS está bien para control de acceso simple; en HTTP es como mandar postales sin sobre.

    Parte 3: Gestión de Errores Personalizados

    1. Crear 404.html y 403.html en la raíz.
    2. Añadir en /var/www/html/.htaccess:
    ErrorDocument 404 /404.html
    ErrorDocument 403 /403.html
    
    1. Probar introduciendo una URL inexistente.

    Parte 4: Cabeceras de Seguridad

    Añadir en /var/www/html/.htaccess:

    Header set X-Frame-Options "DENY"
    Header set X-Content-Type-Options "nosniff"
    Header set X-XSS-Protection "1; mode=block"
    Header set Referrer-Policy "no-referrer-when-downgrade"
    Header set Permissions-Policy "geolocation=()"
    

    Explicación breve:

    • X-Frame-Options: DENY Esta prohíbe que tu página se cargue dentro de un <iframe> de otra página. ¿Para qué sirve? Para evitar el clickjacking, un truco donde otra web maliciosa mete la tuya en un iframe invisible y coloca botones encima, de manera que el usuario cree estar haciendo una cosa y está pulsando otra. Con DENY, el navegador dice “no me meto en iframes de nadie” y así se acaba el truco de magia.
    • X-Content-Type-Options: nosniff Los navegadores suelen ser listillos: si reciben un archivo con un tipo incorrecto, intentan adivinarlo (“sniffing MIME”). Eso abre una puerta curiosa: si subes un .png que en realidad es JavaScript con una cabecera errónea, algunos navegadores podrían intentar ejecutarlo. Con nosniff el navegador promete no “oler” el tipo y usar sólo lo declarado. Evita ciertos vectores de XSS y descarga ejecutable camuflada.
    • X-XSS-Protection: 1; mode=block Esto es un modo antiguo del filtro anti-XSS integrado en algunos navegadores. Le indica al navegador que si detecta un ataque de Cross-Site Scripting reflejado, bloquee la carga de la página en vez de intentar sanearla. Hoy en día está un poco de capa caída (Chrome lo retiró en favor de Content-Security-Policy) pero en entornos legacy todavía es un salvavidas aceptable.
    • Referrer-Policy: no-referrer-when-downgrade Cada vez que pulsas un enlace, el navegador suele enviar una cabecera Referer (sin la segunda “r”, por herencia histórica) indicando desde qué página vienes. Esa miguita de pan puede revelar urls privadas, parámetros de sesión o rutas internas. no-referrer-when-downgrade ordena no enviar el Referer cuando pasas de HTTPS a HTTP (es decir, no “degradar” seguridad). Existen políticas más estrictas (strict-origin, no-referrer, etc.), pero esta ya reduce filtraciones triviales.
    • Permissions-Policy: geolocation=() Aquí entramos en una política moderna que controla APIs del navegador. Es como darle a tu web un panel de permisos: cámara, micrófono, geolocalización, sensores… geolocation=() significa “no concedo geolocalización a nadie, ni siquiera a mí”. Puedes ser más granular, por ejemplo geolocation=(self) permitiría sólo a tu propio dominio. Eso reduce el “exceso de curiosidad” del navegador y de scripts de terceros.
    • El resumen conceptual es que no protegen tu código del mal, sino que recortan la superficie de comportamiento del navegador, reduciendo trucos clásicos: iframes invisibles, tipos MIME engañosos, ejecución de scripts inesperados y filtración de metadatos. Es parecido a darle menos herramientas a un niño travieso: no podrá arreglar un coche, pero tampoco desmontar la casa.

    Más allá de estas cabeceras existen otras piezas más finas como Content-Security-Policy (CSP), que es una gramática entera para decir “qué scripts, imágenes, estilos y conexiones están permitidos”. CSP convierte el navegador en una especie de sandbox configurable, y ahí es donde el mundo del XSS moderno se vuelve deporte olímpico.

    Parte 5: Redirecciones HTTP

    1. Redirección permanente (301):
    Redirect 301 /viejo.html /nuevo.html
    
    1. Temporal (302):
    Redirect 302 /promo /promo-2026
    

    Recomendación: usar 301 solo cuando sea definitivo.

    Cuando haces una redirección 302 (Found / Moved Temporarily) estás diciendo dos cosas:

    — Primero: “el recurso sigue existiendo en la URL original, pero por ahora estoy sirviendo desde otra URL”.

    — Segundo: “no actualices tus mapas, no caches esto como definitivo”.

    Consecuencias prácticas:

    1. Los navegadores no la memorizan como algo fijo.
      No guardan en disco que la URL ha cambiado. Si mañana quitas la redirección, el navegador volverá a pedir la original sin pelearse contigo. Es como poner un cartel de “pasen por la puerta lateral mientras pintamos la principal”.
    2. Los buscadores no transfieren ‘peso’ SEO.
      A diferencia de un 301, Google y compañía no asumen que la URL nueva es la buena. Mantienen la original en sus índices. Es la forma de decirles: “no reorganices tu mapa, solo estoy haciendo obras”.
    3. No cambia los enlaces de terceros.
      Si un usuario sigue un enlace desde otra web, la redirección lo mueve, pero esa web no actualizará su enlace, porque no hay garantía de permanencia.
    4. Sirve para pruebas y mantenimiento.
      Si estás desplegando un nuevo diseño, probando un AB testing o moviendo tráfico durante un rato, una 302 te da una especie de reversibilidad instantánea.

    En contraste, un 301 (Moved Permanently) es como una mudanza registrada en el ayuntamiento: los navegadores pueden cachearla, los buscadores actualizan índices y pasan “autoridad” a la nueva URL, y los cambios tardan más en revertirse porque todos asumen que era definitivo.

    Lo temporal no cambia la cartografía del navegador ni del buscador, solo redirige el tráfico en tiempo real. Es útil cuando estás probando algo, cuando tienes dudas o cuando quieres mantener la puerta original como referencia verdadera. Luego, cuando estés seguro de la mudanza, ya haces el 301 y los mapas del mundo cambian de sitio.

    Parte 6: Reescritura de URLs con mod_rewrite

    La reescritura de URLs permite transformar una URL solicitada por el navegador en otra diferente de forma interna, sin que el usuario lo note. Se utiliza para crear URLs más limpias, eliminar extensiones (.php, .html) o implementar un patrón MVC (Front Controller).


    6.1 Activación del módulo

    Activar el módulo responsable de la reescritura:

    sudo a2enmod rewrite
    sudo systemctl restart apache2
    

    Sin este módulo, las reglas de reescritura no funcionarán.


    6.2 Requisito en el VirtualHost

    Dentro del VirtualHost debe estar permitido el uso de .htaccess. En el bloque <Directory> debe existir:

    AllowOverride All
    

    Si estuviera en None, Apache ignorará las reglas del .htaccess.


    6.3 Ejemplo simple: eliminar extensión

    Crear un archivo hola.html en el DocumentRoot (/var/www/html/).

    Crear o editar el .htaccess en el mismo directorio con:

    RewriteEngine On
    RewriteRule ^hola$ hola.html [L]
    

    • RewriteEngine On → activa el motor de reescritura
    • RewriteRule ^hola$ hola.html → si se solicita /hola, entregar hola.html
    • [L] → indica que esta es la última regla si coincide

    Prueba

    Acceder en el navegador:

    http://servidor/hola
    

    Aunque el archivo real sea hola.html, el navegador verá una URL sin extensión.


    6.4 Ejemplo avanzado: patrón MVC (Front Controller)

    Este patrón es común en frameworks y sitios dinámicos. La idea es que todas las peticiones que no sean archivos ni carpetas reales se envían a index.php.

    6.4.1 Código

    En el .htaccess del DocumentRoot:

    RewriteEngine On
    
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule ^(.+)$ index.php?route=$1 [L,QSA]
    

    6.4.2 Explicación de las condiciones

    • RewriteCond %{REQUEST_FILENAME} !-f
      → si lo solicitado no es un archivo físico
    • RewriteCond %{REQUEST_FILENAME} !-d
      → si lo solicitado no es un directorio

    6.4.3 Explicación de la regla

    • ^(.+)$ → coincide con cualquier ruta solicitada
    • index.php?route=$1 → envía la ruta al script index.php mediante el parámetro route
    • [L,QSA]:
      • L → última regla si coincide
      • QSA → preserva parámetros existentes (?id=3 etc.)

    6.5 Demostración práctica

    Crear un archivo index.php con:

    <?php
    echo "Ruta solicitada: " . ($_GET['route'] ?? 'ninguna');
    ?>
    

    Acceder desde el navegador a distintas rutas:

    http://servidor/productos
    http://servidor/usuarios/editar/7
    http://servidor/pepito
    

    Salida esperada:

    Ruta solicitada: productos
    Ruta solicitada: usuarios/editar/7
    Ruta solicitada: pepito
    

    Esto confirma que index.php captura todas las rutas y puede decidir qué controlador o vista cargar.


    6.6 Caso especial: archivos reales

    Si se accede a:

    /style.css
    /logo.png
    /index.php
    

    o cualquier recurso físico, NO pasa por la reescritura porque las condiciones lo impiden:

    RewriteCond %{REQUEST_FILENAME} !-f   → archivo físico
    RewriteCond %{REQUEST_FILENAME} !-d   → directorio físico
    

    De esta forma no se rompe el funcionamiento del sitio.


    6.7 Uso habitual en aplicaciones web

    Este sistema se utiliza para:

    • URLs amigables para SEO
    • Frameworks PHP (Laravel, Symfony, CodeIgniter)
    • Paneles de administración
    • APIs REST
    • Front Controllers (único punto de entrada)

    En lugar de:

    index.php?route=usuarios/listar
    

    se obtiene:

    /usuarios/listar
    

    más limpio y apto para buscadores.

    La reescritura de URLs no cambia el archivo real que se ejecuta, solo traduce internamente la ruta.
    El usuario ve una URL limpia y el servidor recibe una ruta estructurada para procesar.

    Parte 7: Control del Listado de Directorios

    Para evitar que se muestren archivos:

    Options -Indexes
    

    Crear una carpeta sin index.html y comprobar el resultado.


    Parte 8: Forzar HTTPS

    Añadir:

    RewriteEngine On
    RewriteCond %{HTTPS} !=on
    RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
    

    Requiere certificado SSL configurado.


    Parte 9: Cacheo y Compresión

    Cache de archivos (si mod_expires activado):

    <IfModule mod_expires.c>
       ExpiresActive On
       ExpiresByType image/jpeg "access plus 30 days"
       ExpiresByType text/css "access plus 7 days"
       ExpiresByType application/javascript "access plus 7 days"
    </IfModule>
    

    Compresión (si mod_deflate activado):

    SetOutputFilter DEFLATE
    

    Cuando decíamos “cache de archivos (si mod_expires activado)” nos referíamos a una función del servidor web Apache diseñada para decirle al navegador cuánto tiempo puede guardar ciertos archivos sin volver a descargarlos.

    En castellano llano:

    La caché es la costumbre del navegador de guardar copias locales de cosas que ya descargó (como imágenes, CSS o JavaScript) para no pedirlas de nuevo al servidor cada vez que visitas la página. Si ya tienes el logo en tu disco, ¿para qué volver a bajarlo?

    El módulo mod_expires es una parte de Apache que permite controlar cuánto dura esa copia local, poniendo un “fecha de caducidad” en las respuestas.

    Si lo activas y configurás reglas como:

    ExpiresByType image/png "access plus 30 days"
    

    Estás diciendo: “los archivos PNG pueden vivir 30 días en la caché del navegador”.

    ¿Resultado práctico? La primera visita carga todo desde el servidor, las siguientes cargan desde disco; la web vuela y el servidor descansa.

    Esencialmente, es un acuerdo temporal entre servidor y navegador, parecido a:

    – Servidor: “Este archivo apenas cambia, guárdalo un mes”.
    – Navegador: “Perfecto, no te molesto hasta que pase ese mes”.

    En el ecosistema web, la caché es una de las razones por las que las páginas parecen “instantáneas” después de la primera visita, y una forma elegante de reducir gasto de CPU, ancho de banda y tiempo de espera. Sin caché, cada visita sería como entrar por primera vez en un supermercado cada día: todo el mundo preguntando todo el rato dónde están los pasillos.

    Parte 10: Interacción con Buscadores (SEO y Indexación)

    robots.txt

    Crear en raíz del sitio:

    User-agent: *
    Disallow: /admin/
    Disallow: /backup/
    

    Nota: los bots maliciosos pueden ignorarlo.

    Evitar indexación con HTTP (X-Robots-Tag)

    En .htaccess:

    Header set X-Robots-Tag "noindex, nofollow"
    

    Usos habituales:

    • PDFs
    • Paneles internos
    • Carpetas privadas

    Bloquear bots por User-Agent

    Ejemplo:

    RewriteEngine On
    RewriteCond %{HTTP_USER_AGENT} googlebot [NC]
    RewriteRule ^ - [R=403]
    

    Parte 11: Ocultación y Restricción de Carpetas

    Impedir acceso web a una carpeta:

    Dentro de la carpeta crear .htaccess:

    Require all denied
    

    O por archivo:

    <FilesMatch "\.(sql|bak|zip|tar)$">
       Require all denied
    </FilesMatch>
    

    Restringir por IP:

    Require ip 192.168.1.0/24
    

    Evitar ejecución de PHP en carpetas de subida:

    <FilesMatch "\.(php|phtml)$">
       Require all denied
    </FilesMatch>
    

    Muy útil en uploads/ o storage/.


    Con .htaccess es posible:

    • Restringir acceso
    • Personalizar errores
    • Crear URLs amigables
    • Controlar bot y rastreadores
    • Proteger información sensible
    • Forzar HTTPS
    • Mejorar SEO
    • Mejorar rendimiento

    Advertencia para producción:

    • .htaccess se evalúa en cada petición
    • Incrementa carga del servidor
    • En grandes entornos se recomienda configurar desde VirtualHost

  • ¿Qué hace systemctl?

    ¿Qué hace systemctl?

    Un servicio es un proceso de fondo (daemon) que se ejecuta sin cliente directo: servidor web, base de datos, cupón/leche… cosas que viven en silencio.

    systemd organiza los servicios como units (unidades). Una unit puede ser:

    • service → servicios
    • timer → programadores sustitutos del cron
    • mount → puntos de montaje
    • socket → servicios socket-activados
    • y más fauna, pero hoy nos interesa el zoológico *.service.

    ¿Qué hace systemctl?

    systemctl permite:

    • Iniciar/detener un servicio.
    • Habilitarlo o deshabilitarlo en arranque.
    • Ver logs y estado.
    • Ver dependencias.

    Su sintaxis general:

    systemctl <acción> <unidad>

    Ejemplo:

    systemctl start apache2.service

    Ver servicios instalados

    Esto ayuda a explorar el sistema:

    Servicios activos ahora mismo:

    
    
    
    
    
    systemctl list-units --type=service --state=running
    

    Todos los servicios cargados (activos + inactivos):

    
    
    
    
    
    systemctl list-units --type=service
    

    Servicios instalados en el sistema (cargados y no cargados):

    
    
    
    
    
    systemctl list-unit-files --type=service
    

    Estado de un servicio

    Es la acción más frecuente.

    
    
    
    
    
    systemctl status apache2.service
    

    Muestra:

    • PID
    • Logs recientes
    • “Loaded” (si está instalado)
    • “Active” (si está corriendo)

    La magia aquí es que systemd integra parte del journal, así que ya da contexto.


    Iniciar / Detener / Reiniciar

    Aquí es donde la clase empieza a levantar humo.

    Iniciar servicio:

    
    
    
    
    
    sudo systemctl start apache2.service
    

    Detener:

    
    
    
    
    
    sudo systemctl stop apache2.service
    

    Reiniciar de forma limpia:

    
    
    
    
    
    sudo systemctl restart apache2.service
    

    Recargar configuración sin detener el servicio (si lo soporta, como Nginx):

    
    
    
    
    
    sudo systemctl reload nginx.service
    

    Para puristas: restart tira y relanza, reload solo recarga configuración.


    Habilitar en el arranque

    Esto conecta systemd con los “targets” (equivalentes modernos de runlevels).

    Habilitar:

    
    
    
    
    
    sudo systemctl enable apache2.service
    

    Deshabilitar:

    
    
    
    
    
    sudo systemctl disable apache2.service
    

    Comprobar si está habilitado:

    
    
    
    
    
    systemctl is-enabled apache2.service
    

    Esto crea o elimina enlaces simbólicos en /etc/systemd/system/.


    Ver logs de un servicio

    journalctl es el diario íntimo del sistema. Útil para debugging y para descubrir que olvidaste escapar ese símbolo en la config de Postfix.

    Logs recientes del servicio:

    
    
    
    
    
    journalctl -u apache2.service
    

    Logs en tiempo real (“modo Matrix”):

    
    
    
    
    
    journalctl -u apache2.service -f
    

    Logs de hoy con timestamps:

    
    
    
    
    
    journalctl -u apache2.service --since today
    

  • Caso Práctico DS1: Análisis de Tráfico Web y Login con Wireshark (2)

    Caso Práctico DS1: Análisis de Tráfico Web y Login con Wireshark (2)

    Aprender a capturar y analizar tráfico de red con Wireshark, identificar credenciales transmitidas en claro, interpretar paquetes HTTP y localizar patrones que un pentester o analista usaría para detectar:

    • Credenciales expuestas
    • Cookies de sesión
    • Estructura de peticiones al servidor
    • Intentos de ataque (básico)
    • Fingerprinting indirecto del hosting

    1. Preparación del entorno

    1.1. Material necesario

    • Wireshark instalado
    • Navegador web
    • La URL de vuestra aplicación PHP en el hosting

    1.2. Configuración previa

    1. Abrir Wireshark
    2. Elegir la interfaz correcta:
      • En WiFi: suele ser wlan0 o similar
      • En cable: eth0
    3. Aplicad un filtro pre-captura opcional para no saturar: tcp port 80 or tcp port 443

    2. Captura del tráfico (la parte divertida)

    2.1. Comenzar la captura

    1. En Wireshark → seleccionad interfaz → botón azul Start capture.
    2. Dejad Wireshark escuchando en segundo plano.

    2.2. Generar tráfico real

    En vuestra aplicación PHP:

    1. Entrad en la página del login.
    2. Haced:
      • 1 intento fallido
      • 1 intento correcto
    3. Navegad un poco por el CRUD (listar, ver, editar).

    Esto genera tráfico muy fácil de reconocer.


    3. Filtrado y análisis del tráfico HTTP

    3.1. Filtrar solo HTTP

    En la barra de filtros de Wireshark:

    http
    

    Observad cómo aparecen las peticiones:

    • GET /login.php HTTP/1.1
    • POST /login.php HTTP/1.1
    • Peticiones a JS, CSS, etc.

    Entrega:

    • Captura del primer filtro HTTP mostrando al menos 8–10 paquetes.

    4. Análisis de un login (¡a por credenciales!)

    Vamos a buscar el POST del login.

    4.1. Filtro preciso del POST

    http.request.method == "POST"
    

    Seleccionad el paquete que corresponda a vuestro login.

    4.2. Abrir el contenido del POST

    En el panel inferior → Hypertext Transfer Protocol → Form-urlencoded.

    Deberíais ver algo como:

    username=juan
    password=1234
    

    (¡si la web no usa HTTPS y el hosting no lo fuerza!)

    4.3. Preguntas para entregar

    1. ¿El login viaja en claro o cifrado?
    2. Si viaja cifrado, ¿qué aparece en su lugar?
    3. Si viaja en claro, copiáis:
      • usuario
      • contraseña
      • parámetros adicionales

    💡 Esta parte impacta mucho: “Así de fácil es robar credenciales sin HTTPS.”


    5. Análisis de cookies y sesión

    5.1. Buscar cookies de sesión

    Filtro:

    http.set_cookie
    

    o:

    http.cookie
    

    Localizad:

    • PHPSESSID=xxxxxxx u otro identificador.

    5.2. Preguntas para entregar

    1. ¿La cookie tiene flags Secure, HttpOnly, SameSite?
    2. ¿Se envía en la misma petición del login?
    3. ¿Se reutiliza durante toda la sesión?
    4. ¿Podríais robarla si el tráfico no fuese HTTPS?

    6. Identificación de servidor y tecnologías mediante tráfico

    Aunque no usemos WhatWeb, Wireshark también revela cosas interesantes.

    6.1. Buscad cabeceras del servidor

    Filtro:

    http.server
    

    y:

    http.response
    

    Podéis encontrar:

    • Server: Apache/2.4.54
    • X-Powered-By: PHP/8.1.12

    7. Detectar patrones de ataque (mini-reto)

    Ahora vamos a “jugar” con el tráfico que vosotros mismos habéis generado.

    Hacer desde otra máquina:

    • un par de intentos de fuerza bruta
    • navegación rara
    • errores 404
    • probad rutas prohibidas

    7.1. Filtrar errores del servidor

    http.response.code >= 400
    

    7.2. Preguntas

    1. ¿Qué tipo de errores aparecen más?
    2. ¿Alguna IP destaca como “sospechosa”?
    3. ¿Puedes reconstruir qué intentaba hacer ese cliente?
      (por ejemplo: intentar acceder a /admin/ o /backup/)

    8. Bonus: reconstrucción de sesión (Follow TCP Stream)

    Seleccionad cualquier paquete HTTP → botón derecho:

    Follow → TCP Stream

    Miraréis la conversación completa entre cliente y servidor como si fuese un chat textual.

    Entrega:

    1. Captura del stream
    2. Comentad:
      • ¿Qué información sensible se ve?
      • ¿Podríais reproducir manualmente alguna petición?

    9. Conclusiones finales (informe corto)

    Cada alumno debe redactar:

    9.1. Hallazgos importantes

    • ¿Se ven credenciales?
    • ¿Se identifican cookies inseguras?
    • ¿Qué tecnologías se filtran?
    • ¿Alguna ruta interesante/extraña?

    9.2. Riesgos detectados

    3 riesgos mínimos (exposición de tecnología, falta de HTTPS, cookies inseguras…)

    9.3. Recomendaciones

    3 medidas de mejora:

    • Forzar HTTPS
    • Ocultar versión del servidor
    • Flag HttpOnly en cookies
    • Deshabilitar rutas innecesarias
  • Caso Práctico DS1: Fingerprinting y superficie de ataque (3)

    Caso Práctico DS1: Fingerprinting y superficie de ataque (3)

    enéis desplegada una pequeña aplicación PHP (CRUD + login) en un hosting compartido.

    En esta práctica vais a poneros en la piel de un analista de ciberseguridad que tiene permiso para auditar solo ese sitio web. El objetivo es:

    • Identificar tecnologías y versiones que usa la web (fingerprinting).
    • Descubrir rutas y ficheros interesantes (superficie de ataque).
    • Detectar posibles debilidades de configuración.

    ⚠️ Regla de oro: Solo podéis escanear el dominio/URL que os ha dado el profesor. Nada de escanear webs ajenas “por probar”.


    1. Preparación del entorno

    1.1. Datos que debes tener

    Anota en tu cuaderno o documento:

    • URL de la aplicación:
      Ejemplo: https://grupoX.miapp.ejemplo.com
    • (Opcional) IP del servidor si el profe la da:
      Ejemplo: 123.45.67.89

    1.2. Herramientas a usar

    En un Linux (real o máquina virtual) instalad, si no están:

    sudo apt update
    
    # WhatWeb (fingerprinting web)
    sudo apt install whatweb -y
    
    # Nikto (escáner de vulnerabilidades web)
    sudo apt install nikto -y
    
    # Gobuster (fuerza bruta de directorios)
    sudo apt install gobuster -y
    
    # Wordlist básica (si no la tenéis)
    sudo apt install wordlists -y
    

    Comprobad que funcionan:

    whatweb --version
    nikto -Version
    gobuster -h
    

    2. Fingerprinting básico del servidor web (WhatWeb + cabeceras)

    2.1. Resolver el dominio

    1. Desde la terminal, comprobad a qué IP resuelve vuestro dominio:
    ping -c 3 TU_DOMINIO
    

    Sustituye TU_DOMINIO por tu URL (sin https://).
    Ejemplo:

    ping -c 3 grupoX.miapp.ejemplo.com
    
    1. Anota:
      • IP a la que resuelve
      • Tiempo de respuesta aproximado

    Entrega: captura de pantalla o copia del comando y el resultado.


    2.2. Cabeceras HTTP con curl

    Queremos ver qué nos cuenta el servidor solo con las cabeceras.

    1. Ejecuta:
    curl -I https://TU_DOMINIO
    
    1. Fíjate en:
    • Server: (Apache, Nginx, etc., ¿con versión?)
    • X-Powered-By: (¿PHP con versión?)
    • Si hay algo como Set-Cookie:, etc.

    Entrega:

    • copia de las cabeceras
    • responde brevemente:
      • ¿Se está filtrando la versión exacta del servidor o PHP?

    2.3. Fingerprinting con WhatWeb

    Ahora usamos WhatWeb para identificar tecnologías:

    whatweb https://TU_DOMINIO
    

    Si quieres más detalle:

    whatweb -v https://TU_DOMINIO
    

    Analiza:

    • ¿Detecta CMS (WordPress, etc.)?
    • ¿Versiones de Apache/PHP?
    • ¿Librerías JS, frameworks?

    Entrega:

    • salida de WhatWeb (resumen)
    • lista de tecnologías detectadas
    • marca con un asterisco las que muestren versión concreta, ejemplo:
      • PHP 8.1.12 *
      • Apache 2.4.54 *

    3. Análisis de configuración con Nikto

    Nikto es un escáner de vulnerabilidades web orientado a configuración y ficheros por defecto.

    3.1. Lanzar un escaneo básico

    Ejecuta:

    nikto -h https://TU_DOMINIO
    

    Según el hosting puede tardar un poco.

    Mientras tanto, ve leyendo las líneas: muchas veces indican ficheros interesantes, redirecciones, opciones inseguras, etc.

    3.2. Interpretar resultados

    Cuando termine, revisa:

    • ¿Detecta archivos o directorios por defecto (ej: /phpinfo.php, /server-status, /test/)?
    • ¿Algún mensaje tipo “OSVDB”, “might be vulnerable to…”?
    • ¿Alguna recomendación de deshabilitar cosas?

    Entrega:

    1. Lista de 3–5 hallazgos relevantes de Nikto. Para cada uno:
      • Qué ha encontrado (ruta / mensaje).
      • Por qué podría ser un problema.
    2. Indica si crees que hay algo que debería deshabilitarse/eliminarse en el servidor.

    (Si el hosting está muy capado y Nikto no ve casi nada, eso también es un hallazgo: coméntalo.)


    4. Fuerza bruta de rutas y directorios con Gobuster

    Aquí empezamos a descubrir “piezas” ocultas de la aplicación: paneles, copias de seguridad, etc.

    4.1. Elección de wordlist

    Usaremos una wordlist relativamente pequeña para no machacar el hosting.

    Por ejemplo:

    ls /usr/share/wordlists/dirb/
    

    Una habitual:

    • /usr/share/wordlists/dirb/common.txt

    4.2. Lanzar Gobuster (modo dir)

    Comando base:

    gobuster dir \
      -u https://TU_DOMINIO \
      -w /usr/share/wordlists/dirb/common.txt \
      -t 30 \
      -x php,txt,html
    

    Explicación:

    • -u: URL objetivo
    • -w: wordlist
    • -t: hilos (no os flipéis, que es un hosting compartido)
    • -x: extensiones a probar (.php, .txt, .html)

    4.3. Analizar resultados

    Fíjate en entradas con códigos de estado interesantes:

    • 200 → existe y responde bien
    • 301/302 → redirecciones
    • 403 → existe pero está prohibido (¡ojo, puede haber algo interesante detrás!)

    Entrega:

    • Lista de rutas interesantes encontradas. Ejemplo:
      • /admin/ (200)
      • /backup/ (403)
      • /old/ (200)
    • Para cada una, explica:
      • ¿Crees que deberían ser accesibles?
      • ¿Podrían contener datos sensibles?

    5. Mini-conclusiones de seguridad

    Al final de la práctica, responde a estas preguntas en un pequeño informe (1–2 páginas):

    1. Fingerprinting
      • ¿Qué servidor web y versión usa vuestro hosting?
      • ¿Qué versión de PHP se expone (si es visible)?
      • ¿Se muestran cabeceras innecesarias (X-Powered-By, etc.)?
    2. Superficie de ataque
      • ¿Qué directorios ocultos/localizaciones interesantes habéis encontrado?
      • ¿Habéis visto algún archivo de configuración, backup, antiguo…?
    3. Riesgos
      • Señala al menos 3 riesgos potenciales que habéis identificado.
      • Para cada uno, describe:
        • Cómo lo habéis descubierto (herramienta + comando).
        • Qué podría hacer un atacante con ello.
    4. Recomendaciones
      • Escribe 3 medidas que propondrías al responsable del hosting:
        • Ejemplos: ocultar versión de servidor, borrar backups públicos, restringir /admin, etc.
  • Practica [OSINT]- SEÑALES DE VIDA (O ALGO PEOR) EN LA RED

    Practica [OSINT]- SEÑALES DE VIDA (O ALGO PEOR) EN LA RED

    Operación Nostromo: búsqueda de dispositivos comprometidos antes de que “algo” despierte…


    La nave USCSS Nostromo ha recibido una transmisión automática desde un sistema remoto. No se sabe si es una llamada de socorro… o una advertencia.
    La compañía ha encomendado al Equipo de Investigación (tus alumnos) usar Shodan para rastrear:

    1. Señales de dispositivos expuestos
    2. Orígenes de la transmisión
    3. Infraestructura del sistema remoto
    4. Posibles vectores de intrusión

    La misión: analizar patrones, encontrar conexiones y trazar el mapa de un “nido” digital escondido.

    La actividad se divide en 3 fases, cada una con un objetivo claro y un filtro de Shodan.

    FASE 1 — Localizar señales: “Ping de movimiento”

    Objetivo: practicar filtros por tipo de dispositivo + país/ciudad.

    El sensor de movimiento de la Nostromo detecta actividad anómala en una zona del sistema. Necesitamos saber qué dispositivos expuestos hay allí.

    Tareas:

    1. Buscar un tipo concreto de dispositivo (puerta automatizada, cámara IP, sistema industrial, etc.) Ejemplos:
      • Cámaras IP:
        product:GoAhead
        product:"Hikvision"
        port:554 has_screenshot:true
      • Paneles web expuestos:
        http.title:"login"
    2. Añadir filtro de ubicación (país o ciudad).
      Por ejemplo, España: country:ES product:GoAhead O por ciudad: city:Madrid http.title:login
    3. Apuntar IP, puerto, captura y versión como si fueran “señales biológicas”.


    FASE 2 — Identificar el origen de la transmisión

    Objetivo: buscar por organización o dominio.

    La señal parece provenir de una colonia (una empresa, universidad o dominio). Deben “explorar todas las instalaciones” de ese lugar.

    Ejercicios:

    1. Elegir una organización pública o conocida:
      Ejemplos: org:"Universidad Complutense" org:"Telefonica"
    2. Buscar todos los dispositivos de la misma entidad: hostname:"uic.es" hostname:"unizar.es"
    3. Revisar patrones:
      • ¿Qué puertos están abiertos?
      • ¿Qué servicios viejos aparecen?
      • ¿Hay dispositivos iguales repartidos por varias sedes?

    “Se detectan varias salas técnicas, ventilación, terminales…”
    Vamos, un nido perfecto para un xenomorfo.


    FASE 3 — Conexión entre señales: seguir el rastro del xenomorfo

    Objetivo: enlazar un dispositivo concreto → el resto del ecosistema.


    Han encontrado una máquina sospechosa que transmite paquetes extraños. La misión es identificar todo el entorno que la rodea.

    Cómo hacerlo:

    1. Selecciona un dispositivo que hayas encontrado en Fase 1.
    2. Observan:
      • dominio
      • ASN
      • organización
      • versión del servicio
    3. Construyen una nueva búsqueda:

      IP: 82.X.X.X
      org: "Ayuntamiento de ___"
      port 443 running nginx 1.18.0


      Entonces buscar:

      org:"Ayuntamiento de ___"
      product:"nginx"


      O incluso por ASN:

      asn:3352 (o el ASN que toque)

    4. Buscan patrones:
      • ¿Hay varios dispositivos vulnerables?
      • ¿Alguno tiene panel expuesto?
      • ¿Coinciden versiones?

    Misión Ash (ciencia sintética)

    Encontrar un dispositivo antiguo que no debería seguir activo:

    os:"Windows XP"
    

    o

    "Server: Apache/2.2"
    

    Misión Ripley: “Purgar la amenaza”

    Buscar servicios críticos abiertos sin autenticación:

    port:22 "OpenSSH_7"
    port:21 Anonymous
    

    Misión Bishop (android leal)

    Buscar paneles que tengan captura para analizar visualmente:

    has_screenshot:true city:Barcelona


    Registros:

    Informe breve estilo Weyland-Yutani
    (Ejemplo de redacción)

    • Recomendación para “contención”
    • Descripción de la amenaza detectada
    • Pruebas (capturas de Shodan)
    • Hipótesis del “nido” o red asociada

    (Ejemplo de redacción estilo Weyland-Yutani de la ficción de Alien)


    Alternativas interesantes a Shodan

    Herramienta / buscadorQué la hace útil / especialidad
    CensysEscanea infraestructura global, con foco extra en certificados SSL/TLS, puertos, hosts — útil para mapear superficie de ataque de forma sistemática. 5 Minute Breach+2We Live Security+2
    ZoomEyeSimilar a Shodan; ampliamente usada fuera del “mainstream” occidental. Puede servir para comparar visiones distintas del Internet expuesto. MarPoint+2SecurityVision.ru+2
    BinaryEdgePermite monitorear servicios, puertos abiertos, SSL, accesos remotos — y recibir alertas. Buena opción para vigilancia continua o auditorías periódicas. We Live Security+2LearnHub+2
    FofaOfrece sintaxis de búsqueda avanzada, lo que facilita búsquedas muy específicas (por puerto, servicio, sello de software, etc.). Puede servir bien para ejercicios dirigidos. We Live Security+1
    GreyNoiseNo es exactamente un “scanner” de dispositivos, sino más bien un filtro de ruido: ayuda a clasificar qué direcciones/IPs simplemente están haciendo escaneos automáticos masivos (ruido) frente a actividad potencialmente relevante. Útil para refinar resultados (filtrar falsos positivos). We Live Security+2LearnHub+2
    NetlasPlataforma más reciente, pensada para descubrimiento y monitorización global de “activos conectados”. Puede ser útil si buscas comparar con herramientas más consolidadas. SecurityVision.ru+2Netlas+2

    ⚠️ Cosas a tener en cuenta

    • Ninguna herramienta cubre todos los dispositivos — pueden faltar muchos servicios expuestos, por bloqueo, firewalls, NAT, técnicas de evasión.
    • Los datos recogidos (puertos, software, banners) pueden estar desactualizados o ser engañosos: muchas veces los sistemas cambian o los banners son falsos.
    • Uso de herramientas externas implica responsabilidad ética — incluso si lo haces con fines académicos, siempre debe mantenerse respeto por la privacidad y normas legales.
  • R3.1 – Programación-bucles

    R3.1 – Programación-bucles

    Ejercicio 1

    Contando del 1 al 10

    Crea un programa en Java que muestre por pantalla los números del 1 al 10 utilizando un bucle for.

    Requisitos:

    1. El programa debe tener una clase llamada Contador.
    2. Dentro del método main, utiliza un bucle for para recorrer los números del 1 al 10.
    3. En cada iteración, imprime el número actual en una nueva línea.

    Salida esperada:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    
    

    Ejercicio 2

    Cuenta atrás de 100 a 0 en pasos de 10

    Crea un programa en Java que haga una cuenta atrás desde 100 hasta 0, restando 10 en cada paso.

    Cuando llegue a 0, debe mostrar el mensaje «Máquina hackeada».

    Requisitos:

    1. El programa debe tener una clase llamada CuentaAtras10.
    2. Dentro del método main, usa un bucle for que empiece en 100 y vaya disminuyendo de 10 en 10 hasta llegar a 0.
    3. En cada iteración imprime el número actual.
    4. Al finalizar, muestra el texto Máquina hackeada.

    Salida esperada:

    100
    90
    80
    70
    60
    50
    40
    30
    20
    10
    0
    Máquina hackeada
    
    

    Ejercicio 3

    Realiza un algoritmo que simule una caja registradora de un supermercado, donde va pidiendo cantidades y las va sumando, cada vez que pongamos una cantidad por la terminal saldra la suma acumulada del total.

    El programa dejara de pedir las cantidades de compra cuando insertemos un 0.

    En ese momento mostrara el total de la compra y nos pedira que le indiquemos con cuanto dinero nos pagan e indicara el cambio que debemos devolver.

    Ejemplo de ejecución:

    Introduce la cantidad de la compra (0 para finalizar): 25.50
    Suma acumulada: 25.50
    Introduce la cantidad de la compra (0 para finalizar): 40.00
    Suma acumulada: 65.50
    Introduce la cantidad de la compra (0 para finalizar): 15.75
    Suma acumulada: 81.25
    Introduce la cantidad de la compra (0 para finalizar): 0
    Total a pagar: 81.25
    Con cuánto dinero te pagan? 100.00
    Cambio a devolver: 18.75
    

    Ejercicio 4

    Desarrollar un programa en Java que genere un dibujo usando únicamente el carácter asterisco (*). Este ejercicio te ayudará a entender mejor el control de bucles y el diseño de patrones en la consola.

    Descripción:

    Tu tarea es crear un programa que dibuje una pirámide de asteriscos. La altura de la pirámide será determinada por el usuario al inicio del programa.

    Requisitos:

    1. El programa debe pedir al usuario que introduzca un número entero positivo, el cual representará la altura de la pirámide.
    2. Utiliza bucles for o while para generar el patrón.
    3. La pirámide debe estar alineada a la izquierda, sin utilizar espacios para centrar las líneas.

    Ejemplo de salida:

    Si el usuario ingresa 5, el programa deberá mostrar el siguiente patrón:

    *
    **
    ***
    ****
    *****
    

    Ejercicio 5

    Crea un programa en Java que muestre el siguiente patrón usando dos bucles for anidados:

    Salida esperada:

    54321
    4321
    321
    21
    1
    
    

    Requisitos:

    1. Crea una clase llamada PatronDel5al1.
    2. Dentro del método main, utiliza un primer bucle for para controlar las filas, que empiece en 5 y termine en 1.
    3. Dentro de ese bucle, usa otro for que empiece en el valor de la fila y baje hasta 1.
    4. Después del bucle interno, imprime un salto de línea (System.out.println()).

  • R3.2 Programación-Bucles

    R3.2 Programación-Bucles

    Walter White y Jesse Pinkman han cocinado 1000 pastillas de «mentaanfetamienta» en su caravana.

    Cada pastilla tiene una calidad aleatoria entre 0 y 100.

    El “señor del pollo” (Gus Fring) solo acepta aquellas con calidad mayor o igual que 90.

    RETO 1: “El recuento del lote”

    Calcular cuántas pastillas tienen una calidad superior a 90.

    Pistas:

    • Usa Random para generar números del 0 al 100.
    • Usa un for para simular las 1000 pastillas.
    • Usa un contador para las “buenas”.

    Ejemplo de salida:

    Pastillas totales: 1000
    De calidad superior: 128
    

    RETO 2: “Hasta lograr la receta perfecta”

    Walter repite la cocción hasta que consiga una pastilla con calidad 100.

    Pistas:

    • Genera números aleatorios entre 0 y 100.
    • Detén el bucle cuando salga 100.
    • Muestra cuántos intentos necesitó.

    Ejemplo:

    ¡Perfecta! Calidad 100 obtenida tras 57 intentos.
    

    RETO 3: “La producción nocturna”

    Walter y Jesse producen pastillas hasta llegar a 1000 unidades buenas (≥90).

    Muestra cuántas totales han hecho (incluyendo las malas).

    Ejemplo:

    Para conseguir 1000 pastillas buenas, produjeron un total de 8732.
    

    RETO 4: “El análisis por lotes”

    Dividir la producción en 10 lotes de 100 pastillas y mostrar cuántas buenas hay en cada lote.

    Salida esperada:

    Lote 1 → 13 pastillas buenas
    Lote 2 → 8 pastillas buenas
    ...
    Lote 10 → 11 pastillas buenas
    
    

    RETO 5: “Promedio de calidad”

    Calcular el promedio total de calidad de las 1000 pastillas.

    Salida:

    Promedio de calidad general: 72.38
    
    

    RETO 6 (extra): “La inspección de Gus Fring”

    Genera pastillas hasta tener 500 buenas, pero cada vez que salgan 50 malas seguidas, muestra:

    🔥 Gus Fring sospecha del laboratorio...
    
    

    Ayuda:

    Chuleta Java – Math, Random y String


    🔹 Clase Math (no necesita crear objeto)

    Usa directamente: Math.metodo()

    MétodoDescripciónEjemploResultado
    Math.abs(x)Valor absolutoMath.abs(-5)5
    Math.max(a,b)Mayor de dos valoresMath.max(8,3)8
    Math.min(a,b)Menor de dos valoresMath.min(8,3)3
    Math.pow(a,b)Potencia (a^b)Math.pow(2,3)8.0
    Math.sqrt(x)Raíz cuadradaMath.sqrt(9)3.0
    Math.round(x)Redondea al entero más cercanoMath.round(3.6)4
    Math.floor(x)Redondea hacia abajoMath.floor(3.9)3.0
    Math.ceil(x)Redondea hacia arribaMath.ceil(3.1)4.0
    Math.random()Número aleatorio entre 0 y 1Math.random()0.0–0.999...
    Math.PIConstante πMath.PI3.14159…
    Math.EConstante eMath.E2.71828…

    Ejemplo práctico:

    double area = Math.PI * Math.pow(5, 2);
    
    

    🎲 Clase Random

    Primero importa y crea el objeto:

    import java.util.Random;
    Random r = new Random();
    
    
    MétodoDescripciónEjemploResultado
    r.nextInt(n)Entero entre 0 y n-1r.nextInt(10)0–9
    r.nextInt(max - min + 1) + minEntero entre min y maxr.nextInt(21) + 8080–100
    r.nextDouble()Decimal entre 0.0 y 1.0r.nextDouble()0.0–0.999...
    r.nextBoolean()Verdadero o falsor.nextBoolean()true / false

    Ejemplo:

    int dado = r.nextInt(6) + 1; // 1 a 6
    
    

    🧵 Clase String

    Recuerda: los String son objetos, y sus métodos se invocan sobre la variable:

    texto.metodo()

    MétodoDescripciónEjemploResultado
    length()Longitud del texto"Hola".length()4
    charAt(i)Carácter en posición i"Hola".charAt(1)'o'
    toUpperCase()Convierte a mayúsculas"hola".toUpperCase()"HOLA"
    toLowerCase()Convierte a minúsculas"HOLA".toLowerCase()"hola"
    equals(cadena)Compara textos (sensible a mayúsculas)"Hola".equals("hola")false
    equalsIgnoreCase(cadena)Compara ignorando mayúsculas/minúsculas"Hola".equalsIgnoreCase("hola")true
    substring(inicio, fin)Extrae parte del texto"Java".substring(1,3)"av"
    indexOf(cadena)Posición de una subcadena"Hola".indexOf("la")2
    contains(cadena)¿Contiene la subcadena?"Hola".contains("Ho")true
    startsWith(prefijo)¿Empieza por…?"Hola".startsWith("Ho")true
    endsWith(sufijo)¿Termina en…?"Hola".endsWith("la")true
    trim()Elimina espacios al inicio y final" Hola ".trim()"Hola"
    replace(a, b)Sustituye texto"Hola".replace("a","e")"Hole"

    Ejemplo combinado:

    String nombre = " Antonio ";
    System.out.println(nombre.trim().toUpperCase());
    
    

    ⚗️ Extra para curiosos

    Rango aleatorio con Math (sin Random):

    int n = (int)(Math.random() * 21) + 80; // 80–100
    
    
  • R3.3 – Arrays – Bienvenido al mundo de Mr. Robot

    R3.3 – Arrays – Bienvenido al mundo de Mr. Robot

    Evil Corp —el gigante que controla todo lo que consumes, lo que piensas y hasta lo que olvidas— cree tenerlo todo bajo control.

    Pero no contaba contigo.

    En un sótano lleno de cables, pantallas parpadeantes y tazas de café frías, un grupo de hackers conocidos como Atriumsociety prepara su próximo golpe digital. Su misión: devolver el poder a la gente, línea de código a línea de código.

    Tu papel comienza aquí.

    Eres parte del equipo. Hoy no vienes a “hacer ejercicios”, vienes a infiltrarte en el sistema, Cada array que declares es una base de datos secreta, cada bucle un intento de intrusión, cada condicional una decisión que puede cambiarlo todo.

    Prepárate: el prompt está parpadeando.

    Atriumsociety te necesita.

    1. “Elliot vs Evil Corp”

    Enunciado:

    Elliot ha interceptado una lista con los balances de Evil Corp.

    Con el siguiente array:

    int[] balances = {12000, -50, 5000, 15000, 0, -300, 800, 22000, 9999, 100};
    
    

    Muestra:

    • Cuántas cuentas tienen saldo negativo.
    • Cuántas tienen saldo superior a 10 000 $.
    • El saldo medio.

    2. “Backdoor Scanner”

    Enunciado:

    Darlene analiza si los servidores de Evil Corp están vulnerables.

    Usa el siguiente array:

    boolean[] vulnerables = {false, true, false, false, true, false, true, false};
    
    

    Muestra:

    • Cuántos servidores son vulnerables (true).
    • En qué posiciones están.

    3. “Password Audit”

    Enunciado:

    Elliot encuentra las siguientes contraseñas antiguas de Evil Corp:

    String[] passwords = {"admin123", "e@mpl3", "supersecure99", "pass", "root@2020"};
    
    

    Indica:

    • Cuántas contienen el carácter @.
    • Cuántas tienen más de 8 caracteres.
    • Cuántas terminan en un número.
    • Cuál es la más larga.

    4. “Hack the Gibson”

    Enunciado:

    Simula los niveles de éxito de los ataques de Elliot con el siguiente array:

    int[] intentos = {82, 13, 45, 79, 90, 5, 33, 72, 18, 65, 40, 100, 29, 10, 67, 55, 88, 60, 14, 3};
    
    

    Muestra:

    • El valor máximo y el mínimo.
    • Cuántos intentos fueron “exitosos” (más de 70).
    • Si todos son menores de 30, muestra “Mr Robot sospecha que estás desconectado”.

    5. “Logs del Servidor”

    Enunciado:

    Angela revisa los registros de acceso de un servidor:

    String[] logs = {"OK", "ERROR", "OK", "OK", "ERROR", "OK", "ERROR", "ERROR", "OK", "OK"};
    
    

    Cuenta:

    • Cuántos accesos fueron "OK".
    • Cuántos "ERROR".
    • Si hay más errores que accesos correctos, muestra “Servidor en peligro”.

    6. “Temperaturas del Servidor”

    Enunciado:

    Durante un ataque, Elliot monitoriza las temperaturas del servidor:

    int[] temperaturas = {45, 49, 52, 57, 60, 59, 55, 48, 46, 50};
    
    

    Calcula:

    • La temperatura media.
    • Cuántas mediciones superan los 55 °C.
    • Si todas las temperaturas están por debajo de 60 °C, muestra “Sistema estable”; si alguna es 60 o más, muestra “¡Sobrecalentamiento detectado!”.

    7. “DDoS Simulator”

    Enunciado:

    Durante un ataque DDoS, se registran los siguientes tiempos de respuesta (en ms):

    int[] tiempos = {200, 540, 720, 150, 950, 330, 480, 510, 870, 610};
    
    

    Muestra:

    • La media, el máximo y el mínimo.
    • Si más del 60 % supera los 500 ms, muestra “Servidor saturado”.
    • Si menos del 10 % supera los 200 ms, muestra “Ataque fallido”.