Autor: ciberkaos

  • Etica para ingenieros – 2 Análisis de la realidad social desde la revolución tecnológica

    📘 Capítulo 2 — Análisis de la realidad social desde la revolución tecnológica

    (Resumen extenso y desarrollado)

    Este capítulo amplía el marco iniciado en el capítulo 1 y da un paso decisivo: situar la ingeniería en el corazón de la transformación social contemporánea. Los autores sostienen que no se puede comprender la sociedad actual sin comprender la revolución tecnológica, y que, por tanto, el ingeniero ocupa una posición central en esa transformación.

    El objetivo del capítulo no es describir tecnologías concretas, sino analizar cómo la tecnología reconfigura la realidad social, y qué papel juegan los ingenieros en ese proceso.


    1️⃣ La revolución tecnológica como fenómeno histórico

    El capítulo parte de una afirmación clave:

    Vivimos una de las transformaciones más profundas de la historia, comparable a grandes revoluciones anteriores.

    La revolución tecnológica contemporánea no es:

    • Un simple avance técnico
    • Una sucesión de innovaciones aisladas

    Sino un proceso global, continuo y acelerado que afecta:

    • A la economía
    • A la política
    • A la cultura
    • A la vida cotidiana
    • A la forma en que las personas se relacionan entre sí

    La tecnología deja de ser un instrumento puntual y se convierte en:

    Una estructura básica de la sociedad moderna


    2️⃣ La tecnología como sistema, no como herramienta aislada

    Uno de los ejes del capítulo es romper con la visión ingenua de la tecnología como “simple herramienta”.

    Los autores subrayan que:

    • La tecnología funciona como un sistema complejo
    • Cada innovación se integra en redes técnicas, económicas y sociales
    • Ninguna tecnología es neutral o independiente de su contexto

    Esto implica que:

    • Introducir una tecnología modifica comportamientos
    • Reorganiza relaciones de poder
    • Genera nuevas dependencias
    • Produce efectos no previstos

    ➡️ La ingeniería actúa, por tanto, sobre sistemas sociales, no solo sobre objetos técnicos.


    3️⃣ Tecnología y economía

    El capítulo analiza en profundidad la relación entre tecnología y sistema económico.

    Ideas centrales:

    • La tecnología es motor fundamental del crecimiento económico
    • Aumenta la productividad
    • Reconfigura el trabajo y el empleo

    Pero también:

    • Genera desigualdades
    • Desplaza profesiones
    • Crea nuevas formas de precariedad
    • Introduce criterios puramente económicos en decisiones técnicas

    Los autores advierten contra una visión reduccionista:

    No todo lo técnicamente eficiente es socialmente deseable.

    El ingeniero se encuentra muchas veces atrapado entre:

    • La lógica del mercado
    • La presión de la rentabilidad
    • Las consecuencias sociales de sus decisiones

    Aquí se empieza a perfilar el conflicto ético estructural del ingeniero moderno.


    4️⃣ Tecnología y política

    La tecnología no es políticamente neutra.

    El capítulo muestra cómo:

    • Las decisiones tecnológicas influyen en el poder
    • Determinan quién controla recursos, información y capacidades
    • Pueden reforzar o debilitar la democracia

    Ejemplos conceptuales (no concretos):

    • Infraestructuras
    • Sistemas de comunicación
    • Tecnologías de control y vigilancia
    • Automatización de decisiones

    El ingeniero participa, muchas veces sin ser consciente, en:

    Decisiones con profundas implicaciones políticas

    Por ello, el capítulo insiste en que:

    • Delegar la responsabilidad “en los políticos” es insuficiente
    • La decisión técnica ya contiene una decisión política implícita

    5️⃣ Tecnología y cultura

    La tecnología también transforma:

    • Valores
    • Hábitos
    • Formas de pensar
    • Expectativas vitales

    El capítulo analiza cómo:

    • La cultura tecnológica tiende a valorar la eficiencia, la rapidez y el control
    • Se normaliza la idea de que “todo problema tiene solución técnica”
    • Se reduce el espacio para la reflexión ética o el debate social

    Los autores advierten del peligro del tecnologismo:

    La creencia de que la técnica puede resolver por sí sola todos los problemas humanos.

    Esta mentalidad:

    • Empobrece el juicio moral
    • Reduce la complejidad de los problemas sociales
    • Desplaza la responsabilidad ética hacia la “inevitabilidad técnica”

    6️⃣ El mito de la neutralidad tecnológica

    Uno de los núcleos más importantes del capítulo es la crítica a la neutralidad tecnológica.

    Se desmonta la idea de que:

    “La tecnología es neutral; depende del uso que se haga de ella”

    Los autores argumentan que:

    • Toda tecnología incorpora valores
    • Prioriza ciertos fines frente a otros
    • Favorece determinadas formas de organización social

    Ejemplos conceptuales:

    • Tecnologías que favorecen el control frente a la autonomía
    • Sistemas que priorizan eficiencia frente a seguridad
    • Diseños que excluyen a ciertos colectivos

    ➡️ El ingeniero participa activamente en la incorporación de valores a la tecnología.


    7️⃣ Ingeniería y cambio social

    El capítulo subraya que:

    • Los ingenieros no son meros ejecutores
    • Son agentes del cambio social

    Esto significa que:

    • Contribuyen a definir el tipo de sociedad futura
    • Influyen en cómo se vive, se trabaja y se convive

    La ingeniería moderna:

    • No solo responde a demandas sociales
    • También las crea

    Por tanto, el ingeniero debe preguntarse:

    • ¿Qué tipo de mundo estoy ayudando a construir?
    • ¿A quién beneficia esta tecnología?
    • ¿A quién puede perjudicar?

    8️⃣ Responsabilidad en un contexto de complejidad

    La complejidad tecnológica dificulta:

    • Prever todas las consecuencias
    • Atribuir responsabilidades claras

    Sin embargo, el capítulo insiste en que:

    La complejidad no elimina la responsabilidad ética.

    Al contrario:

    • La aumenta
    • Exige prudencia
    • Exige reflexión colectiva
    • Exige humildad profesional

    El ingeniero debe aceptar que:

    • No controla todo
    • Pero sí es responsable de evaluar riesgos razonables
    • De advertir sobre peligros
    • De no actuar de forma ciega o acrítica

    9️⃣ Preparación del terreno para la ética de la ingeniería

    El capítulo concluye enlazando con el resto del libro:

    • La ingeniería es central en la revolución tecnológica
    • Esa revolución transforma la sociedad en todos sus niveles
    • Por tanto, la ética de la ingeniería es una necesidad histórica, no un lujo académico

    La ética profesional:

    • No frena el progreso
    • Lo orienta
    • Lo humaniza

    🧠 Ideas clave del Capítulo 2 (síntesis final)

    • La revolución tecnológica es un fenómeno social global
    • La tecnología funciona como sistema, no como herramienta aislada
    • No existe neutralidad tecnológica
    • La ingeniería influye en economía, política y cultura
    • El ingeniero es agente del cambio social
    • La responsabilidad ética aumenta con el poder tecnológico
    • La ética es necesaria para orientar el progreso técnico
  • Etica para ingenieros – 1 La profesión de la ingeniería

    📘 Capítulo 1 — La profesión de la ingeniería

    (Resumen extenso y explicado)

    El Capítulo 1 tiene como objetivo situar la ingeniería dentro del conjunto de las profesiones sociales, analizando qué significa ser ingeniero no solo desde el punto de vista técnico, sino social, histórico y ético. No entra todavía en normas morales concretas, sino que construye el marco conceptual necesario para entender por qué la ética es inseparable de la ingeniería.


    1️⃣ La actividad profesional como fenómeno social

    El capítulo comienza afirmando una idea clave:

    Toda actividad profesional es un fenómeno social, y la ingeniería no es una excepción.

    La ingeniería:

    • No se ejerce en el vacío
    • No es solo una actividad individual
    • Está profundamente insertada en la estructura de la sociedad

    Esto implica que:

    • Responde a necesidades sociales
    • Produce efectos colectivos
    • Goza de reconocimiento y confianza pública

    Por tanto, la ingeniería tiene consecuencias sociales reales, y no puede analizarse solo desde criterios técnicos.


    2️⃣ ¿Qué es una profesión?

    Antes de hablar específicamente de la ingeniería, los autores analizan qué entendemos por “profesión” desde la sociología.

    Una profesión se caracteriza por:

    • Un saber especializado
    • Una formación específica
    • Un reconocimiento social
    • Un servicio a la sociedad
    • Una cierta autonomía en el ejercicio
    • Un compromiso ético implícito

    No toda actividad laboral es una profesión.
    La ingeniería sí lo es, porque cumple todas estas condiciones.

    👉 Esto es importante porque las profesiones generan expectativas morales: la sociedad espera algo más que eficacia técnica.


    3️⃣ El lugar social de las profesiones

    Las profesiones ocupan un lugar central en las sociedades modernas, porque:

    • Median entre el conocimiento especializado y las necesidades sociales
    • Influyen en la organización económica, política y tecnológica

    En el caso de la ingeniería:

    • Su papel es especialmente relevante
    • Tiene una capacidad transformadora mayor que muchas otras profesiones

    Los autores citan a pensadores clásicos (como Max Weber o Durkheim) para mostrar que:

    • Las profesiones no son neutras
    • Siempre reflejan valores, intereses y modelos de sociedad

    ➡️ La ingeniería participa activamente en la construcción del mundo social.


    4️⃣ La ingeniería como profesión específica

    Tras este marco general, el capítulo se centra ya en la ingeniería.

    La ingeniería se define como:

    • Una actividad profesional
    • Basada en conocimientos científicos y técnicos
    • Orientada a diseñar, construir y transformar la realidad

    Pero lo fundamental es que:

    • La ingeniería no solo produce objetos
    • Produce formas de vida, infraestructuras, sistemas y condiciones de existencia

    Ejemplos implícitos:

    • Redes eléctricas
    • Sistemas de transporte
    • Tecnologías digitales
    • Infraestructuras críticas

    Todo ello afecta directamente a las personas, incluso a quienes no han elegido usar esas tecnologías.


    5️⃣ El ingeniero y la responsabilidad social

    Una de las ideas más importantes del capítulo es que:

    El ingeniero no es solo responsable de “hacer bien su trabajo”, sino de entender el impacto social de su trabajo.

    Esto implica:

    • Que el ingeniero no puede refugiarse únicamente en la obediencia técnica
    • Que las decisiones técnicas son también decisiones sociales

    El texto critica expresamente la idea de que:

    “Yo solo aplico lo que me piden”

    Porque:

    • Las decisiones técnicas no son neutrales
    • Siempre implican valores: eficiencia, seguridad, coste, riesgo, sostenibilidad, etc.

    6️⃣ Ingeniería, poder y confianza social

    La sociedad concede a los ingenieros:

    • Autoridad técnica
    • Confianza
    • Capacidad de decisión

    Esa confianza se basa en que:

    • El ingeniero actuará con competencia
    • Pero también con responsabilidad

    Aquí aparece una idea crucial:

    A mayor poder técnico, mayor responsabilidad ética

    La ingeniería moderna maneja:

    • Sistemas complejos
    • Riesgos elevados
    • Impactos a gran escala

    Por tanto, la exigencia ética aumenta, no disminuye.


    7️⃣ Dimensión colectiva de la ingeniería

    El capítulo insiste en que:

    • La ingeniería rara vez es una actividad individual
    • Se ejerce en equipos, empresas y organizaciones

    Esto no elimina la responsabilidad personal:

    • La responsabilidad es compartida, no diluida
    • Formar parte de una organización no exime de reflexión ética

    Se empieza a preparar así el terreno para capítulos posteriores sobre:

    • Responsabilidad profesional
    • Ética organizacional
    • Códigos profesionales

    8️⃣ Por qué es necesaria una ética profesional de la ingeniería

    El capítulo concluye dejando claro que:

    • La ética profesional no es una moral abstracta
    • Surge de las condiciones reales del ejercicio profesional

    La ética de la ingeniería es necesaria porque:

    • La ingeniería transforma la sociedad
    • Maneja riesgos
    • Tiene impacto a largo plazo
    • Afecta a personas que no participan en la decisión

    ➡️ No basta con ser un buen técnico.
    ➡️ Es necesario ser un profesional responsable.

    Este capítulo no da todavía normas concretas, pero establece el fundamento:

    La ingeniería, por su naturaleza social, exige una reflexión ética propia.


    🧠 Ideas clave del capítulo (para estudiar)

    • La ingeniería es una profesión social, no solo técnica
    • Las profesiones generan responsabilidades éticas
    • La ingeniería tiene gran poder transformador
    • No existe neutralidad técnica
    • La responsabilidad del ingeniero es social y moral
    • La ética profesional es una exigencia interna de la profesión
  • Etica para ingenieros – Intro

    Aquí tienes un resumen claro y estructurado del PDF Ética para ingenieros de Galo Bilbao, Javier Fuertes y José Mª Guibert, pensado para comprenderlo rápido y también para usarlo en contexto académico

    📘 Resumen de Ética para ingenieros

    El libro analiza la ingeniería no solo como una actividad técnica, sino como una práctica profundamente social y moral, defendiendo que no existe una ingeniería “neutral”: toda decisión técnica tiene consecuencias humanas, sociales, políticas y ambientales.


    🎯 Idea central del libro

    Ser buen ingeniero no es solo saber hacer bien las cosas, sino hacer las cosas correctas.

    La ética no es un añadido externo, sino parte esencial de la competencia profesional del ingeniero.


    🧱 Estructura y contenido principal

    1️⃣ La ingeniería como profesión social

    (Capítulo 1)

    • La ingeniería es una profesión socialmente reconocida, con poder real para transformar la sociedad.
    • El ingeniero no actúa de forma aislada, sino dentro de organizaciones, equipos y estructuras.
    • Toda profesión implica:
      • Responsabilidad
      • Compromiso social
      • Impacto colectivo

    ➡️ Se introduce la necesidad de una ética profesional específica, no genérica.


    2️⃣ Tecnología y sociedad

    (Capítulo 2)

    • La tecnología no es neutral: condiciona la economía, la política, la cultura y la vida cotidiana.
    • El ingeniero es actor clave de la revolución tecnológica.
    • Se analizan las relaciones:
      • Tecnología ↔ economía
      • Tecnología ↔ política
      • Tecnología ↔ cultura

    ➡️ El progreso técnico no garantiza progreso humano si no se orienta éticamente.


    3️⃣ Ética y tecnociencia

    (Capítulo 3)

    • Ciencia y tecnología están unidas a valores, intereses y decisiones.
    • Se rompe el mito de que: “La técnica solo ejecuta, otros deciden”
    • La ética entra en:
      • Diseño
      • Elección de medios
      • Evaluación de consecuencias

    ➡️ El ingeniero comparte responsabilidad moral sobre los efectos de la tecnología.


    4️⃣ Ética profesional y sus principios

    (Capítulo 4)

    Se definen los principios básicos de la ética profesional del ingeniero, entre ellos:

    • Responsabilidad
    • Justicia
    • Honestidad
    • Competencia
    • Servicio a la sociedad

    También se analizan riesgos habituales:

    • Tecnocracia
    • Obediencia ciega
    • Priorizar solo eficiencia y rentabilidad
    • Desvincularse del impacto social

    🔍 Segunda parte: hacia una ética aplicada a la ingeniería

    5️⃣ La sociedad del riesgo

    (Capítulo 5)

    • Vivimos en una sociedad donde los riesgos tecnológicos son inevitables.
    • El riesgo:
      • No es solo técnico
      • Es también social, político y moral
    • El ingeniero participa en:
      • Creación
      • Gestión
      • Minimización del riesgo

    6️⃣ La virtud de la prudencia

    (Capítulo 6)

    • La prudencia no es miedo, sino capacidad de decidir bien en contextos complejos.
    • Implica:
      • Visión sistémica
      • Anticipar consecuencias
      • Pensar a largo plazo

    7️⃣ Decisión racional y ética

    (Capítulo 7)

    • Se analiza la toma de decisiones éticas en ingeniería.
    • No basta con cálculos técnicos.
    • Se incorporan:
      • Dilemas morales
      • Cooperación
      • Responsabilidad compartida

    8️⃣ El principio de responsabilidad

    (Capítulo 8)

    • El ingeniero debe responder:
      • Por lo que hace
      • Por lo que permite
      • Por lo que omite
    • Especial énfasis en:
      • Daños futuros
      • Impactos a largo plazo
      • Generaciones futuras

    9️⃣ Códigos profesionales y ética organizacional

    (Capítulo 9)

    • Importancia de:
      • Códigos deontológicos
      • Ética empresarial
      • Ética en la administración pública
    • Las organizaciones no eximen de responsabilidad individual.

    🧠 Mensaje final del libro

    • La excelencia técnica no basta sin excelencia ética.
    • El ingeniero debe:
      • Reflexionar
      • Justificar
      • Asumir consecuencias
    • La ética forma parte de la identidad profesional, no es una imposición externa.

    🧩 Frase clave que resume el libro

    La ingeniería configura el mundo en que vivimos; por eso, no puede renunciar a la responsabilidad moral sobre ese mundo.

  • Espanse – El poder de los atajos (Ubuntu)

    Espanse – El poder de los atajos (Ubuntu)

    Espanso es una de esas herramientas pequeñas que, cuando encajan en tu forma de trabajar, te roban minutos al reloj cada día y luego no los devuelven nunca. Y eso es bueno.

    Dicho sin épica innecesaria: Espanso es un expansor de texto a nivel de sistema.

    Escribes algo corto… y se transforma automáticamente en algo largo.

    Es el autocomplete de tu cerebro.

    Instalación en Ubuntu

    Antes de empezar. Espanso funciona de forma fiable en X11, no en Wayland.
    En Ubuntu moderno eso importa.

    Comprobar si estás en X11 o Wayland

    Abre una terminal y ejecuta:

    
    
    
    
    
    echo $XDG_SESSION_TYPE
    • x11 → perfecto, continúa
    • waylandrecomendado cambiar a X11

    Cambiar a X11 (GNOME)

    1. Cierra sesión
    2. En la pantalla de login, pulsa ⚙️
    3. Elige “Ubuntu on Xorg”
    4. Inicia sesión
    5. Comprueba otra vez con echo $XDG_SESSION_TYPE

    Descargar Espanso (versión X11)

    Ve a la web oficial: https://espanso.org/docs/install/linux/#deb-x11

    Descarga el paquete:

    • espanso-debian-x11-amd64.deb

    Opción recomendada: dpkg

    Evita problemas de permisos con _apt.

    
    
    
    
    
    sudo dpkg -i espanso-debian-x11-amd64.deb
    

    Si salen errores de dependencias:

    
    
    
    
    
    sudo apt -f install

    Espanso usa systemd de usuario.
    Si no lo registras, no arrancará solo.

    
    
    
    
    
    espanso service register
    

    Introduce tu contraseña si la pide.


    Arrancar Espanso

    
    
    
    
    
    espanso start
    

    Comprobar estado:

    
    
    
    
    
    espanso status
    

    Resultado esperado:

    
    
    
    
    
    espanso is running
    

    Probar que funciona

    Abre cualquier sitio donde puedas escribir:

    • Terminal
    • VS Code
    • Navegador
    • Editor de texto

    Escribe:

    
    
    
    
    
    :date
    

    Si se sustituye por la fecha → funciona.


    Dónde se configura Espanso

    Ruta principal:

    
    
    
    
    
    ~/.config/espanso/
    

    Atajos (lo importante):

    
    
    
    
    
    ~/.config/espanso/match/
    

    Ejemplo de atajo simple:

    
    
    
    
    
    matches:
      - trigger: ":hola"
        replace: "Hola mundo 👋"
    

    Después de editar:

    
    
    
    
    
    espanso restart
    

    Arranque automático (comprobación)

    Espanso debería arrancar solo al iniciar sesión.
    Puedes verificarlo con:

    
    
    
    
    
    systemctl --user status espanso

    Posibles problemas

    ProblemaCausa habitualSolución
    espanso is not runningEl servicio no está registradoEjecutar:~~~bashespanso service registerespanso start~~~
    No expande textoEstás en Wayland o Espanso no está activo• Comprobar sesión X11:~~~bashecho $XDG_SESSION_TYPE~~~• Probar en un editor gráfico (VS Code, navegador, etc.)• Reiniciar Espanso:~~~bashespanso restart~~~
    Error al instalar Espanso X11 teniendo WaylandConflicto entre paquetes espanso-wayland y espanso-x11Desinstalar primero Wayland:~~~bashsudo apt remove espanso-wayland~~~Luego instalar la versión X11

    ​Crear atajos en Espanso

    En Ubuntu los atajos de Espanso se guardan en ~/.config/espanso/match y se editan en archivos YAML como base.yml.

    Localizar la carpeta de Espanso en Ubuntu

    • Ruta por defecto (si no tocaste XDG): ~/.config/espanso (es decir, /home/tu_usuario/.config/espanso).

    También puedes verlo ejecutando:

    
    
    
    
    
    espanso path
    

    que te mostrará la ruta exacta de configuración en tu sistema.​

    Entra en la carpeta de matches:

      cd ~/.config/espanso/match
      

      Abre (o crea) base.yml con tu editor favorito, por ejemplo:

      
      
      
      
      
      nano base.yml
      

      Asegúrate de que al menos tenga esta estructura básica:

      
      
      
      
      
      matches:     
         - trigger: ":hola"      replace: "Hola, ¿qué tal?"
      • matches: es la clave raíz y cada - define un atajo.
      • trigger es lo que escribes y replace lo que Espanso inserta.

      Ejemplos pensados para Ubuntu

      Puedes añadir estos ejemplos bajo matches: en el mismo base.yml:

      
      
      
      
      
      matches:
        # Saludo rápido
        - trigger: ":saludo"
          replace: "Hola, ¿qué tal estás?"
      
        # Comando típico de actualización
        - trigger: ":aptup"
          replace: "sudo apt update && sudo apt upgrade -y"
      
        # Firma para correos
        - trigger: ":firma"
          replace: "Un saludo,\nTu Nombre"
      
        # Fecha actual (útil para documentación)
        - trigger: ":hoy"
          replace: "{{hoy}}"
          vars:
            - name: hoy
              type: date
              params:
                format: "%Y-%m-%d"
      
      • Estos snippets funcionan en cualquier app donde Espanso esté activo (terminal, editor, navegador, etc.).

      La variable date permite generar la fecha en el formato indicado.

      Recargar Espanso para aplicar cambios

      • Después de guardar base.yml, recarga Espanso:
      espanso restart
      

      Si lo tienes como servicio de usuario (systemd), puede ser algo como:

      
      
      
      
      
      systemctl --user restart espanso
      

      según cómo lo instalases en Ubuntu.

    1. 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. 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.


    3. 2.1 – Librerías en Python

      2.1 – Librerías en Python

      ¿Qué es una librería en Python?

      Una librería (o “biblioteca”) es código que alguien ya escribió para resolver un problema común: hacer peticiones web, leer PDFs, crear gráficos, trabajar con fechas, etc.

      • Python estándar: viene “de serie” (por ejemplo json, os, math, datetime).
      • Librerías externas: se instalan aparte (por ejemplo requests, pandas, flask, numpy).

      Regla mental útil:

      • Si lo importas y no lo instalas, normalmente es estándar.
      • Si lo importas y te da error, probablemente hay que instalarlo.

      ¿Qué significa import?

      Cuando haces:

      
      
      
      
      
      import requests
      

      Estás diciendo: “Python, carga ese paquete para que pueda usar sus funciones”.

      También puedes importar cosas concretas:

      
      
      
      
      
      from datetime import datetime
      

      O ponerle un alias (muy común):

      
      
      
      
      
      import pandas as pd
      

      ¿Dónde se instalan librerías?

      En Python, las librerías se instalan en “un Python concreto”, que puede ser:

      1. Python del sistema (global).
      2. Un entorno virtual (recomendado para clase/proyectos).
      3. Una instalación específica (por ejemplo, un Python dentro de VS Code, conda, etc.).

      La confusión típica del alumnado:

      “He instalado requests pero sigue dando error”
      Casi siempre es porque instalaron en un Python y ejecutan con otro.


      Gestores de paquetes: pip

      pip es el instalador estándar de paquetes Python.

      Comandos básicos:

      
      
      
      
      
      pip --version
      python3 -m pip --version
      

      Instalar una librería:

      
      
      
      
      
      python3 -m pip install requests
      

      Actualizar una librería:

      
      
      
      
      
      python3 -m pip install --upgrade requests
      

      Ver lo instalado:

      
      
      
      
      
      python3 -m pip list
      

      Ver información de un paquete:

      
      
      
      
      
      python3 -m pip show requests
      

      La forma “pro” para clase: entornos virtuales (venv)

      Esto evita romper el sistema y hace que cada proyecto tenga sus librerías.

      Crear entorno virtual

      En la carpeta del proyecto:

      
      
      
      
      
      python3 -m venv venv
      

      Activarlo

      Linux/Mac:

      
      
      
      
      
      source venv/bin/activate
      

      Windows (PowerShell):

      
      
      
      
      
      venv\Scripts\Activate.ps1
      

      Windows (CMD):

      
      
      
      
      
      venv\Scripts\activate.bat
      

      Cuando está activo, normalmente verás (venv) al inicio de la terminal.

      Instalar dentro del entorno

      
      
      
      
      
      python -m pip install requests
      

      5.4 Salir del entorno

      
      
      
      
      
      deactivate
      

      Cómo saber si algo es estándar o externo

      Ejemplos:

      • Estándar:
      
      
      
      
      
      import json
      import os
      import datetime
      
      • Externas (requieren pip):
      
      
      
      
      
      import requests
      import pandas
      import flask
      

      Buenas prácticas al trabajar con librerías

      Fijar dependencias: requirements.txt

      Generar lista de dependencias del entorno:

      
      
      
      
      
      python -m pip freeze > requirements.txt
      

      Instalar dependencias en otro equipo:

      
      
      
      
      
      python -m pip install -r requirements.txt
      

      Esto es oro puro para que los proyectos “funcionen igual” en todas las máquinas.

      Leer documentación y “ejemplos mínimos”

      La documentación oficial suele tener:

      • instalación
      • ejemplos pequeños
      • parámetros importantes
      • errores comunes

      Ejemplo completo con requests (GET)

      Vamos a hacer una petición HTTP a una API pública de ejemplo y procesar JSON.

      Instalar requests

      Si estás en venv, mejor.

      
      
      
      
      
      python -m pip install requests
      

      Script: peticion_get.py

      
      
      
      
      
      import requests
      
      URL = "https://httpbin.org/get"
      
      def main():
          try:
              # timeout: evita que el programa se quede colgado si el servidor no responde
              response = requests.get(URL, timeout=10)
      
              # Lanza excepción si el status code es 4xx/5xx
              response.raise_for_status()
      
              # httpbin devuelve JSON
              data = response.json()
      
              print("✅ Status:", response.status_code)
              print("✅ Tu IP según el servidor:", data.get("origin"))
              print("✅ Headers enviados (ejemplo):")
              headers = data.get("headers", {})
              print("   User-Agent:", headers.get("User-Agent"))
      
          except requests.exceptions.Timeout:
              print("⏳ Error: timeout (el servidor tardó demasiado en responder).")
          except requests.exceptions.HTTPError as e:
              print("🚫 Error HTTP:", e)
          except requests.exceptions.RequestException as e:
              # Cubre: problemas de red, DNS, conexión, etc.
              print("🌐 Error de red:", e)
          except ValueError:
              # Si .json() falla porque la respuesta no era JSON
              print("🧩 Error: la respuesta no era JSON válido.")
      
      if __name__ == "__main__":
          main()
      

      Ejecutarlo

      
      
      
      
      
      python peticion_get.py
      

      Qué deberían observar:

      • status_code (200 si ok)
      • origin (la IP “vista” por el servidor)
      • headers (cabeceras HTTP)

      Ejemplo con parámetros (GET con params)

      params construye la query ?clave=valor.

      
      
      
      
      
      import requests
      
      URL = "https://httpbin.org/get"
      
      params = {
          "busqueda": "python",
          "pagina": 1
      }
      
      r = requests.get(URL, params=params, timeout=10)
      print("URL final:", r.url)
      print("Respuesta JSON:", r.json().get("args"))
      

      Ejemplo POST (enviar datos)

      Enviar JSON

      
      
      
      
      
      import requests
      
      URL = "https://httpbin.org/post"
      
      payload = {
          "usuario": "alumno01",
          "rol": "tester"
      }
      
      r = requests.post(URL, json=payload, timeout=10)
      r.raise_for_status()
      
      data = r.json()
      print("Enviado:", data.get("json"))
      

      Enviar formulario (application/x-www-form-urlencoded)

      
      
      
      
      
      import requests
      
      URL = "https://httpbin.org/post"
      
      form_data = {
          "email": "alumno@ejemplo.com",
          "password": "1234"
      }
      
      r = requests.post(URL, data=form_data, timeout=10)
      print(r.json().get("form"))
      

      Cabeceras y autenticación básica

      Cabeceras (headers)

      
      
      
      
      
      import requests
      
      URL = "https://httpbin.org/headers"
      
      headers = {
          "User-Agent": "ClasePython/1.0",
          "X-Profesor": "Antonio"
      }
      
      r = requests.get(URL, headers=headers, timeout=10)
      print(r.json())
      

      Auth básica (solo ejemplo didáctico)

      
      
      
      
      
      import requests
      
      URL = "https://httpbin.org/basic-auth/user/pass"
      r = requests.get(URL, auth=("user", "pass"), timeout=10)
      print(r.status_code, r.json())
      

      Errores típicos (y cómo cazarlos rápido)

      “ModuleNotFoundError: No module named ‘requests’”

      • No está instalado en ese Python.
      • Solución:
      
      
      
      
      
      python -m pip install requests
      python -c "import requests; print(requests.__version__)"
      

      “Funciona en terminal pero no en VS Code”

      • VS Code está usando otro intérprete.
      • Solución: seleccionar el intérprete del venv en VS Code (Python: Select Interpreter).

      “Se queda colgado”

      • Falta timeout.
      • Solución: siempre pon timeout=... en peticiones.

    4. 2.2 – ReconLite (mini escáner OSINT HTTP)

      2.2 – ReconLite (mini escáner OSINT HTTP)

      En este caso vamos a construir paso a paso ReconLite, un mini escáner HTTP orientado a reconocimiento OSINT ligero. No es una herramienta para “atacar”, ni pretende competir con scanners profesionales, sino un proyecto didáctico pensado para entender qué información expone un servicio web antes incluso de hablar de vulnerabilidades.

      ReconLite nace con una idea muy clara: en ciberseguridad, observar bien es más importante que correr rápido. Aprender a mirar cabeceras, códigos de estado, tiempos de respuesta, redirecciones o endpoints típicos permite formarse una primera imagen del objetivo sin romper nada, sin hacer ruido innecesario y, sobre todo, dejando evidencias claras y reproducibles.

      A lo largo del proyecto se trabajan conceptos clave que aparecen constantemente en auditorías reales y análisis forense web: normalización de objetivos, fingerprinting pasivo, revisión de hardening HTTP, enumeración controlada de rutas y generación de reportes estructurados. Todo ello usando Python y la librería requests, sin magia negra y con explicaciones claras de cada decisión tomada en el código.

      El objetivo no es solo que el script funcione, sino que entiendas por qué se hace cada cosa, qué información aporta y cuáles son sus límites. ReconLite está diseñado para fomentar una mentalidad ciber realista:
      mirar sin asumir, registrar sin interpretar de más y recordar siempre que un 200 no significa “seguro”, ni un 403 significa “no existe”.

      A partir de aquí encontrarás la estructura completa del proyecto, el código íntegro y una explicación detallada de cada parte, para que puedas usarlo, modificarlo y ampliarlo como base para prácticas, laboratorios o proyectos más avanzados.

      Qué hace:

      • Valida y normaliza una URL objetivo
      • Descubre endpoints típicos (con un wordlist pequeño)
      • Revisa cabeceras de seguridad (CSP, HSTS, etc.)
      • Detecta tecnologías básicas por headers (sin magia negra)
      • Comprueba robots.txt y sitemap.xml
      • Mide tiempos y códigos de estado
      • Saca un reporte en JSON

      Mentalidad ciber: “mirar sin romper”, registrar evidencias, y no asumir que “200 = seguro” ni que “403 = no existe”.


      Estructura

      Crea esta carpeta:

      • reconlite/
        • reconlite.py
        • requirements.txt
        • README.md
        • report.json (se genera)

      requirements.txt

      
      
      
      
      
      requests>=2.31.0
      

      reconlite.py (proyecto completo)

      
      
      
      
      
      #!/usr/bin/env python3
      import argparse
      import json
      import re
      import sys
      import time
      from urllib.parse import urljoin, urlparse
      
      import requests
      
      
      DEFAULT_PATHS = [
          "/", "/robots.txt", "/sitemap.xml",
          "/.git/", "/.env", "/config.php", "/phpinfo.php",
          "/admin", "/admin/", "/login", "/login/",
          "/wp-admin", "/wp-login.php",
          "/api", "/api/", "/swagger", "/swagger/", "/openapi.json",
          "/server-status", "/actuator", "/actuator/health"
      ]
      
      SEC_HEADERS = [
          "Strict-Transport-Security",
          "Content-Security-Policy",
          "X-Content-Type-Options",
          "X-Frame-Options",
          "Referrer-Policy",
          "Permissions-Policy",
          "Cross-Origin-Opener-Policy",
          "Cross-Origin-Resource-Policy",
          "Cross-Origin-Embedder-Policy",
      ]
      
      
      def normalize_url(raw: str) -> str:
          raw = raw.strip()
          if not raw:
              raise ValueError("URL vacía.")
          if not re.match(r"^https?://", raw, re.IGNORECASE):
              raw = "https://" + raw  # por defecto https
          u = urlparse(raw)
          if not u.netloc:
              raise ValueError("URL inválida. Ejemplo: https://example.com")
          # reconstrucción limpia (sin fragmentos)
          clean = f"{u.scheme}://{u.netloc}"
          if u.path and u.path != "/":
              clean += u.path.rstrip("/")
          return clean
      
      
      def safe_request(session: requests.Session, method: str, url: str, **kwargs):
          t0 = time.time()
          try:
              r = session.request(method, url, **kwargs)
              dt = (time.time() - t0) * 1000.0
              return r, dt, None
          except requests.RequestException as e:
              dt = (time.time() - t0) * 1000.0
              return None, dt, str(e)
      
      
      def extract_basic_fingerprint(headers: dict) -> dict:
          # Fingerprinting suave: headers típicos (no infalible)
          server = headers.get("Server")
          powered = headers.get("X-Powered-By")
          via = headers.get("Via")
          return {
              "server": server,
              "x_powered_by": powered,
              "via": via,
          }
      
      
      def analyze_security_headers(headers: dict) -> dict:
          present = {}
          missing = []
          for h in SEC_HEADERS:
              if h in headers:
                  present[h] = headers.get(h)
              else:
                  missing.append(h)
      
          # Heurísticas sencillas (no dogma)
          notes = []
          if "Strict-Transport-Security" not in headers:
              notes.append("No HSTS: si es un sitio web público, se suele recomendar forzar HTTPS con HSTS.")
          if headers.get("X-Content-Type-Options", "").lower() != "nosniff":
              notes.append("X-Content-Type-Options no es 'nosniff' (o falta).")
          if "Content-Security-Policy" not in headers:
              notes.append("Sin CSP: suele reducir impacto de XSS (no lo elimina).")
      
          return {"present": present, "missing": missing, "notes": notes}
      
      
      def is_interesting_status(code: int) -> bool:
          # 200/204/3xx/401/403 son “interesantes” para enumeración
          return code in (200, 201, 202, 204, 301, 302, 307, 308, 401, 403)
      
      
      def scan_paths(base_url: str, paths: list, timeout: int, verify_tls: bool, user_agent: str, max_paths: int):
          session = requests.Session()
          session.headers.update({"User-Agent": user_agent})
      
          results = []
          for i, p in enumerate(paths[:max_paths], start=1):
              full = urljoin(base_url + "/", p.lstrip("/"))
              r, dt, err = safe_request(
                  session,
                  "GET",
                  full,
                  timeout=timeout,
                  allow_redirects=False,
                  verify=verify_tls,
              )
      
              entry = {
                  "path": p,
                  "url": full,
                  "error": err,
                  "ms": round(dt, 2),
              }
      
              if r is not None:
                  entry.update({
                      "status": r.status_code,
                      "content_type": r.headers.get("Content-Type"),
                      "content_length": r.headers.get("Content-Length"),
                      "location": r.headers.get("Location"),
                  })
      
                  # Guardamos solo “señales”, no el contenido entero (más limpio y ético)
                  if is_interesting_status(r.status_code):
                      results.append(entry)
              else:
                  # errores de red también son evidencia
                  results.append(entry)
      
          return results
      
      
      def head_base(base_url: str, timeout: int, verify_tls: bool, user_agent: str):
          session = requests.Session()
          session.headers.update({"User-Agent": user_agent})
      
          r, dt, err = safe_request(
              session,
              "HEAD",
              base_url,
              timeout=timeout,
              allow_redirects=False,
              verify=verify_tls,
          )
      
          if r is None:
              return {"error": err, "ms": round(dt, 2)}
      
          return {
              "status": r.status_code,
              "ms": round(dt, 2),
              "headers": dict(r.headers),
          }
      
      
      def main():
          parser = argparse.ArgumentParser(
              description="ReconLite - Recon HTTP/OSINT ligero con mentalidad ciber (solo objetivos autorizados)."
          )
          parser.add_argument("target", help="URL o dominio (ej: https://example.com o example.com)")
          parser.add_argument("--timeout", type=int, default=8, help="Timeout por request en segundos (default: 8)")
          parser.add_argument("--insecure", action="store_true", help="No verificar TLS (NO recomendado)")
          parser.add_argument("--max-paths", type=int, default=40, help="Máximo de rutas a probar (default: 40)")
          parser.add_argument("--paths-file", help="Archivo de rutas (una por línea) para enumeración")
          parser.add_argument("--out", default="report.json", help="Ruta del reporte JSON (default: report.json)")
          parser.add_argument("--ua", default="ReconLite/1.0 (+educational)", help="User-Agent personalizado")
      
          args = parser.parse_args()
      
          try:
              base_url = normalize_url(args.target)
          except ValueError as e:
              print(f"[!] {e}", file=sys.stderr)
              sys.exit(1)
      
          verify_tls = not args.insecure
      
          paths = DEFAULT_PATHS
          if args.paths_file:
              try:
                  with open(args.paths_file, "r", encoding="utf-8") as f:
                      custom = [line.strip() for line in f if line.strip() and not line.strip().startswith("#")]
                  # Normaliza para que siempre empiecen por "/"
                  paths = [p if p.startswith("/") else "/" + p for p in custom]
              except OSError as e:
                  print(f"[!] No se pudo leer paths-file: {e}", file=sys.stderr)
                  sys.exit(1)
      
          report = {
              "target": base_url,
              "timestamp_utc": time.strftime("%Y-%m-%dT%H:%M:%SZ", time.gmtime()),
              "config": {
                  "timeout_s": args.timeout,
                  "verify_tls": verify_tls,
                  "max_paths": args.max_paths,
                  "user_agent": args.ua,
              },
              "base_head": {},
              "fingerprint": {},
              "security_headers": {},
              "findings": [],
          }
      
          # 1) HEAD base
          base_head = head_base(base_url, args.timeout, verify_tls, args.ua)
          report["base_head"] = base_head
      
          if "headers" in base_head:
              headers = base_head["headers"]
              report["fingerprint"] = extract_basic_fingerprint(headers)
              report["security_headers"] = analyze_security_headers(headers)
      
          # 2) Enumeración de rutas
          findings = scan_paths(base_url, paths, args.timeout, verify_tls, args.ua, args.max_paths)
          report["findings"] = findings
      
          # 3) Guardar reporte
          try:
              with open(args.out, "w", encoding="utf-8") as f:
                  json.dump(report, f, indent=2, ensure_ascii=False)
          except OSError as e:
              print(f"[!] No se pudo escribir el reporte: {e}", file=sys.stderr)
              sys.exit(1)
      
          # Resumen consola
          interesting = [x for x in findings if x.get("status") is not None]
          print(f"✅ Objetivo: {base_url}")
          if "status" in base_head:
              print(f"✅ HEAD status: {base_head['status']} ({base_head['ms']} ms)")
          print(f"✅ Hallazgos guardados en: {args.out}")
          print(f"✅ Endpoints interesantes (con status): {len(interesting)}")
      
      
      if __name__ == "__main__":
          main()
      

      README.md

      README.md 
      # ReconLite (proyecto resuelto) – Python + requests con mentalidad ciber

      ## Objetivo
      Hacer reconocimiento HTTP/OSINT de forma ligera y responsable:
      - Cabeceras de seguridad (HSTS, CSP, etc.)
      - Fingerprinting básico por headers
      - Enumeración “suave” de rutas típicas
      - Reporte JSON para evidencias

      > Úsalo solo contra objetivos autorizados.

      ## Instalación
      ```bash
      python3 -m venv venv
      source venv/bin/activate
      pip install -r requirements.txt
      ```

      ## Uso básico
      ```bash
      python reconlite.py https://example.com
      ```

      ## Cambiar User-Agent
      ```bash
      python reconlite.py example.com --ua "Mozilla/5.0 (ReconLite class)"
      ```

      ## Añadir tu propio wordlist de rutas
      Archivo `paths.txt` (una ruta por línea):
      ```
      admin
      admin/
      robots.txt
      api/v1
      ```

      Ejecución:
      ```bash
      python reconlite.py https://midominio.com --paths-file paths.txt --max-paths 200
      ```

      ## TLS
      Por defecto verifica TLS.
      Si estás en laboratorio con certificados raros (NO recomendado):
      ```bash
      python reconlite.py https://lab.local --insecure
      ```

      ## Salida
      Genera `report.json` con:
      - Config usada
      - HEAD base con headers
      - Seguridad de headers
      - Listado de rutas con status, tiempos, redirects y content-type
      ```

      ---

      ## Ejemplos de ejecución (para clase)
      ~~~bash
      # 1) Recon rápido
      python reconlite.py https://testphp.vulnweb.com

      # 2) Enumeración más grande con tu lista
      python reconlite.py https://testphp.vulnweb.com --paths-file paths.txt --max-paths 150

      # 3) Cambiar timeout (objetivos lentos)
      python reconlite.py https://testphp.vulnweb.com --timeout 15

      Aqhí tienes todos los archivos del proyecto para que puedas usarlos.

      Métodos comentados

      normalize_url(raw: str) -> str

      Propósito: convertir lo que te pase el usuario (example.com, http://..., https://.../algo) en una URL base “limpia” y usable.

      Qué hace paso a paso:

      • raw.strip() limpia espacios (entrada típica de alumno: " example.com ").
      • Si está vacío → ValueError. Evita que luego requests reviente con errores menos claros.
      • Si no empieza por http:// o https://, le añade https:// por defecto.
        • Mentalidad ciber: preferir TLS. Si el sitio no soporta HTTPS, ya verás error/redirect.
      • urlparse(raw) separa esquema, host, path, etc.
      • Si no hay netloc (host) → URL inválida.
      • Reconstruye una URL “limpia” sin fragmentos y con path normalizado.

      Por qué es importante en ciber:

      • Un recon decente empieza por normalizar objetivos. Evitas escanear accidentalmente https://https://... o rutas raras.

      Limitaciones:

      • No valida DNS ni conectividad; solo sintaxis.
      • No fuerza www ni detecta canonical URL.

      Mejoras típicas:

      • Permitir http por defecto si https falla (con aviso).
      • Bloquear esquemas raros aunque vengan “inyectados”.

      safe_request(session, method, url, **kwargs)

      Propósito: envoltorio robusto alrededor de requests para:

      • medir tiempo
      • capturar errores de red
      • devolver siempre un resultado uniforme

      Qué hace:

      • Arranca cronómetro (t0 = time.time()).
      • Intenta session.request(...) con método, URL y parámetros.
      • Si va bien → devuelve (response, ms, None).
      • Si falla (timeout, DNS, TLS, conexión, etc.) → devuelve (None, ms, "error string").

      Por qué es importante en ciber:

      • En recon real, los fallos son evidencia: “no resuelve”, “TLS handshake falla”, “timeout”… eso te dice cosas del perímetro.

      Limitaciones:

      • Devuelve str(e) sin clasificar error (timeout vs ssl vs conn).

      Mejoras:

      • Clasificar excepciones (Timeout, SSLError, ConnectionError) en un campo error_type.
      • Añadir reintentos con backoff (con cuidado de no hacer ruido).

      extract_basic_fingerprint(headers: dict) -> dict

      Propósito: fingerprinting básico y ético: mirar lo que el servidor declara en headers.

      Qué hace:

      • Lee Server, X-Powered-By, Via.
      • Devuelve un dict con esos valores.

      Por qué es ciber:

      • Esto a veces revela stack (“nginx”, “Apache”, “Express”, “PHP”, “cloudflare”, proxies…).
      • Es “OSINT pasivo” dentro de una request normal.

      Limitaciones (muy importantes):

      • No es fiable: muchos servidores mienten o lo ocultan.
      • No debe tomarse como prueba definitiva.

      Mejoras:

      • Añadir heurísticas con Set-Cookie, X-AspNet-Version, CF-RAY, etc.
      • Detectar CDN/WAF con señales comunes (pero siempre como “posible”).

      analyze_security_headers(headers: dict) -> dict

      Propósito: comprobar presencia/ausencia de headers de seguridad y generar notas.

      Qué hace:

      • Recorre SEC_HEADERS:
        • Si está presente → lo guarda con su valor.
        • Si falta → lo añade a missing.
      • Genera notes con heurísticas:
        • falta HSTS
        • X-Content-Type-Options no es nosniff
        • falta CSP

      Por qué es ciber:

      • Esto te da un “termómetro” rápido de hardening HTTP.
      • Útil para que alumnos aprendan que seguridad también es config.

      Limitaciones:

      • Que falte un header ≠ vulnerabilidad explotable.
      • CSP/HSTS requieren contexto (subdominios, preload, mixed content).

      Mejoras:

      • Analizar valores:
        • HSTS: max-age, includeSubDomains, preload
        • XFO: DENY/SAMEORIGIN
        • CSP: evitar unsafe-inline (ojo: no siempre posible)
      • Añadir chequeo de Secure/HttpOnly/SameSite en cookies (si haces GET real y hay cookies).

      is_interesting_status(code: int) -> bool

      Propósito: decidir qué códigos son “interesantes” para enumeración sin guardar ruido.

      Qué hace:

      • Devuelve True si status ∈ {200, 201, 202, 204, 301, 302, 307, 308, 401, 403}

      Por qué es ciber:

      • 401/403 son oro: “existe pero protegido”.
      • 3xx también: revela rutas canonical o paneles movidos.

      Limitaciones:

      • 404 también puede ser interesante si detectas “soft 404” (200 con página de error).
      • 500/502/503 deberían contarse como hallazgo porque indican superficie frágil.

      Mejoras:

      • Permitir configurar lista de códigos por CLI.
      • Detectar “soft 404” comparando longitud/huella de respuesta.

      scan_paths(base_url, paths, timeout, verify_tls, user_agent, max_paths)

      Propósito: enumeración “suave” de endpoints típicos con GET sin seguir redirecciones.

      Qué hace:

      • Crea requests.Session() (mejor que requests.get repetido):
        • Reutiliza conexión (keep-alive) → más rápido, menos carga.
      • Fija User-Agent.
      • Recorre rutas hasta max_paths.
      • Construye URL final con urljoin.
      • Llama safe_request(GET, ...) con:
        • allow_redirects=False (clave para recon: quieres ver el Location)
        • verify=verify_tls
        • timeout=timeout
      • Crea entry con datos:
        • path, url, error, ms
      • Si hay respuesta:
        • status, content-type, content-length, location
        • Si status es “interesante” → lo añade
      • Si hay error:
        • también lo añade (evidencia)

      Por qué es ciber:

      • Enumeración controlada, orientada a reporte.
      • No seguir redirects evita perder información y evita cadenas largas.

      Limitaciones / ética:

      • Un wordlist grande puede parecer “escaneo agresivo”.
      • No hay rate-limit → en un entorno real debes dormir entre requests.

      Mejoras pro:

      • Añadir --delay-ms o --rps para no hacer ruido.
      • Añadir método HEAD para paths (menos transferencia) y usar GET solo si “promete”.
      • Añadir comparación de contenido para detectar páginas trampa.

      head_base(base_url, timeout, verify_tls, user_agent)

      Propósito: obtener headers del objetivo base con HEAD (ligero).

      Qué hace:

      • Crea sesión, pone UA.
      • Llama safe_request("HEAD", base_url, allow_redirects=False, ...)
      • Si falla → devuelve dict con error y ms.
      • Si va bien → devuelve status, ms, headers.

      Por qué es ciber:

      • Minimiza impacto: HEAD normalmente no descarga cuerpo.
      • Buen punto de partida para fingerprint y seguridad headers.

      Limitaciones:

      • Algunos servidores no implementan HEAD bien:
        • responden distinto que GET
        • devuelven 405 Method Not Allowed
      • Si hay WAF/CDN, puede variar por método.

      Mejoras:

      • Si HEAD da 405 → fallback a GET con stream=True y sin leer cuerpo (o leyendo muy poco).

      main()

      Propósito: orquestar todo: argumentos, normalización, ejecutar recon, guardar reporte, resumen por consola.

      Qué hace:

      1. argparse define CLI:
        • target, timeout, insecure, max-paths, paths-file, out, ua
      2. Normaliza URL (si falla, sale con error claro).
      3. verify_tls = not args.insecure
      4. Carga paths:
        • si hay --paths-file, lo lee y normaliza cada ruta a /...
      5. Inicializa report:
        • target, timestamp_utc, config, base_head, fingerprint, security_headers, findings
      6. Llama head_base
        • si trae headers → fingerprint + security header analysis
      7. Llama scan_paths
      8. Guarda JSON en args.out
      9. Imprime resumen

      Por qué es ciber:

      • Deja un rastro reproducible: configuración + timestamp + evidencias.
      • Separa “descubrimiento” (head) de “enumeración” (paths).

      Limitaciones:

      • No hay control de concurrencia ni rate limit.
      • No hay logging estructurado (solo print final).

      Mejoras:

      • Añadir niveles de verbosidad -v / -vv.
      • Exportar también a Markdown (bonito para entregar como informe).
      • Añadir “modo aula”: limitar a X requests por minuto.

      if __name__ == "__main__": main()

      Propósito: permitir que el script funcione:

      • como programa ejecutable (CLI)
      • y también importable como módulo sin ejecutarse automáticamente

      • Puedes reutilizar funciones en otro fichero (tests, GUI, etc.).
    5. 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

    6. 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: