Categoría: Sistemas

  • Actividad – Script interactivo para gestión de red con Netplan

    Actividad – Script interactivo para gestión de red con Netplan


    En entornos Linux de servidor, la configuración de red es un elemento crítico. Un error puede dejar el sistema incomunicado, inaccesible por SSH o fuera de la red. En Ubuntu Server moderno, la gestión de red se realiza mediante Netplan, que utiliza archivos YAML para definir cómo se configuran las interfaces.

    En administraciones reales, cambiar entre IP dinámica (DHCP) y IP estática es una tarea habitual:

    • Laboratorios → DHCP automático
    • Servidores → IP fija y controlada
    • Máquinas virtuales → cambios frecuentes
    • Entornos de pruebas → configuraciones rápidas

    Automatizar esta tarea reduce errores humanos y permite aplicar buenas prácticas de administración.


    Se te pide desarrollar un script en Bash interactivo que permita:

    • Cambiar una interfaz de red entre DHCP y IP estática
    • Solicitar datos al usuario
    • Validar entradas básicas
    • Generar automáticamente el archivo de configuración Netplan
    • Aplicar los cambios con netplan apply
    • Crear copias de seguridad antes de modificar la configuración
    • Ofrecer un menú interactivo

    Requisitos técnicos

    El script debe:

    1. Ejecutarse únicamente como root
    2. Verificar que existe el archivo de Netplan
    3. Permitir elegir entre:
      • Configuración DHCP
      • Configuración IP estática
      • Salir
    4. En modo IP estática debe solicitar:
      • Dirección IP
      • Máscara en formato CIDR
      • Gateway
      • DNS
    5. Confirmar datos antes de aplicar cambios
    6. Crear copia de seguridad automática del archivo original
    7. Mostrar el archivo generado antes de aplicar
    8. Aplicar configuración con netplan apply
    9. Gestionar errores básicos

    Restricciones

    • El script debe estar escrito íntegramente en Bash
    • No se permite editar Netplan manualmente fuera del script
    • No se permite copiar directamente soluciones externas
    • Debe funcionar en Ubuntu Server con Netplan

    Análisis de solución

    Una vez terminado tu script puedes comparalo con el ejemplo de solución.

    Deberás:

    • Comparar tu solución con la propuesta
    • Detectar mejoras posibles
    • Identificar:
      • Validaciones adicionales
      • Buenas prácticas usadas
      • Manejo de errores
      • Estructura del código
      • Modularización en funciones

    El objetivo no es solo que funcione… sino entender cómo se escribe un script robusto de administración real.


    Ejemplo de solucion

    1. Idea general del script

    El script en Bash hará:

    1. Detectar qué archivo de Netplan estoy usando (normalmente algo como /etc/netplan/00-installer-config.yaml).
    2. Mostrar un menú en consola:
        1. Configurar IP estática
        1. Configurar IP dinámica (DHCP)
        1. Salir
    3. Según la opción:
      • Pedirá los datos necesarios (IP, máscara, gateway, DNS) si es estática.
      • Generará un archivo YAML de Netplan con esa configuración.
      • Ejecutará netplan apply para aplicar los cambios.

    IMPORTANTE:

    • Necesitaré ejecutarlo como root (sudo ./script.sh), porque va a escribir en /etc/netplan/.
    • Debo saber el nombre de la interfaz (por ejemplo enp0s3 o ens33). Lo puedo consultar mediante ip a o ifconfig

    2. Ejemplo de archivo Netplan (referencia rápida)

    Consulto mi archivo actual de Netplan mediante ls /etc/netplan primero y sudo cat /etc/netplan/50-cloud-init.yaml obteniendo las siguientes:

    DHCP (IP dinámica)

    network:
      version: 2
      ethernets:
        enp0s3:
          dhcp4: true

    «

    IP estática

    network:
      version: 2
      renderer: networkd
      ethernets:
        enp0s3:
          dhcp4: false
          addresses:
            - 192.168.1.50/24
          gateway4: 192.168.1.1
          nameservers:
            addresses:
              - 8.8.8.8
              - 1.1.1.1
    

    Nuestro script generará algo parecido según la opción que elijas.


    3. Script completo en Bash

    Mediante sudo nano script_cambiar_ip_netplan.sh,creo el script dentro de mi carpeta de scripts con ruta /home/mario/scripts. En su interior introduzco los siguientes parámetros de configuración:

    #!/usr/bin/env bash
    
    # ==========================================================
    # Script para cambiar entre IP estática y dinámica (DHCP)
    # en Ubuntu Server usando Netplan.
    #
    # Úsalo con:
    #   sudo ./cambiar_ip_netplan.sh
    # ==========================================================
    
    # ---------- CONFIGURACIÓN BÁSICA A EDITAR ----------
    # Nombre de la interfaz de red (ajústalo a tu caso: enp0s3, ens33, etc.)
    INTERFACE="enp0s3"
    
    # Archivo de Netplan a usar
    NETPLAN_FILE="/etc/netplan/50-cloud-init.yaml"
    # Si tu sistema usa otro, cámbialo aquí, por ejemplo:
    # NETPLAN_FILE="/etc/netplan/50-cloud-init.yaml"
    # ---------------------------------------------------
    
    # Comprueba que se ejecuta como root
    if [[ "$EUID" -ne 0 ]]; then
      echo "Este script debe ejecutarse como root. Usa: sudo $0"
      exit 1
    fi
    
    # Comprueba que existe el archivo de Netplan
    if [[ ! -f "$NETPLAN_FILE" ]]; then
      echo "ERROR: No se encuentra el archivo de Netplan: $NETPLAN_FILE"
      echo "Revísalo y edita el script para apuntar al archivo correcto."
      exit 1
    fi
    
    # Función para pausar
    pausa() {
      echo
      read -rp "Pulsa Enter para continuar..." _;
    }
    
    # Función para configurar DHCP
    configurar_dhcp() {
      echo "Configurando interfaz $INTERFACE con IP dinámica (DHCP)..."
    
      # Hacemos copia de seguridad
      cp "$NETPLAN_FILE" "${NETPLAN_FILE}.backup_$(date +%Y%m%d_%H%M%S)"
    
      cat > "$NETPLAN_FILE" <<EOF
    network:
      version: 2
      renderer: networkd
      ethernets:
        $INTERFACE:
          dhcp4: true
    EOF
    
      echo "Archivo Netplan generado:"
      echo "----------------------------------------"
      cat "$NETPLAN_FILE"
      echo "----------------------------------------"
    
      echo "Aplicando cambios con netplan apply..."
      netplan apply
    
      if [[ $? -eq 0 ]]; then
        echo "Configuración DHCP aplicada correctamente."
      else
        echo "Hubo un error al aplicar la configuración. Revisa el archivo YAML."
      fi
    
      pausa
    }
    
    # Función para configurar IP estática
    configurar_estatica() {
      echo "Configuración de IP estática para la interfaz: $INTERFACE"
      echo
    
      read -rp "Introduce la IP (ej: 192.168.1.50): " IP
      read -rp "Introduce la máscara en CIDR (ej: 24 para 255.255.255.0): " CIDR
      read -rp "Introduce la puerta de enlace (gateway) (ej: 192.168.1.1): " GATEWAY
      read -rp "Introduce DNS (separados por espacio, ej: 8.8.8.8 1.1.1.1): " DNS_ENTRIES
    
      # Validaciones básicas (muy simples)
      if [[ -z "$IP" || -z "$CIDR" || -z "$GATEWAY" || -z "$DNS_ENTRIES" ]]; then
        echo "Algún campo está vacío. Cancelando configuración."
        pausa
        return
      fi
    
      echo
      echo "Resumen de la configuración estática:"
      echo "  IP:           $IP/$CIDR"
      echo "  Gateway:      $GATEWAY"
      echo "  DNS:          $DNS_ENTRIES"
      echo
    
      read -rp "¿Es correcto? (s/n): " CONFIRM
      if [[ "$CONFIRM" != "s" && "$CONFIRM" != "S" ]]; then
        echo "Configuración cancelada."
        pausa
        return
      fi
    
      # Creamos una copia de seguridad del archivo actual
      cp "$NETPLAN_FILE" "${NETPLAN_FILE}.backup_$(date +%Y%m%d_%H%M%S)"
    
      # Generamos lista YAML de DNS
      DNS_YAML=""
      for dns in $DNS_ENTRIES; do
        DNS_YAML+="          - $dns"$'\n'
      done
    
      # Escribimos nueva configuración en el archivo Netplan
      cat > "$NETPLAN_FILE" <<EOF
    network:
      version: 2
      renderer: networkd
      ethernets:
        $INTERFACE:
          dhcp4: false
          addresses:
            - $IP/$CIDR
          gateway4: $GATEWAY
          nameservers:
            addresses:
    $(echo -n "$DNS_YAML")
    EOF
    
      echo "Archivo Netplan generado:"
      echo "----------------------------------------"
      cat "$NETPLAN_FILE"
      echo "----------------------------------------"
    
      echo "Aplicando cambios con netplan apply..."
      netplan apply
    
      if [[ $? -eq 0 ]]; then
        echo "Configuración estática aplicada correctamente."
      else
        echo "Hubo un error al aplicar la configuración. Revisa el archivo YAML."
      fi
    
      pausa
    }
    
    # Menú principal
    while true; do
      clear
      echo "=============================================="
      echo "   Cambiar configuración de red (Netplan)"
      echo "   Interfaz actual: $INTERFACE"
      echo "   Archivo Netplan: $NETPLAN_FILE"
      echo "=============================================="
      echo "1) Usar IP dinámica (DHCP)"
      echo "2) Usar IP estática"
      echo "3) Salir"
      echo "----------------------------------------------"
      read -rp "Elige una opción [1-3]: " OPCION
    
      case "$OPCION" in
        1)
          configurar_dhcp
          ;;
        2)
          configurar_estatica
          ;;
        3)
          echo "Saliendo..."
          exit 0
          ;;
        *)
          echo "Opción no válida."
          pausa
          ;;
      esac
    done
    

    4. Cómo usarlo paso a paso

    1. Crear el archivo del script: sudo nano script_cambiar_ip_netplan.sh Pega el contenido anterior, guarda y cierra (Ctrl+O, Enter, Ctrl+X).
    2. Dar permisos de ejecución: sudo chmod +x script_cambiar_ip_netplan.sh
    3. Editar variables según tu caso:
      • Abre el script y cambia: INTERFACE="enp0s3" NETPLAN_FILE="/etc/netplan/50-cloud-init.yaml" Pon el nombre de la interfaz que tengas y el archivo real de Netplan.
    4. Ejecutar el script como root: sudo ./script_cambiar_ip_netplan.sh
    5. Elegir opción del menú:
      • Si eliges estática, introduce:
        • IP (ej. 192.168.0.50)
        • CIDR (ej. 24)
        • Gateway (ej. 192.168.0.1)
        • DNS (ej. 8.8.8.8 1.1.1.1)

    5. Recomendaciones para no quedarte “sin red”

    • Haz pruebas estando en consola local (no por SSH), para que si te quedas sin red aún tengas acceso.
    • El script crea copias de seguridad del YAML original con nombre tipo:
      • /etc/netplan/00-installer-config.yaml.backup_20251206_153055
    • Si algo sale mal, puedes restaurar: sudo cp /etc/netplan/00-installer-config.yaml.backup_YYYYMMDD_HHMMSS /etc/netplan/00-installer-config.yaml sudo netplan applyM

    6. Evidencias de funcionamiento del Script en mi UbuntuServer.

    • A continuación adjunto distintas capturas de pantallas de mi UbuntuServer en las que puedo seleccionar las distintas opciones (yo no asignaré IP fija en este momento, ya que quiero seguir trabajando con mi server mediante DHCP)

    Arrancamos el script seleccionado la config por DHCP:

    Aquí vemos las opciones que nos ofrece, sin seleccionar ninguna:

    En esta simulamos introducir los parámetros para configurar IP estática:

    Y en esta última seleccionamos la opción de salir, y hacemos un ip a donde evidencia la asignación de IP por DHCP:

  • [Reto] – Aletheia un Sistema de Auditoría y Análisis Forense Automatizado

    [Reto] – Aletheia un Sistema de Auditoría y Análisis Forense Automatizado

    El término aletheia proviene del griego antiguo αλήθεια y significa «verdad», pero con un matiz profundo que va más allá de una simple correspondencia con la realidad; se refiere al «desocultamiento del ser» o al proceso de hacer evidente lo que estaba oculto.

    En entornos profesionales de administración de sistemas, auditoría y ciberseguridad, el análisis de evidencias no se realiza en el equipo personal del analista.
    Los datos —logs, resultados de auditoría, informes técnicos o documentación sensible— se envían a servidores dedicados, diseñados para procesar información de forma controlada, trazable y reproducible.

    El proyecto Aletheia plantea la construcción de uno de estos servidores.

    Aletheia es una máquina independiente dentro de la red cuya función no es almacenar información ni ofrecer servicios al usuario final, sino transformar evidencias técnicas en conocimiento estructurado.
    Para ello, integra un motor de inteligencia artificial local, accesible únicamente desde el propio servidor, que actúa como sistema de análisis y apoyo a la toma de decisiones.

    A diferencia de soluciones basadas en la nube, este servidor:

    • no envía información a terceros,
    • no depende de conectividad externa,
    • y permite mantener control total sobre los datos analizados.

    Durante el desarrollo del proyecto, el alumnado diseñará y desplegará un servicio capaz de:

    • recibir archivos y evidencias técnicas,
    • procesarlos de forma segura y estática,
    • analizarlos desde una perspectiva de auditoría o forense,
    • y generar informes claros, coherentes y reutilizables.

    El objetivo no es “usar IA”, sino integrarla como parte de una arquitectura real de sistemas, entendiendo su papel como herramienta de análisis, no como sustituto del criterio técnico.

    Este proyecto reproduce un escenario habitual en organizaciones reales, donde la inteligencia no reside en el usuario final, sino en la infraestructura que da soporte al análisis.

    Fase 1 — Puesta a punto del servidor

    Requisitos mínimos de la VM

    1. Crea una VM en VirtualBox:
      • Ubuntu Server 22.04/24.04 (64-bit)
      • 4 vCPU
      • 8 GB RAM
      • 40 GB disco
      • Red: Adaptador puente

    Instala Ubuntu Server y crea un usuario (no root), por ejemplo: alumno.


    1) Actualiza el sistema

    sudo apt update && sudo apt -y upgrade
    sudo reboot
    

    2) Instala herramientas base

    Instalar utilidades básicas:

    • curl
    • unzip
    • jq
    • python3
    sudo apt -y install curl unzip jq ca-certificates gnupg python3 python3-venv python3-pip
    

    3) Configura hostname (opcional pero recomendado)

    sudo hostnamectl set-hostname forense-ai
    

    Comprueba:

    hostnamectl
    

    4) Comprueba IP del servidor

    ip a
    

    Fase 2 — Instalar y probar Ollama

    5) Instala Ollama

    curl -fsSL https://ollama.com/install.sh | sh
    

    6) Comprueba que el servicio está activo

    sudo systemctl status ollama --no-pager
    

    7) Descarga un modelo ligero (recomendado para VM)

    ollama pull phi3
    

    8) Prueba que responde

    ollama run phi3 "Resume en 5 líneas qué es una auditoría de sistemas."
    

    Si esto funciona, ya tienes “motor IA” listo.

    Fase 3 — Instalar Apache + PHP (interfaz web)

    9) Instala Apache y PHP

    sudo apt -y install apache2 php libapache2-mod-php
    

    10) Habilita y arranca Apache

    sudo systemctl enable --now apache2
    

    11) Abre el firewall (solo si lo estás usando)

    Si tienes UFW activo:

    sudo ufw allow 'Apache'
    sudo ufw status
    

    12) Comprueba acceso web

    Desde tu PC (host), abre:

    • http://IP_DEL_SERVIDOR/

    Debes ver la página por defecto de Apache.


    Fase 4 — Crear la estructura del servicio “Forense-AI”

    13) Crea carpetas del proyecto

    sudo mkdir -p /var/www/forense-ai/{uploads,results,scripts,logs}
    sudo chown -R www-data:www-data /var/www/forense-ai
    sudo chmod -R 750 /var/www/forense-ai
    

    14) Crea un VirtualHost

    sudo nano /etc/apache2/sites-available/forense-ai.conf
    

    Pega esto:

    <VirtualHost *:80>
        ServerName forense-ai.local
        DocumentRoot /var/www/forense-ai
    
        <Directory /var/www/forense-ai>
            Options -Indexes
            AllowOverride All
            Require all granted
        </Directory>
    
        ErrorLog ${APACHE_LOG_DIR}/forense-ai_error.log
        CustomLog ${APACHE_LOG_DIR}/forense-ai_access.log combined
    </VirtualHost>
    

    Activa el sitio:

    sudo a2ensite forense-ai
    sudo a2dissite 000-default
    sudo systemctl reload apache2
    

    Fase 5 — Servicio web: formulario de subida + análisis

    15) Instala herramientas para extraer texto de PDF

    sudo apt -y install poppler-utils
    

    (trae pdftotext)

    16) Crea el formulario web index.php

    sudo nano /var/www/forense-ai/index.php
    

    Contenido:

    <?php
    $maxSize = 8 * 1024 * 1024; // 8 MB
    $allowed = ['txt','log','pdf'];
    
    function safe_name($name) {
      $name = preg_replace('/[^a-zA-Z0-9._-]/', '_', $name);
      return $name;
    }
    
    ?>
    <!doctype html>
    <html>
    <head>
      <meta charset="utf-8">
      <title>Forense-AI</title>
      <style>
        body { font-family: Arial, sans-serif; margin: 40px; max-width: 900px; }
        .box { padding: 16px; border: 1px solid #ccc; border-radius: 8px; }
        input, textarea, select { width: 100%; padding: 8px; margin-top: 8px; }
        button { padding: 10px 14px; margin-top: 12px; }
        .small { color: #555; font-size: 0.9em; }
      </style>
    </head>
    <body>
      <h1>Forense-AI — Analizador de evidencias</h1>
      <div class="box">
        <form action="process.php" method="post" enctype="multipart/form-data">
          <label>Evidencia (TXT/LOG/PDF, máx 8 MB)</label>
          <input type="file" name="evidence" required>
    
          <label>Tipo de análisis</label>
          <select name="mode">
            <option value="audit">Auditoría (hallazgos y riesgos)</option>
            <option value="forensic">Forense (línea temporal y eventos)</option>
            <option value="summary">Resumen ejecutivo</option>
          </select>
    
          <label>Contexto (opcional)</label>
          <textarea name="context" rows="4" placeholder="Ej: Esto es un auth.log de un servidor SSH expuesto a Internet..."></textarea>
    
          <button type="submit">Subir y analizar</button>
          <p class="small">El análisis se realiza localmente en el servidor (Ollama). No se envía nada a Internet.</p>
        </form>
      </div>
    </body>
    </html>
    

    17) Crea el script de procesamiento process.php

    sudo nano /var/www/forense-ai/process.php
    

    Contenido:

    <?php
    $uploadDir = __DIR__ . "/uploads/";
    $resultDir = __DIR__ . "/results/";
    $logDir    = __DIR__ . "/logs/";
    
    $maxSize = 8 * 1024 * 1024;
    $allowed = ['txt','log','pdf'];
    
    function safe_name($name) {
      return preg_replace('/[^a-zA-Z0-9._-]/', '_', $name);
    }
    
    function ext($name) {
      $p = pathinfo($name);
      return strtolower($p['extension'] ?? '');
    }
    
    function run_cmd($cmd) {
      $output = [];
      $ret = 0;
      exec($cmd . " 2>&1", $output, $ret);
      return [$ret, implode("\n", $output)];
    }
    
    if (!isset($_FILES['evidence'])) {
      http_response_code(400);
      exit("No file uploaded");
    }
    
    $f = $_FILES['evidence'];
    if ($f['error'] !== UPLOAD_ERR_OK) {
      http_response_code(400);
      exit("Upload error");
    }
    
    if ($f['size'] > $maxSize) {
      http_response_code(400);
      exit("File too large");
    }
    
    $original = $f['name'];
    $extension = ext($original);
    
    if (!in_array($extension, $allowed, true)) {
      http_response_code(400);
      exit("Invalid extension");
    }
    
    $mode = $_POST['mode'] ?? 'audit';
    $context = trim($_POST['context'] ?? '');
    
    $base = date("Ymd_His") . "_" . safe_name($original);
    $dest = $uploadDir . $base;
    
    if (!move_uploaded_file($f['tmp_name'], $dest)) {
      http_response_code(500);
      exit("Failed to save upload");
    }
    
    // Extraer texto
    $textFile = $dest . ".txt";
    if ($extension === 'pdf') {
      // pdftotext
      [$ret, $out] = run_cmd("pdftotext " . escapeshellarg($dest) . " " . escapeshellarg($textFile));
      if ($ret !== 0) {
        http_response_code(500);
        exit("pdftotext failed:\n" . htmlspecialchars($out));
      }
    } else {
      // Copiar tal cual
      copy($dest, $textFile);
    }
    
    // Leer texto (limitamos por tamaño para no petar memoria)
    $raw = file_get_contents($textFile);
    if ($raw === false) {
      http_response_code(500);
      exit("Cannot read extracted text");
    }
    $raw = substr($raw, 0, 50000); // 50k chars (suficiente para práctica)
    
    $promptBase = "Eres un analista de ciberseguridad. Responde en español con formato claro.\n";
    if ($mode === 'audit') {
      $task = "Analiza la evidencia como auditoría. Devuelve: 1) Resumen, 2) Hallazgos (con evidencias), 3) Riesgos, 4) Recomendaciones priorizadas.";
    } elseif ($mode === 'forensic') {
      $task = "Analiza la evidencia con enfoque forense. Devuelve: 1) Resumen, 2) Línea temporal aproximada, 3) Eventos relevantes, 4) Hipótesis, 5) Próximos pasos.";
    } else {
      $task = "Resume la evidencia para un responsable no técnico. Devuelve un resumen ejecutivo y 5 puntos clave.";
    }
    
    $contextPart = $context ? "\nContexto aportado por el usuario:\n" . $context . "\n" : "";
    
    $prompt = $promptBase . $task . $contextPart . "\nEVIDENCIA (texto):\n" . $raw . "\n";
    
    // Llamar a Ollama
    $model = "phi3";
    $cmd = "ollama run " . escapeshellarg($model) . " " . escapeshellarg($prompt);
    
    [$ret, $analysis] = run_cmd($cmd);
    if ($ret !== 0) {
      http_response_code(500);
      exit("Ollama failed:\n" . htmlspecialchars($analysis));
    }
    
    $reportName = basename($dest) . "_informe.md";
    $reportPath = $resultDir . $reportName;
    
    $report = "# Informe Forense-AI\n\n"
            . "- Archivo: **" . htmlspecialchars($original) . "**\n"
            . "- Fecha: **" . date("Y-m-d H:i:s") . "**\n"
            . "- Modo: **" . htmlspecialchars($mode) . "**\n\n"
            . "---\n\n"
            . $analysis . "\n";
    
    file_put_contents($reportPath, $report);
    
    // Log básico
    file_put_contents($logDir . "activity.log",
      date("c") . " file=" . $base . " mode=" . $mode . " ip=" . ($_SERVER['REMOTE_ADDR'] ?? 'unknown') . "\n",
      FILE_APPEND
    );
    
    header("Location: result.php?f=" . urlencode($reportName));
    

    18) Crea la página de resultados result.php

    sudo nano /var/www/forense-ai/result.php
    

    Contenido:

    <?php
    $resultDir = __DIR__ . "/results/";
    $f = $_GET['f'] ?? '';
    $f = basename($f); // evita traversal
    $path = $resultDir . $f;
    
    if (!$f || !file_exists($path)) {
      http_response_code(404);
      exit("Report not found");
    }
    
    $txt = file_get_contents($path);
    ?>
    <!doctype html>
    <html>
    <head>
      <meta charset="utf-8">
      <title>Resultado — Forense-AI</title>
      <style>
        body { font-family: Arial, sans-serif; margin: 40px; max-width: 900px; }
        pre { white-space: pre-wrap; border: 1px solid #ccc; padding: 16px; border-radius: 8px; }
        a { display:inline-block; margin-top: 12px; }
      </style>
    </head>
    <body>
      <h1>Informe generado</h1>
      <a href="download.php?f=<?php echo urlencode($f); ?>">Descargar informe</a>
      <pre><?php echo htmlspecialchars($txt); ?></pre>
      <a href="index.php">⬅ Volver</a>
    </body>
    </html>
    

    19) Crea el descargador download.php

    sudo nano /var/www/forense-ai/download.php
    

    Contenido:

    <?php
    $resultDir = __DIR__ . "/results/";
    $f = $_GET['f'] ?? '';
    $f = basename($f);
    $path = $resultDir . $f;
    
    if (!$f || !file_exists($path)) {
      http_response_code(404);
      exit("Not found");
    }
    
    header('Content-Type: text/markdown; charset=utf-8');
    header('Content-Disposition: attachment; filename="' . $f . '"');
    readfile($path);
    

    Fase 6 — Permisos y seguridad mínima del servicio

    20) Permisos finales (muy importante)

    sudo chown -R www-data:www-data /var/www/forense-ai
    sudo find /var/www/forense-ai -type d -exec chmod 750 {} \;
    sudo find /var/www/forense-ai -type f -exec chmod 640 {} \;
    sudo systemctl reload apache2
    

    21) Importante: Ollama solo local

    Comprueba que Ollama no está expuesto:

    • El servicio web llama a ollama run localmente.
    • No hace falta abrir puertos de Ollama.

    Fase 7 — Pruebas obligatorias (para entregar)

    22) Caso de prueba A (Auditoría)

    1. Sube un auth.log (o un ejemplo creado por vosotros)
    2. Modo: Auditoría
    3. Debe devolver hallazgos y recomendaciones

    23) Caso de prueba B (Forense)

    1. Sube una salida de nmap guardada como TXT
    2. Modo: Forense
    3. Debe generar hipótesis y próximos pasos

    24) Caso de prueba C (PDF)

    1. Sube un PDF técnico (manual, informe)
    2. Modo: Resumen ejecutivo
    3. Debe resumir y extraer puntos clave
  • 1 – KALI LINUX – HERRAMIENTAS Y METODOLOGÍA DE SEGURIDAD OFENSIVA

    1 – KALI LINUX – HERRAMIENTAS Y METODOLOGÍA DE SEGURIDAD OFENSIVA

    Qué es Kali Linux

    Kali Linux es una distribución GNU/Linux especializada en seguridad informática. Está diseñada para auditoría, pentesting, análisis forense y formación en ciberseguridad. Y aquí viene lo importante: es tan potente como malentendida.


    Kali es un laboratorio portátil. Un entorno pensado para aprender, probar y verificar la seguridad de sistemas, redes y aplicaciones.

    • Un sistema basado en Debian, estable y bien documentado.
    • Un conjunto curado de herramientas profesionales: escaneo, explotación, análisis de tráfico, ingeniería inversa, OSINT, forense, wireless…
    • Un estándar educativo y profesional en ciberseguridad (universidades, certificaciones, laboratorios, CTFs).
    • Una plataforma para pensar como atacante, con permiso y con método, para poder defender mejor.

    Kali no “hace magia”. Cada herramienta exige entender redes, sistemas, protocolos y lógica. Si no sabes qué es TCP, Kali no te lo va a enseñar a golpes de teclado.


    Qué no es Kali Linux

    Kali no es:

    • ❌ Un sistema para usar como Linux de diario (navegar, ofimática, jugar).
    • ❌ Un botón rojo para “hackear WiFi en 3 minutos”.
    • ❌ Una forma de saltarte la ley sin consecuencias.
    • ❌ Un atajo para no aprender fundamentos.
    • ❌ Un sistema “más potente” que Ubuntu para tareas normales.

    Si alguien instala Kali sin saber Linux, redes o seguridad… lo más probable es que solo consiga romper cosas propias y frustrarse.

    Kali Linux no te convierte en hacker.
    Kali Linux amplifica lo que ya sabes.

    Un experto con Ubuntu es peligroso (en el buen sentido).
    Un novato con Kali solo tiene un martillo enorme… y dedos cerca.


    Nunca es “primer Linux”. Siempre como herramienta especializada

    La historia BackTrack → Kali Linux es, en el fondo, la historia de cómo el “hacking artesanal” se convirtió en disciplina profesional. Vamos por partes, con contexto y sin mitología barata.


    BackTrack: el origen (2006–2013)

    BackTrack nació cuando la seguridad informática todavía tenía aroma a underground técnico.

    No era una distro “bonita”. Era un arsenal.

    BackTrack surge de la fusión de varios proyectos previos (WHAX, Auditor, etc.) y se construye sobre una idea clara:
    tener todas las herramientas de pentesting listas para usar, en un sistema arrancable.

    Características clave de BackTrack:

    • Basado primero en Slackware, luego en Ubuntu
    • Uso intensivo en Live CD / Live USB
    • Pensado para pentesters, investigadores y formadores
    • Muy popular en:
      • Auditorías
      • CTFs
      • Formación autodidacta
      • Escenarios “de campo”

    Pero BackTrack tenía problemas estructurales:

    • Mantenimiento complejo
    • Sistema poco homogéneo
    • Instalaciones frágiles
    • Difícil de escalar a entornos profesionales
    • Enfoque más “herramientas juntas” que “sistema bien diseñado”

    Era brillante… pero caótico.


    El punto de inflexión: profesionalización

    A medida que la ciberseguridad entra en:

    • empresas
    • universidades
    • certificaciones
    • auditorías reguladas

    BackTrack empieza a quedarse corto.

    No por las herramientas, sino por el modelo.

    Offensive Security (la empresa detrás del proyecto) se hace una pregunta clave:

    ¿Y si esto no fuera solo una distro con herramientas, sino una plataforma profesional mantenible?

    La respuesta fue romper con el pasado.


    Kali Linux: el renacimiento

    En 2013 BackTrack se retira oficialmente y nace Kali Linux.

    No es una versión nueva.
    Es un rediseño completo desde cero.

    Cambios fundamentales:

    • Base Debian pura (estabilidad, repositorios, mantenimiento)
    • Sistema modular y coherente
    • Instalación real en disco (no solo live)
    • Metodología clara: cada herramienta tiene un propósito
    • Integración con certificaciones como OSCP
    • Pensado para:
      • VMs
      • Cloud
      • ARM (Raspberry Pi)
      • Contenedores
      • Laboratorios educativos

    Kali ya no es “un CD lleno de cosas”.
    Es un sistema operativo de trabajo.


    Cambio de filosofía

    BackTrack decía:

    “Aquí tienes herramientas. Averigua tú el resto.”

    Kali dice:

    “Aquí tienes herramientas clasificadas, documentadas y mantenidas, ahora aprende el método.”

    Por eso Kali:

    • Clasifica herramientas por fases del ataque
    • Elimina herramientas obsoletas sin piedad
    • Prioriza reproducibilidad y legalidad
    • Se alinea con estándares profesionales

    Por qué BackTrack murió (y debía morir)

    BackTrack no fracasó.
    Cumplió su misión.

    Fue el puente entre:

    • el hacker autodidacta
    • y el profesional de seguridad

    Kali es lo que viene después:

    • más serio
    • más estable
    • más ético
    • más usable en docencia

    Hoy, enseñar BackTrack tendría el mismo sentido que enseñar MS-DOS para administrar servidores modernos: interesante como historia, inútil como práctica real.


    Resumen mental rápido

    BackTrack fue:

    • rebelde
    • potente
    • desordenado
    • fundacional

    Kali es:

    • profesional
    • mantenido
    • estructurado
    • educativo

    Uno abrió la puerta.
    El otro construyó la casa.

    Y esa evolución explica muy bien cómo maduró toda la ciberseguridad como disciplina.

    Filosofía de Offensive Security

    La filosofía de Offensive Security no va de “atacar por atacar”. Va de una idea incómoda, pero profundamente honesta:

    Si algo puede romperse, alguien lo romperá. Mejor que seas tú, con permiso y con método.

    Eso es offensive security. No una actitud gamberra, sino una postura intelectual frente a la seguridad.


    Pensar como atacante para defender de verdad

    La seguridad defensiva clásica tiende a decir:
    “he configurado esto bien, debería ser seguro”.

    La seguridad ofensiva responde:
    debería no es una garantía”.

    Offensive Security parte de una premisa brutalmente simple:
    la única forma fiable de comprobar la seguridad de un sistema es intentar comprometerlo.


    El enemigo no es el hacker, es la ilusión de seguridad

    En esta filosofía, el problema no son los atacantes.
    El problema es el autoengaño técnico:

    • “Esto no lo va a atacar nadie”
    • “Nadie sabrá que está aquí”
    • “Es solo una app pequeña”
    • “Tenemos firewall, estamos cubiertos”

    Offensive security desmonta esas frases con hechos, no con opiniones.


    Herramientas ≠ filosofía

    Un matiz clave que muchos no pillan:

    • Usar Metasploit no te hace offensive security.
    • Usar Kali no te hace offensive security.
    • Saber exploits no te hace offensive security.

    La filosofía está en el proceso mental:

    1. Enumerar sin asumir nada
    2. Buscar superficies de ataque reales
    3. Encadenar fallos pequeños
    4. Pensar en impacto, no solo en “entré”
    5. Documentar cómo y por qué ocurrió

    El ataque es el medio.
    El objetivo es el conocimiento verificable.


    Metodología antes que ego

    Offensive Security es, paradójicamente, anti-ego.

    No va de:

    • “mira lo listo que soy”
    • “he entrado en X”
    • “tengo 0days”

    Va de:

    • ¿qué falló exactamente?
    • ¿cómo se reproduce?
    • ¿cómo se mitiga?
    • ¿qué aprendemos de esto?

    Por eso OffSec insiste tanto en:

    • laboratorios
    • informes
    • reproducibilidad
    • entender lo que haces, no copiar comandos

    La filosofía offensive no glorifica el delito.
    Lo separa claramente.

    Hay una línea muy clara:

    • con permiso → auditoría
    • sin permiso → delito

    La diferencia no está en la técnica. Está en el contexto y la intención.



    En el fondo, es una postura filosófica

    Offensive Security dice algo muy humano:

    La confianza ciega es peligrosa.
    El escepticismo informado es saludable.

    No destruye sistemas por placer. Los desmonta para entenderlos.

    La línea roja: el permiso

    Todo se decide con una sola pregunta:

    ¿Tienes autorización explícita para hacer lo que estás haciendo?

    • Sí → auditoría, práctica, formación.
    • No → acceso ilícito, daños informáticos, responsabilidades penales.

    No importa:

    • que el sistema sea vulnerable
    • que “solo estuvieras mirando”
    • que no hayas borrado nada
    • que fuera “por aprender”

    La intención técnica no te protege legalmente.


    En España —y de forma muy similar en la UE— entran en juego leyes como:

    • acceso no autorizado a sistemas
    • interceptación de comunicaciones
    • alteración o daño de datos
    • uso indebido de credenciales
    • suplantación

    Muchas acciones típicas de laboratorio (escaneos, fuerza bruta, sniffing) son ilegales fuera de un entorno autorizado, aunque no “rompas” nada.

    El argumento “no causé daño” no suele salvarte. El acceso ya es el daño.


    Ética profesional ≠ “todo lo que la ley permita”

    La ética va un paso más allá de la ley.

    Hay cosas que pueden ser legales… y aun así poco éticas.

    Ejemplos clásicos:

    • escanear infraestructuras sin avisar “a ver qué sale”
    • probar exploits en sistemas de terceros aunque “solo sea lectura”
    • usar datos reales en informes educativos sin anonimizar
    • humillar a un cliente demostrando fallos sin contexto

    La ética profesional exige:

    • mínimo impacto
    • necesidad justificada
    • proporcionalidad
    • responsabilidad sobre los datos

    No todo lo técnicamente posible es profesionalmente aceptable.


    El principio del entorno controlado

    Por eso en formación se insiste tanto en:

    • máquinas virtuales
    • laboratorios aislados
    • plataformas vulnerables a propósito
    • redes sin salida a Internet
    • contratos y documentos de autorización

    No es paranoia.
    Es protección legal y pedagógica.

    Un buen profesional nunca “practica” en producción ajena.


    Documentar también es una obligación ética

    Offensive security no termina cuando entras.

    Termina cuando:

    • explicas qué hiciste
    • explicas por qué fue posible
    • explicas cómo corregirlo
    • evalúas impacto real
    • propones medidas de mitigación

    Callarte un fallo crítico para “parecer más hacker” es una falta ética.
    Exagerarlo para impresionar también.


    El error más común

    Creer que:

    • la herramienta es ilegal
    • o que usarla “en local” siempre es seguro

    La realidad:

    • las herramientas no son ilegales
    • el uso sí puede serlo

    Nmap, Wireshark, Metasploit o Burp son herramientas legítimas.
    Usarlas fuera de contexto es lo que crea problemas.


    La regla de oro

    Antes de ejecutar un comando ofensivo, un profesional se pregunta:

    1. ¿Tengo permiso escrito?
    2. ¿Es el entorno adecuado?
    3. ¿Es necesario hacerlo?
    4. ¿Puedo justificarlo en un informe?
    5. ¿Estoy preparado para asumir consecuencias si algo falla?

    Si alguna respuesta incomoda… se para.

    La ciberseguridad ofensiva no va de cruzar límites,
    va de entenderlos y respetarlos.

    El conocimiento da poder.
    La ética decide si ese poder construye o destruye

    Diferencias: Kali vs Parrot vs BlackArch vs Ubuntu “hardened”

    No son rivales directos. Son respuestas distintas al mismo problema.

    Kali Linux

    Kali es ofensiva pura y explícita.
    Está pensada para atacar con método, no para convivir.

    • Enfoque: pentesting, auditoría, formación
    • Filosofía: offensive security
    • Herramientas: muchas, seleccionadas, clasificadas por fase
    • Público: estudiantes, pentesters, auditores
    • Uso típico: laboratorio, VM, live, cloud

    Kali no intenta ser discreta. Es un maletín abierto lleno de ganzúas… con permiso.


    Parrot Security OS

    Parrot es más híbrida y más política en el buen sentido.

    • Enfoque: seguridad + privacidad + desarrollo
    • Filosofía: anonimato, hardening, uso diario posible
    • Herramientas: menos que Kali, pero bien integradas
    • Público: seguridad, pero también usuarios avanzados
    • Uso típico: sistema principal o VM

    Parrot intenta convivir con el día a día. Kali no.


    BlackArch

    BlackArch es radical.

    • Enfoque: ofensivo extremo
    • Filosofía: “si existe una herramienta, la incluimos”
    • Herramientas: miles
    • Público: usuarios muy avanzados
    • Uso típico: entornos muy específicos

    BlackArch no te enseña. Te exige saber.
    Es potencia sin pedagogía.


    Ubuntu hardened

    Aquí cambia completamente el eje.

    • Enfoque: defensa
    • Filosofía: reducir superficie de ataque
    • Herramientas ofensivas: ninguna por defecto
    • Público: administradores, producción
    • Uso típico: servidores, entornos reales

    No sirve para atacar. Sirve para no ser atacado.


    Cada uno juega a otra cosa, aunque compartan campo.


    Modos de uso de Kali Linux

    Aquí está la parte crítica para docencia y práctica profesional.


    1. Máquina virtual (VM)

    Este es el modo rey en formación.

    Qué es:

    • Kali ejecutándose dentro de VirtualBox, VMware, Proxmox, etc.

    Ventajas:

    • Aislamiento total
    • Fácil de romper y rehacer
    • Snapshots
    • Ideal para laboratorios

    Inconvenientes:

    • Rendimiento
    • Algunas limitaciones hardware (WiFi, GPU)

    Uso típico:

    • clases
    • prácticas
    • CTFs
    • pruebas controladas

    Si alguien empieza con Kali, esto es lo correcto.


    2. Live USB

    Kali “arranca y desaparece”.

    Qué es:

    • Kali ejecutándose desde USB sin tocar el disco

    Ventajas:

    • No deja rastro (en modo live)
    • Ideal para auditorías puntuales
    • Muy portable

    Inconvenientes:

    • Cambios no persistentes (salvo configuración especial)
    • Más lento
    • No pensado para trabajar a largo plazo

    Uso típico:

    • auditorías de campo
    • demostraciones
    • emergencias

    Este modo es heredero directo del espíritu BackTrack.


    3. Instalación bare metal

    Aquí ya hablamos de uso serio y consciente.

    Qué es:

    • Kali instalado como sistema principal en el equipo

    Ventajas:

    • Rendimiento completo
    • Acceso total al hardware
    • Entorno de trabajo permanente

    Inconvenientes:

    • No es cómodo para uso diario
    • Riesgo si no sabes lo que haces
    • No tiene sentido para la mayoría

    Uso típico:

    • profesionales dedicados
    • equipos exclusivos de auditoría

    Instalar Kali como “mi Linux normal” suele ser una mala decisión… hasta que deja de serlo por razones muy concretas.


    4. Kali en la nube / contenedor (conceptual)

    Aquí entramos en la Kali moderna.

    Kali en la nube

    • Kali desplegado en VPS, cloud o laboratorio remoto
    • Ideal para OSINT, análisis, escaneos desde IP externa
    • Muy usado en auditorías reales

    No dependes de tu portátil.
    Dependes de infraestructura reproducible.

    Kali en contenedores

    • Herramientas concretas en Docker
    • No todo el sistema, solo lo necesario
    • Automatización, CI/CD, pruebas repetibles

    Esto refleja una idea clave:

    Kali ya no es solo un sistema, es un ecosistema de herramientas.


  • 2 – KALI LINUX: Metodología de un ataque

    2 – KALI LINUX: Metodología de un ataque

    Ciclo clásico de un test de penetración

    Este ciclo no es una receta mágica ni siempre lineal. Es un modelo mental de trabajo. En la práctica se avanza, se retrocede y se repite. Pensar que es lineal es el primer error del principiante.


    1. Reconocimiento

    Aquí no se ataca. Aquí se observa.

    El objetivo es responder a una pregunta básica pero poderosa:

    ¿Qué existe ahí fuera que pueda ser relevante?

    Se recopila información del objetivo sin interactuar directamente o con la mínima huella posible.

    Incluye:

    • Dominios, subdominios, IPs
    • Rangos de red
    • Tecnologías usadas
    • Información pública de la organización
    • Usuarios, correos, patrones

    Es como mirar un edificio desde la calle: cuántas puertas tiene, cuántas ventanas, si hay cámaras, si alguien entra y sale.

    Error típico del alumno: querer usar exploits aquí.
    Lección clave: sin información, cualquier ataque es ruido.


    2. Enumeración

    Ahora sí se empieza a tocar el sistema… con cuidado.

    La enumeración responde a otra pregunta crítica:

    ¿Qué servicios concretos están activos y cómo se comportan?

    Aquí se baja al detalle:

    • Puertos abiertos
    • Servicios y versiones
    • Rutas web
    • Usuarios válidos
    • Recursos compartidos
    • Respuestas del sistema

    La diferencia con el reconocimiento es la profundidad.
    Si el reconocimiento es el mapa, la enumeración es poner nombres a las calles.

    Error típico: escanear sin entender los resultados.
    Lección clave: un puerto abierto no es una vulnerabilidad; es una pista.


    3. Explotación

    Aquí ocurre lo que todos esperan… pero solo debería llegar cuando hay base suficiente.

    La pregunta ahora es directa:

    ¿Puedo aprovechar esto para obtener acceso?

    Explotar no significa “romperlo todo”, significa:

    • Ejecutar código
    • Saltarse autenticaciones
    • Obtener una shell
    • Acceder a información sensible

    Puede ser:

    • Automático (frameworks)
    • Manual (mucho más interesante didácticamente)

    Error típico: lanzar exploits al azar.
    Lección clave: explotar es confirmar una hipótesis, no probar suerte.


    4. Post-explotación

    Este es el bloque que diferencia a un curioso de un profesional.

    Una vez dentro, la pregunta cambia:

    ¿Hasta dónde puedo llegar y qué impacto real tiene esto?

    Aquí se evalúa:

    • Qué permisos se tienen
    • Si se puede escalar privilegios
    • Qué otros sistemas son accesibles
    • Qué datos pueden extraerse
    • Qué persistencia sería posible

    No se trata de “hacer daño”, sino de medir consecuencias.

    Error típico: quedarse satisfecho con “ya entré”.
    Lección clave: una intrusión sin impacto medido no sirve para nada.


    5. Reporte

    El paso más infravalorado… y el más importante.

    El objetivo no es impresionar, es comunicar.

    Un buen reporte responde a:

    • Qué se hizo
    • Cómo se hizo
    • Qué se consiguió
    • Qué riesgo real existe
    • Cómo se puede mitigar

    Aquí el lenguaje cambia:

    • Técnico para técnicos
    • Claro y ejecutivo para responsables

    Error típico: pensar que esto es “relleno”.
    Lección clave: si no se puede explicar, no existe.


    ¿Qué es MITRE ATT&CK?

    La caja MITRE ATT&CK es, básicamente, el mapa oficial del “cómo” atacan los adversarios. No es una herramienta, no es un exploit, y no sirve para “hackear” directamente. Sirve para pensar con rigor.

    Si el ciclo clásico te dice en qué fase estás, MITRE ATT&CK te dice qué tácticas y técnicas existen en cada fase. Ciencia del mal comportamiento, documentada con obsesión académica.


    MITRE ATT&CK (Adversarial Tactics, Techniques and Common Knowledge) es una base de conocimiento que recoge:

    • Técnicas reales usadas por atacantes
    • Observadas en incidentes reales
    • Clasificadas y normalizadas
    • Mantenida por MITRE (organización sin ánimo de lucro)

    No habla de herramientas concretas. Habla de comportamientos.


    La “caja” ATT&CK

    Se suele representar como una matriz (una caja grande):

    • Columnas → Tácticas (el por qué)
    • Filas → Técnicas (el cómo)

    Cada celda responde a:

    Para conseguir este objetivo, ¿qué formas conocidas existen?


    Tácticas principales (Enterprise)

    Las tácticas son intenciones del atacante. No son pasos estrictos, pero sí un flujo lógico.

    • Reconnaissance – Recopilar información
    • Resource Development – Preparar infraestructura
    • Initial Access – Primer acceso al sistema
    • Execution – Ejecutar código
    • Persistence – Mantener acceso
    • Privilege Escalation – Subir permisos
    • Defense Evasion – Evitar detección
    • Credential Access – Obtener credenciales
    • Discovery – Conocer el entorno interno
    • Lateral Movement – Moverse por la red
    • Collection – Recopilar datos
    • Command and Control – Comunicación con el atacante
    • Exfiltration – Sacar información
    • Impact – Daño o efecto final

    Observa algo interesante: no es lineal. Es un grafo mental.


    Técnicas y sub-técnicas

    Cada táctica contiene técnicas numeradas (por ejemplo T1059).

    Ejemplo:

    • Táctica: Execution
    • Técnica: Command and Scripting Interpreter
    • Sub-técnica: PowerShell, Bash, Python

    Esto permite:

    • Hablar con precisión
    • Comparar ataques distintos
    • Decir “qué pasó” sin folklore

    Relación con el ciclo clásico

    Aquí ocurre la magia didáctica.

    Ciclo clásicoMITRE ATT&CK
    ReconocimientoReconnaissance
    EnumeraciónDiscovery
    ExplotaciónInitial Access + Execution
    Post-explotaciónPersistence, Privilege Escalation, Lateral Movement, Collection
    ReporteDocumentar técnicas ATT&CK

    El ciclo clásico es pedagógico.
    MITRE ATT&CK es analítico y profesional.


    Evita frases como:

    • “Me hackearon con un virus”
    • “Usaron Metasploit”
    • “Fue un ataque raro”

    Y las sustituye por:

    • “T1059 – ejecución mediante intérprete de comandos”
    • “T1003 – dumping de credenciales”
    • “T1021 – movimiento lateral vía SMB”

    Eso es lenguaje común entre Red Team, Blue Team y SOC.


    Red Team vs Blue Team

    MITRE ATT&CK es el campo de batalla compartido:

    • Red Team: qué técnicas usar
    • Blue Team: qué técnicas detectar
    • Purple Team: alinear ambos mundos

    Kali vive cómodo en el Red Team, pero ATT&CK es neutral.

    KALI LINUX: CLASIFICACIÓN DE HERRAMIENTAS

    A partir de aquí, Kali se entiende por categorías funcionales, no por listas caóticas.


    Reconocimiento pasivo (OSINT)

    Sin tocar el objetivo directamente.

    Herramientas clave:

    • whois
    • theHarvester
    • Maltego
    • Amass (modo pasivo)
    • dnsenum
    • subfinder
    • Google dorks (conceptual)

    Objetivo: aprender a sacar información sin levantar sospechas.


    Reconocimiento activo y escaneo

    Aquí ya “tocamos” el sistema.

    Herramientas clave:

    • nmap (bloque enorme, merece varias clases)
      • Descubrimiento
      • Puertos
      • Servicios
      • Scripts NSE
    • masscan
    • netdiscover
    • arp-scan

    Objetivo: mapear superficie de ataque.


    Enumeración de servicios

    Saber qué versión, qué fallo y qué puerta está abierta.

    Por servicios:

    • HTTP/HTTPS:
      • whatweb
      • nikto
      • dirb, dirbuster, gobuster
    • SMB:
      • enum4linux
      • smbclient
    • FTP:
      • ftp, nmap ftp-*
    • DNS:
      • dig
      • dnsrecon

    Objetivo: transformar “puertos abiertos” en vulnerabilidades reales.


    Análisis de vulnerabilidades

    Antes de explotar, se evalúa.

    Herramientas:

    • nikto (web)
    • searchsploit
    • Introducción a CVE, CVSS
    • Relación versión → exploit

    Objetivo: no disparar a ciegas.


    Explotación

    Aquí empieza lo serio

    Herramientas:

    • Metasploit Framework
      • exploits
      • payloads
      • sesiones
    • Explotación manual (conceptual)
    • Uso responsable y controlado

    Objetivo: entender cómo se compromete un sistema, no solo ejecutar exploits.


    Post-explotación

    Una vez dentro… ¿ahora qué?

    • Enumeración interna
    • Escalada de privilegios
    • Persistencia (conceptual)
    • Exfiltración (conceptual)
    • Limpieza de rastros (ética y teoría)

    Herramientas:

    • Módulos de Metasploit
    • Scripts básicos

    Objetivo: comprender el impacto real de una intrusión.


    Ataques a credenciales

    Uno de los bloques favoritos de los alumnos.

    Herramientas:

    • hydra
    • john
    • hashcat
    • Diccionarios
    • Tipos de hash

    Objetivo: demostrar por qué las contraseñas débiles son el eslabón roto.


    Redes inalámbricas

    Siempre motiva mucho.

    Herramientas:

    • aircrack-ng
    • airodump-ng
    • aireplay-ng
    • Conceptos:
      • WPA/WPA2/WPA3
      • Handshake
      • Diccionarios

    Objetivo: entender por qué el WiFi mal configurado es un desastre.


    Sniffing y análisis de tráfico

    Ver lo invisible.

    Herramientas:

    • tcpdump
    • wireshark
    • Filtros básicos
    • Captura de credenciales en claro

    Objetivo: aprender a leer la red como si fuera texto.


    13. Ingeniería social (teórica)

    Con cuidado y ética.

    • Conceptos
    • Casos reales
    • Phishing (solo teórico o laboratorio controlado)

    Objetivo: entender que el humano es el vector más vulnerable.


    Automatización y scripting en Kali

    Pensar como profesional.

    • Bash básico para pentesting
    • Python para automatizar tareas
    • Uso de herramientas encadenadas

    Objetivo: dejar de ser “usuario de herramientas” y pasar a operador.


    Documentación y reporting

    El ataque no vale nada sin informe.

    • Evidencias
    • Capturas
    • Explicación técnica
    • Recomendaciones de mitigación
    • Informe ejecutivo vs técnico

    Objetivo: cerrar el ciclo profesional.


  • Herramientas IA en la Web (I)

    🖼️ IA de IMAGEN (generación / edición)

    HerramientaEnlaceUso principalCoste
    Rendernethttps://rendernet.ai/Imágenes y vídeo con personajes consistentesFreemium / Suscripción
    Krea AIhttps://www.krea.ai/homeImagen creativa en tiempo real, estilosFreemium / Suscripción
    Grok Image / Imaginehttps://grok.com/imagineGeneración de imágenes por promptFreemium (limitado)
    Adobe Fireflyhttps://firefly.adobe.com/upload/inpaintEdición IA (inpaint, estilos)Freemium / Suscripción Adobe
    Reve / Reve AIhttps://app.reve.com/Generación artística de imágenesFreemium
    Lovart AIhttps://www.lovart.ai/Ilustración, arte conceptualFreemium / Suscripción
    PixVersehttps://app.pixverse.ai/Imagen + vídeo creativoFreemium / Suscripción

    🎥 IA de VÍDEO (texto → vídeo / imagen → vídeo)

    HerramientaEnlaceUso principalCoste
    LivePortraithttps://liveportrait.github.io/Animar retratos (imagen → vídeo)Gratuito / Open Source
    HuggingFace Demo (KwaiVGI)https://huggingface.co/spaces/KwaiVGIDemo online de LivePortraitGratuito
    Wanhttps://wan.video/Generación de vídeo con IAFreemium / Suscripción
    Wan 2.2https://wan.video/Versión avanzada del modelo WanFreemium / Suscripción
    MindVideohttps://www.mindvideo.ai/es/Texto → vídeoFreemium / Suscripción
    CapCut AI Videohttps://www.capcut.com/my-editEdición y vídeo con IAFreemium / Pro
    Symphony (TikTok)https://ads.tiktok.com/creativeVídeos publicitarios automáticosGratuito
    Veo 3.1 (Flow)https://labs.google/fx/es/tools/flowVídeo generativo experimental (Google)Acceso limitado / Experimental
    Hedrahttps://www.hedra.com/Creación audiovisual con IAFreemium / Suscripción

    🔊 IA de VOZ / AUDIO

    HerramientaEnlaceUso principalCoste
    ElevenLabshttps://try.elevenlabs.io/shmdm7umt6ggTexto → voz realista, clonaciónFreemium / Suscripción

    💬 IA de CHAT / LLMs

    HerramientaEnlaceUso principalCoste
    Meta AIhttps://www.meta.ai/Asistente IA generalGratuito
    Qwenhttps://qwen.ai/LLM general (Alibaba)Gratuito
    Chat Qwen (mini campus)https://chat.qwen.ai/s/deploy/Chat personalizado desplegadoGratuito
    Erniehttps://ernie.baidu.com/LLM de BaiduGratuito
    Chat Zhttps://chat.z.ai/Chat IA generalGratuito
    ChatGLMhttps://chatglm.cnLLM técnicoGratuito
    LMArenahttps://lmarena.ai/Comparador de modelos LLMGratuito

    🧠 PROMPTS / EXPERIMENTOS IA

    HerramientaEnlaceUso principalCoste
    Generador de prompts (Gemini)https://gemini.google.com/gem/Creación de prompts optimizadosGratuito
    Pomelli (Google Labs)https://labs.google.com/pomelli/about/Experimentos creativos IAGratuito / Experimental

    🤖 AGENTES / AUTOMATIZACIÓN

    HerramientaEnlaceUso principalCoste
    RoboNeohttps://www.roboneo.com/Agentes IA y automatizaciónFreemium / Suscripción

    🔐 PRIVACIDAD / VPN (extra, no IA)

    HerramientaEnlaceUso principalCoste
    NordVPNhttps://nordvpn.com/alejaviVPN profesionalSuscripción
    Hide.me (extensión Chrome)Chrome Web StoreVPN básica navegadorGratuita

    🧩 RESUMEN

    • 🟢 Gratis / Open: LivePortrait, HuggingFace, Meta AI, Qwen, ChatGLM, LMArena
    • 🟡 Freemium : ElevenLabs, Krea, CapCut, Wan, PixVerse
    • 🔵 Profesional / Pro: Rendernet, Adobe Firefly, NordVPN

  • TGPT desde la terminal (Windows · Linux · macOS)

    TGPT desde la terminal (Windows · Linux · macOS)

    Manual de instalación y uso de tgpt

    1. ¿Qué es tgpt y para qué sirve?

    tgpt es un cliente no oficial que permite interactuar con modelos tipo ChatGPT directamente desde la terminal, sin navegador y sin iniciar sesión en OpenAI.

    Se usa mucho para:

    • Resolver dudas técnicas rápidas
    • Explicar comandos Linux
    • Generar scripts
    • Pedir ejemplos de código
    • Documentar procesos
    • Automatizar consultas desde scripts

    No sustituye el razonamiento humano. Es un copiloto, no el piloto.



    2. Instalación en Windows

    Instalar Node.js

    1. Descargar desde: https://nodejs.org
    2. Instalar la versión LTS
    3. Verificar desde PowerShell o CMD:
    
    
    
    
    
    node -v
    npm -v
    

    Si aparecen versiones, todo va bien.


    Instalar tgpt

    En PowerShell o CMD:

    
    
    
    
    
    npm install -g tgpt
    

    Comprobar instalación:

    
    
    
    
    
    tgpt --help
    

    Primer uso en Windows

    Ejemplo simple:

    
    
    
    
    
    tgpt "¿Qué es un firewall?"
    

    Ejemplo técnico:

    
    
    
    
    
    tgpt "Explícame el comando netstat en Windows con ejemplos"
    

    3. Instalación en Linux (Ubuntu, Debian, Kali, Parrot…)

    curl -sSL https://raw.githubusercontent.com/aandrew-me/tgpt/main/install | bash -s /usr/local/bin
    

    Comprobar:

    
    
    
    
    
    tgpt --help
    

    Primer uso en Linux

    Ejemplo OSINT:

    
    
    
    
    
    tgpt "¿Qué es OSINT y qué tipos de fuentes existen?"
    

    Ejemplo Linux:

    
    
    
    
    
    tgpt "Explícame el comando grep con ejemplos reales"
    

    Ejemplo scripting:

    
    
    
    
    
    tgpt "Hazme un script bash para comprobar si un host responde a ping"
    

    4. Instalación en macOS

    5.1 Instalar Homebrew (si no está instalado)

    En Terminal:

    
    
    
    
    
    brew install tgpt

    Verificar:

    
    
    
    
    
    tgpt --help
    

    Ejemplo programación:

    
    
    
    
    
    tgpt "Dame un ejemplo sencillo de una API REST"
    

    Ejemplo sistemas:

    
    
    
    
    
    tgpt "Diferencias entre TCP y UDP explicadas para principiantes"
    

    5. Uso básico de tgpt

    Consulta directa

    
    
    
    
    
    tgpt "Explícame qué es un hash"
    

    Respuestas más técnicas

    
    
    
    
    
    tgpt "Explícame qué es SHA-256 con un ejemplo práctico"
    

    Modo conversación

    
    
    
    
    
    tgpt -c
    

    Permite hacer varias preguntas seguidas manteniendo contexto.


    Salida sin colores (útil para logs o scripts)

    
    
    
    
    
    tgpt --no-color "Qué es un IDS"
    

    6. Buenas prácticas

    • No copiar y pegar sin entender
    • Verificar comandos antes de ejecutarlos
    • Usar tgpt como ayuda, no como sustituto del aprendizaje
    • Contrastar respuestas técnicas
    • Documentar qué pregunta se hizo y por qué

    7. Ejemplos

    Ejemplo 1 – Linux

    
    
    
    
    
    tgpt "Explícame paso a paso cómo funciona chmod"
    

    Ejemplo 2 – Ciberseguridad

    
    
    
    
    
    tgpt "Diferencias entre IDS y IPS con ejemplos"
    

    Ejemplo 3 – OSINT

    
    
    
    
    
    tgpt "Herramientas OSINT que se pueden usar desde terminal"
    

    Ejemplo 4 – Programación

    
    
    
    
    
    tgpt "Ejemplo de conexión a MySQL en PHP usando PDO"
    

    8. Problemas comunes

    • command not found → tgpt no está en el PATH
    • Permisos npm → usar sudo en Linux
    • Node muy antiguo → actualizar Node.js
    • Respuestas erróneas → recordar que la IA puede equivocarse

    Opciones y flags con ejemplos reales

    Uso básico (sin flags)

    
    
    
    
    
    tgpt "¿Qué es un IDS?"
    

    Esto lanza una consulta directa y devuelve una respuesta estándar, con colores y formato amigable.

    Es el modo “háblame como a un humano”.


    -m → Elegir modelo (cuando está disponible)

    El flag -m permite indicar el modelo que se quiere usar.
    No siempre todos los modelos están activos, pero el concepto es clave didácticamente.

    
    
    
    
    
    tgpt -m gpt-3.5-turbo "Explícame qué es OSINT"
    

    Ejemplo técnico:

    
    
    
    
    
    tgpt -m gpt-3.5-turbo "Dame un ejemplo de escaneo pasivo"
    


    Prueba a comparar la misma pregunta con y sin -m y analizar diferencias de detalle, precisión o estilo.


    -s → Modo shell / respuesta corta y directa

    Este flag es oro para Linux.

    -s (shell mode) intenta responder como si fuera una ayuda de terminal: más conciso, menos charla.

    
    
    
    
    
    tgpt -s "comando para listar puertos abiertos en linux"
    

    Salida típica: comandos directos, sin narrativa larga.

    Ejemplo muy útil:

    
    
    
    
    
    tgpt -s "como ver mi ip publica en linux"
    

    -c → Modo conversación (contexto persistente)

    Activa un modo interactivo.
    tgpt recuerda lo que se ha dicho en esa sesión.

    
    
    
    
    
    tgpt -c
    

    Luego:

    
    
    
    
    
    ¿qué es nmap?
    ¿y en qué se diferencia de masscan?
    ponme un ejemplo práctico
    

    Esto es perfecto para:

    • razonamiento progresivo
    • tutoría guiada
    • simulación de mentor técnico

    El contexto se pierde al salir del programa.


    --no-color → Sin colores (scripts, logs, redirecciones)

    Cuando la salida se va a:

    • un archivo
    • un pipe
    • un script bash

    Los colores estorban.

    
    
    
    
    
    tgpt --no-color "qué es un hash" > hash.txt
    

    O encadenado:

    
    
    
    
    
    tgpt --no-color -s "comando para ver procesos" | less
    


    -q → Modo silencioso (solo respuesta)

    El flag -q elimina encabezados y texto adicional.

    
    
    
    
    
    tgpt -q "comando para ver usuarios conectados"
    

    Muy útil cuando:

    • quieres solo la respuesta
    • estás comparando resultados
    • lo usas como apoyo rápido

    Combinando flags (aquí está la magia)

    Ejemplo 1 – Linux puro

    
    
    
    
    
    tgpt -s -q "ver uso de disco en linux"
    

    Respuesta directa, corta, sin ruido.


    Ejemplo 2 – OSINT

    
    
    
    
    
    tgpt -s "herramientas osint que funcionen desde terminal"
    

    Ejemplo 3 – Para scripting

    
    
    
    
    
    tgpt --no-color -s "script bash para comprobar si un host responde a ping"
    

    Ejemplo 4 – Clase de ciberseguridad

    
    
    
    
    
    tgpt -c -s
    

    Y dentro:

    
    
    
    
    
    que es un firewall
    diferencia entre firewall y waf
    ejemplo en entorno real
    

    Ver todas las opciones disponibles

    Siempre recordar a los alumnos:

    
    
    
    
    
    tgpt --help
    

    Esto refuerza un hábito clave: leer la ayuda antes de preguntar.


    Ejercicios

    1. Ejecuta la misma pregunta de 3 formas:
      • sin flags
      • con -s
      • con -s -q
    2. Pregunta:
      • ¿Cuál es más útil para terminal?
      • ¿Cuál para aprender?
      • ¿Cuál para automatizar?

    Ejemplo de pregunta base:

    "comando para ver conexiones activas en linux"
    

    Chuleta rápida de tgpt


    tgpt no es ChatGPT, es una interfaz.
    Lo interesante no es la IA, sino cómo la integras en tu flujo de trabajo Linux:


  • Ollama – Chatbot IA Local en 5 Minutos

    Ollama – Chatbot IA Local en 5 Minutos

    ¿cuándo usar tgpt y cuándo usar Ollama?

    En el ecosistema actual de IA aplicada a terminal y ciberseguridad aparecen dos enfoques muy distintos:

    • tgpt → un cliente que conecta con modelos en la nube
    • Ollama → un motor local que ejecuta modelos en tu propio sistema

    Ambos usan IA. Pero resuelven problemas distintos.


    1. Qué es tgpt (en una frase honesta)

    tgpt es un puente entre tu terminal y modelos en la nube.

    • No ejecuta IA local
    • Envía tus prompts a un servicio externo
    • Devuelve la respuesta en texto, integrada en la terminal

    Mentalmente:

    “Un ChatGPT sin navegador, pegado a la shell.”


    2. Qué es Ollama (en una frase honesta)

    Ollama es una plataforma para ejecutar modelos de IA localmente.

    • Los modelos están en tu disco
    • El razonamiento ocurre en tu máquina
    • No depende de Internet
    • Tú controlas datos, logs y flujos

    Mentalmente:

    “Un motor de IA como si fuera un servicio más del sistema.”


    3. Comparativa

    AspectotgptOllama
    TipoClienteMotor local
    Dónde se ejecuta la IANubeTu servidor
    Requiere InternetNo
    PrivacidadBaja–mediaAlta
    Consumo de recursos localesMuy bajoMedio–alto
    Facilidad de usoMuy altaMedia
    Control del sistemaNuloTotal
    Ideal paraConsultas rápidasIntegración técnica
    Uso en producciónNo
    Valor educativo en ciberConceptualArquitectónico

    4. Cuándo es mejor usar tgpt

    Usa tgpt cuando:

    • Quieres rapidez
    • Estás aprendiendo conceptos
    • Necesitas ayuda puntual con:
      • comandos
      • sintaxis
      • explicaciones
    • No te importa que el contenido viaje a la nube
    • Estás en un equipo con pocos recursos

    Ejemplos reales:

    • “Explícame este error de Bash”
    • “¿Qué hace este comando?”
    • “Dame una idea rápida”

    tgpt es ideal como calculadora mental avanzada.


    5. Cuándo es mejor usar Ollama

    Usa Ollama cuando:

    • Trabajas con:
      • logs reales
      • datos sensibles
      • salidas de herramientas de ciber
    • Quieres offline
    • Necesitas:
      • automatización
      • integración con scripts
      • auditoría y control
    • Estás enseñando arquitectura y seguridad
    • No quieres depender de terceros

    Ejemplos reales:

    • Analizar auth.log
    • Resumir resultados de nmap
    • Asistir en scripting
    • Crear un copiloto de terminal seguro
    • Laboratorios en red aislada

    Requisitos mínimos Ollama (realistas)

    Antes de tocar nada, conviene saber qué espera Ollama del hierro:

    • Ubuntu Server 24.04 LTS (OK)
    • Arquitectura x86_64
    • CPU decente (funciona sin GPU, pero paciencia)
    • RAM recomendada:
      • 8 GB → modelos pequeños (phi, tinyllama)
      • 16 GB o más → llama3, mistral, etc.
    • Acceso a internet

    Comprueba lo básico:

    lsb_release -a
    uname -m
    free -h
    



    Instalación

    Ollama se instala con un único script oficial. No snaps, no flatpaks, no dramas.

    
    
    
    
    
    curl -fsSL https://ollama.com/install.sh | sh
    

    Qué hace este script (para tu tranquilidad mental):

    • Descarga el binario de Ollama
    • Lo instala en /usr/bin/ollama
    • Crea un servicio systemd
    • Arranca Ollama automáticamente

    Comprobar que el servicio está vivo

    En un server, systemd manda:

    
    
    
    
    
    systemctl status ollama
    

    Deberías ver algo como:

    • Active: active (running)
    • Escuchando en 127.0.0.1:11434

    Si no está activo:

    
    
    
    
    
    sudo systemctl enable --now ollama
    

    Probar Ollama desde terminal

    Aquí viene la parte bonita: usar IA sin navegador.

    Prueba con un modelo ligero primero:

    
    
    
    
    
    ollama run phi
    

    O uno más conocido:

    
    
    
    
    
    ollama run llama3
    

    La primera vez:

    • Descarga el modelo
    • Puede tardar (no está roto, está pensando)

    Cuando veas un prompt tipo:

    
    
    
    
    
    >>> 
    

    Ya tienes un LLM local funcionando. Sin nube. Sin vender tu alma.


    Ver modelos instalados

    
    
    
    
    
    ollama list
    

    Descargar modelos sin ejecutarlos:

    
    
    
    
    
    ollama pull mistral
    ollama pull llama3:8b
    

    Uso como servicio (API local)

    Ollama levanta una API REST en local:

    • URL: http://localhost:11434

    Prueba rápida:

    
    
    
    
    
    curl http://localhost:11434/api/tags
    

    Esto es oro puro para:

    • Scripts Python
    • Herramientas OSINT
    • Automatización en ciber
    • Integrarlo con apps web internas

    Permitir acceso desde otra máquina (opcional)

    ⚠️ Ojo sysadmin: por defecto SOLO escucha en localhost.

    Si quieres que otros equipos accedan (por ejemplo, alumnos o un frontend):

    Edita el servicio:

    
    
    
    
    
    sudo systemctl edit ollama
    

    Añade:

    
    
    
    
    
    [Service]
    Environment="OLLAMA_HOST=0.0.0.0:11434"
    

    Luego:

    
    
    
    
    
    sudo systemctl daemon-reload
    sudo systemctl restart ollama
    

    Y abre firewall si procede:

    
    
    
    
    
    sudo ufw allow 11434/tcp
    

    Dónde guarda Ollama los modelos

    Importante para servidores con discos separados:

    • Por defecto:
      /usr/share/ollama/.ollama

    Puedes moverlo usando:

    
    
    
    
    
    export OLLAMA_MODELS=/ruta/grande/ollama-models
    

    En server con /data o /mnt, esto es muy recomendable.


    Desinstalar

    sudo systemctl stop ollama
    sudo rm /usr/bin/ollama
    sudo rm /etc/systemd/system/ollama.service
    sudo rm -rf /usr/share/ollama
    

    Modelos Ollama – Tamaño en disco y recursos

    ModeloParámetros (B)RAM recomendadaTamaño en disco aprox.VelocidadUso típico
    tinyllama1.1B2–4 GB~0.7 GBMuy altaPruebas rápidas
    qwen2.5:0.5b0.5B2–3 GB~0.4 GBMuy altaComandos simples
    phi2.7B4–6 GB~1.6 GBMuy altaTerminal, docencia
    orca-mini3B6–8 GB~2.0 GBAltaExplicaciones
    mistral7B8 GB~4.1 GBAltaUso técnico
    qwen2.5:7b7B8 GB~4.0 GBAltaCódigo
    llama3:8b8B8–10 GB~4.7 GBAltaCiber, logs
    codellama7B8–10 GB~3.8–4.2 GBMediaProgramación
    deepseek-coder6–7B8–12 GB~3.5–4.0 GBMediaCódigo
    nous-hermes7–13B8–16 GB~4.5–8.0 GBMediaRazonamiento
    mixtral:8x7bMoE16–32 GB~26–28 GBMediaAnálisis complejo
    llama3:70b70B64+ GB~40–45 GBBajaServidores grandes
    gemma:7b7B8 GB~4.0 GBAltaLenguaje
    yi:6b6B8 GB~3.5 GBMediaMultilenguaje
    yi:34b34B32+ GB~20–22 GBBajaAnálisis profundo

    Comprobar que Ollama está instalado y activo

    En tu Ubuntu Server 24:

    
    
    
    
    
    ollama --version
    systemctl status ollama
    

    Si ves versión y estado active (running), seguimos.


    Instalar (descargar) el modelo codellama

    Instalar un modelo en Ollama es simplemente hacer un pull:

    
    
    
    
    
    ollama pull codellama
    

    Qué ocurre aquí:

    • Se descarga el modelo
    • Se guarda en disco
    • No se ejecuta todavía
    • Puede tardar (son ~4 GB)

    Paciencia de sysadmin.


    Verificar que el modelo está instalado

    
    
    
    
    
    ollama list
    

    Deberías ver algo así:

    
    
    
    
    
    NAME           ID            SIZE     MODIFIED
    codellama      xxxx          ~4.0 GB  …
    

    Usar el modelo

    Modo interactivo

    
    
    
    
    
    ollama run codellama
    

    Te aparecerá:

    
    
    
    
    
    >>>
    

    Ejemplo:

    
    
    
    
    
    >>> escribe un script bash que liste usuarios conectados
    

    Responderá orientado a código, no a charla.


    Uso directo (una sola petición)

    
    
    
    
    
    ollama run codellama "escribe un script en bash para hacer backup de /etc"
    

    Perfecto para redirecciones:

    
    
    
    
    
    ollama run codellama "crea un script de backup de /etc" > backup.sh
    chmod +x backup.sh
    

    Elegir tamaño de codellama (muy importante)

    codellama tiene variantes. Puedes pedir una concreta:

    VarianteRAM recomendadaDisco aprox.
    codellama:7b8–10 GB~3.8 GB
    codellama:13b14–18 GB~7–8 GB
    codellama:34b32+ GB~20 GB

    Ejemplo explícito:

    
    
    
    
    
    ollama pull codellama:7b
    

    Si no indicas nada, Ollama suele traer la variante por defecto (normalmente 7B).

    Uso de Ollama en ejecución del sistema

    Ollama puede:

    • Generar comandos
    • Generar scripts
    • Generar código
    • Analizar salidas de comandos
    • Decidir qué comando habría que ejecutar

    Pero alguien tiene que ejecutarlos. Ese alguien eres tú… o un wrapper.

    El esquema mental sano es este:

    
    
    
    
    
    [ Usuario ] → [ Ollama (razona) ] → [ Script intermedio ] → [ Sistema ]
    

    Nunca:

    
    
    
    
    
    IA → root → caos

    Ollama puede generar contenido:

    
    
    
    
    
    
    
    
    
    
    ollama run llama3 "Escribe un README.md sobre este proyecto" > README.md
    

    Aquí sí crea archivos, pero porque la shell redirige la salida.
    Ollama sigue sin tocar el sistema.


    El peligro real

    El riesgo no es Ollama.
    El riesgo es esto:

    #Peligro
    eval "$(ollama run llama3 'dame un comando para limpiar el sistema')"

    Ejecutar comandos con control (wrapper en Bash)

    #!/bin/bash
    if [ $# -gt 0 ]; then
      pregunta$1
    else
        read -p "Pregunta a la IA: " pregunta
    fi
    
    
    
    respuesta=$(ollama run phi "$pregunta. Devuelve SOLO un comando seguro.")
    
    echo "La IA propone ejecutar:"
    echo "$respuesta"
    
    read -p "¿Ejecutar? (s/n): " ok
    if [[ "$ok" == "s" ]]; then
        eval "$respuesta"
    fi
    

    Qué ocurre aquí:

    • Ollama propone
    • El humano autoriza
    • El sistema ejecuta

    En Linux, un comando es solo:

    • un archivo ejecutable
    • ubicado en un directorio que esté en $PATH

    Si eso se cumple → se ejecuta desde cualquier sitio.

    Compruébalo:

    
    
    
    
    
    echo $PATH
    

    Verás cosas como:

    • /usr/bin
    • /usr/local/bin
    • /bin

    Ahí es donde viven los comandos “del sistema”.


    Opción recomendada: /usr/local/bin (limpio y correcto)

    Supongamos que tu script se llama ollama-shell.sh.

    Mover el script

    
    
    
    
    
    sudo mv ollama-shell.sh /usr/local/bin/ollama-shell
    

    Nota:

    • Quitamos .sh → parece un comando real
    • Linux no necesita extensión

    Dar permisos de ejecución

    
    
    
    
    
    sudo chmod +x /usr/local/bin/ollama-shell
    

    Probar desde cualquier sitio

    
    
    
    
    
    cd /tmp
    ollama-shell
    

    Script Wraper avanzado

    Aquí tienes un script con muchas mas opciones:

    #!/usr/bin/env bash
    set -euo pipefail
    
    # -----------------------------
    # Ollama Shell Assistant (Seguro)
    # - Pregunta a un modelo Ollama local
    # - Fuerza español usando modelo "llama3-es"
    # - Devuelve un único comando
    # - Valida contra lista blanca
    # - Pide confirmación antes de ejecutar
    # - Registra todo en /var/log/ollama-shell.log
    # -----------------------------
    
    MODEL="${MODEL:-llama3-es}"
    LOG_FILE="${LOG_FILE:-/var/log/ollama-shell.log}"
    
    MODE="${MODE:-ask}"  # ask | exec
    TIMEOUT_SECS="${TIMEOUT_SECS:-120}"
    
    # Lista blanca básica de comandos permitidos (ajústala a tu contexto)
    ALLOW_CMDS=(
      "ls" "ll" "pwd" "cd"
      "cat" "less" "head" "tail"
      "grep" "egrep" "fgrep" "awk" "sed" "cut" "sort" "uniq" "wc"
      "find" "locate" "which" "whereis"
      "ip" "ss" "netstat" "ping" "traceroute" "dig" "nslookup" "curl" "wget"
      "ps" "top" "htop" "free" "df" "du" "uptime" "uname" "lsblk"
      "systemctl" "journalctl"
      "who" "w" "id" "groups" "last" "lastb"
      "tar" "gzip" "gunzip" "zip" "unzip"
      "apt" "apt-get" "dpkg" "snap"
      "nmap"
    )
    
    print_help() {
      cat <<'EOF'
    Uso:
      ollama-shell [-e] [-m MODELO] "pregunta..."
      ollama-shell --suggest "pregunta..."
      ollama-shell --exec "pregunta..."
      ollama-shell --help
    
    Opciones:
      -m, --model     Modelo Ollama a usar (por defecto: llama3-es)
      -e, --exec      Permite ejecutar (con confirmación humana)
      --suggest       Solo sugiere (no ejecuta)
      --log FILE      Archivo de log (por defecto: /var/log/ollama-shell.log)
    
    Variables:
      MODEL=llama3-es
      MODE=ask|exec
      LOG_FILE=/var/log/ollama-shell.log
      TIMEOUT_SECS=120
    
    Notas:
    - El modelo debe devolver SOLO UN comando.
    - Se valida el comando contra una lista blanca básica.
    EOF
    }
    
    die() {
      echo "ERROR: $*" >&2
      exit 1
    }
    
    ensure_ollama() {
      command -v ollama >/dev/null 2>&1 || die "No encuentro 'ollama' en PATH. ¿Está instalado?"
      systemctl is-active --quiet ollama 2>/dev/null || true
    }
    
    ensure_log_writable() {
      # Intentar escribir en LOG_FILE; si no se puede, degradar a ~/.ollama-shell.log
      if ! (touch "$LOG_FILE" 2>/dev/null); then
        LOG_FILE="$HOME/.ollama-shell.log"
        touch "$LOG_FILE" || die "No puedo escribir logs ni en /var/log ni en HOME."
      fi
    }
    
    log_line() {
      local msg="$1"
      printf '%s | user=%s | cwd=%s | %s\n' "$(date '+%F %T')" "${USER:-unknown}" "$(pwd)" "$msg" >> "$LOG_FILE"
    }
    
    trim() {
      sed -e 's/^[[:space:]]*//' -e 's/[[:space:]]*$//'
    }
    
    first_token() {
      # Devuelve el primer token (comando base), ignorando sudo si aparece
      local s="$1"
      s="$(echo "$s" | trim)"
      if [[ "$s" == sudo\ * ]]; then
        echo "$s" | awk '{print $2}'
      else
        echo "$s" | awk '{print $1}'
      fi
    }
    
    is_allowed_cmd() {
      local cmd="$1"
      for a in "${ALLOW_CMDS[@]}"; do
        [[ "$cmd" == "$a" ]] && return 0
      done
      return 1
    }
    
    looks_dangerous() {
      # Filtros anti-destrucción básicos (no exhaustivos)
      local s="$1"
      s="$(echo "$s" | trim)"
      [[ -z "$s" ]] && return 0
    
      # Cosas típicas peligrosas
      if echo "$s" | grep -Eqi 'rm\s+-rf\s+/' ; then return 0; fi
      if echo "$s" | grep -Eqi 'mkfs|dd\s+if=|:\(\)\s*\{\s*:\|\s*:\s*;\s*\}\s*;|shutdown|reboot|poweroff' ; then return 0; fi
      if echo "$s" | grep -Eqi '>\s*/etc/|>\s*/bin/|>\s*/usr/bin/|chown\s+root|chmod\s+4[0-7]{3}|chmod\s+u\+s' ; then return 0; fi
    
      # Inyección obvia
      if echo "$s" | grep -Eqi '\$\(|`' ; then return 0; fi
    
      return 1
    }
    
    ask_ollama_for_command() {
      local question="$1"
    
      local prompt
      prompt=$(
        cat <<EOF
    Eres un asistente técnico experto en Linux y ciberseguridad.
    Respondes SIEMPRE en español.
    Tu tarea: proponer EXACTAMENTE UN comando de terminal (una sola línea) para ayudar con la petición del usuario.
    REGLAS:
    - Devuelve SOLO el comando. Sin explicaciones. Sin comillas. Sin markdown.
    - El comando debe ser lo más seguro posible (preferir lectura/consulta a escritura).
    - Evita acciones destructivas. No uses rm, mkfs, dd, ni cambios de permisos peligrosos.
    Petición del usuario:
    $question
    EOF
      )
    
      # Timeout para evitar bloqueos largos
      # Nota: 'timeout' suele estar en coreutils
      if command -v timeout >/dev/null 2>&1; then
        timeout "$TIMEOUT_SECS" ollama run "$MODEL" "$prompt" 2>/dev/null | head -n 1 | trim
      else
        ollama run "$MODEL" "$prompt" 2>/dev/null | head -n 1 | trim
      fi
    }
    
    confirm() {
      local msg="$1"
      read -r -p "$msg (s/n): " ans
      [[ "${ans,,}" == "s" ]]
    }
    
    main() {
      local question=""
      local explicit_mode=""
      local explicit_model=""
      local explicit_log=""
    
      while [[ $# -gt 0 ]]; do
        case "$1" in
          -m|--model) explicit_model="$2"; shift 2 ;;
          -e|--exec) explicit_mode="exec"; shift ;;
          --suggest) explicit_mode="ask"; shift ;;
          --log) explicit_log="$2"; shift 2 ;;
          -h|--help) print_help; exit 0 ;;
          *)
            # Resto como pregunta (permitimos comillas)
            question="$*"
            break
            ;;
        esac
      done
    
      [[ -n "$explicit_model" ]] && MODEL="$explicit_model"
      [[ -n "$explicit_mode" ]] && MODE="$explicit_mode"
      [[ -n "$explicit_log" ]] && LOG_FILE="$explicit_log"
    
      [[ -z "$question" ]] && die "Falta la pregunta. Usa --help para ver ejemplos."
    
      ensure_ollama
      ensure_log_writable
    
      log_line "question=$(printf '%q' "$question") model=$MODEL mode=$MODE"
    
      local cmd
      cmd="$(ask_ollama_for_command "$question")"
    
      log_line "raw_cmd=$(printf '%q' "$cmd")"
    
      [[ -z "$cmd" ]] && die "El modelo no devolvió un comando."
    
      # Validaciones básicas
      if looks_dangerous "$cmd"; then
        log_line "blocked_reason=dangerous_pattern"
        die "Comando bloqueado por patrón peligroso: $cmd"
      fi
    
      local base
      base="$(first_token "$cmd")"
      if ! is_allowed_cmd "$base"; then
        log_line "blocked_reason=not_in_allowlist base=$base"
        die "Comando bloqueado (no está en la lista blanca): $base"
      fi
    
      echo "$cmd"
    
      if [[ "$MODE" == "exec" ]]; then
        if confirm "¿Ejecutar el comando anterior?"; then
          log_line "exec=YES cmd=$(printf '%q' "$cmd")"
          # Ejecuta tal cual (sin eval). Bash interpretará la línea como comando.
          bash -lc "$cmd"
        else
          log_line "exec=NO"
          echo "Cancelado."
        fi
      else
        echo "Modo sugerencia (no ejecuto nada). Usa --exec para permitir ejecución con confirmación."
      fi
    }
    
    main "$@"
    

    Instalación global (para todo el sistema)

    1. Mueve el script a /usr/local/bin y dale permisos:
    
    
    
    
    
    sudo mv ollama-shell /usr/local/bin/ollama-shell
    sudo chmod +x /usr/local/bin/ollama-shell
    
    1. Prueba:
    
    
    
    
    
    ollama-shell "muestra los puertos en escucha"
    
    1. Para permitir ejecución (con confirmación):
    
    
    
    
    
    ollama-shell --exec "muestra los últimos intentos de login fallidos"
    

    Forma más simple: usar el modelo por defecto

    En el script que te pasé, al principio tienes:

    
    
    
    
    
    MODEL="${MODEL:-llama3-es}"
    

    Eso significa:

    • Si no indicas nada, usa llama3-es
    • Es el comportamiento por defecto

    Ejemplo:

    
    
    
    
    
    ollama-shell "lista los usuarios conectados"
    

    Usa automáticamente llama3-es.


    Indicar el modelo en la llamada (recomendado)

    El script soporta el parámetro -m o --model.

    Ejemplo:

    
    
    
    
    
    ollama-shell -m codellama-es "crea un script bash para hacer backup de /etc"
    

    Aquí:

    • No tocas el script
    • Cambias el modelo solo para esa ejecución
    • Ideal para comparar modelos en clase

    Forzar el modelo con variable de entorno

    Esto es muy Unix y muy elegante.

    Para una sola ejecución

    
    
    
    
    
    MODEL=codellama-es ollama-shell "analiza este script"
    

    Para toda la sesión

    
    
    
    
    
    export MODEL=codellama-es
    ollama-shell "genera un Makefile sencillo"
    

    Hasta que cierres la terminal, siempre usará ese modelo.


    Cambiar el modelo por defecto en el script

    Si quieres que siempre use codellama-es, edita el script:

    
    
    
    
    
    nano /usr/local/bin/ollama-shell
    

    Busca:

    
    
    
    
    
    MODEL="${MODEL:-llama3-es}"
    

    Y cambia a:

    
    
    
    
    
    MODEL="${MODEL:-codellama-es}"
    

    A partir de ahí, ese será el modelo base.


    Ver qué modelo se está usando (opcional pero didáctico)

    Si quieres que el script lo muestre, añade justo antes de llamar a Ollama:

    
    
    
    
    
    echo "Modelo en uso: $MODEL"
    

    O loguéalo:

    
    
    
    
    
    log_line "model_in_use=$MODEL"
    

    Esto es muy bueno para auditoría


    Ejemplos

    ComandoQué ocurre
    ollama-shell "ver procesos"Usa modelo por defecto
    ollama-shell -m phi "ver procesos"Usa phi
    MODEL=codellama-es ollama-shell "crear script"Usa codellama-es
    ollama-shell --exec -m llama3-es "ver puertos"Ejecuta con llama3-es

    Comandos básicos que conviene conocer

    
    
    
    
    
    ollama run llama3:8b # Ejecutar modelo
    ollama list # Modelos instalados 
    ollama pull mistral # Descargar modelo 
    ollama rm mistral # Borrar modelo 
    ollama ps # Modelos en uso 
    ollama stop llama3:8b # Detener modelo

    Instalación en Mac-os

    1️⃣ Descarga

    https://ollama.com/download/mac

    Pulsa Download for macOS


    2️⃣ Instala

    • Abre el .dmg
    • Arrastra Ollama a Applications
    • Ábrelo (la primera vez macOS pedirá permiso)

    📌Ollama se queda ejecutándose en segundo plano (daemon).


    3️⃣ Verifica desde Terminal

    Abre Terminal y ejecuta:

    
    
    
    
    
    ollama --version
    

    Si ves algo como:

    
    
    
    
    
    ollama version x.x.x
    

    ✔️ Instalación correcta


    Primer uso: ejecutar un modelo

    Descargar y ejecutar LLaMA 3 (8B)

    
    
    
    
    
    ollama run llama3:8b
    

    La primera vez:

    • Descarga el modelo (varios GB)
    • Luego entras directamente en modo conversación
  • 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