OpenSSL en Kali Linux: Guía Esencial

https://www.onlinetis.com/es/

OpenSSL en Kali Linux: Guía Esencial

OpenSSL es una herramienta fundamental en Kali Linux para todo lo relacionado con criptografía, desde generar certificados SSL/TLS hasta cifrar archivos o probar la seguridad de un servidor.

Aquí tienes una guía rápida de lo más esencial para dominarlo en español.

Comandos básicos de OpenSSL

OpenSSL funciona mediante subcomandos. La estructura general es:

openssl [comando] [opciones]

1. Gestión de Certificados y Claves

Es el uso más común, especialmente para configurar servidores web o realizar ataques de Man-in-the-Middle en entornos de prueba.

Generar una clave privada RSA de 2048 bits:
openssl genrsa -out privada.key 2048
Crear una solicitud de firma de certificado (CSR):
openssl req -new -key privada.key -out solicitud.csr
Generar un certificado autofirmado (válido por 365 días):
openssl x509 -req -days 365 -in solicitud.csr -signkey privada.key -out certificado.crt

2. Cifrado de archivos

Si quieres proteger un archivo localmente antes de enviarlo o guardarlo:

Cifrar un archivo (usando AES-256):
openssl enc -aes-256-cbc -salt -in secreto.txt -out secreto.txt.enc
Descifrar el archivo:
openssl enc -d -aes-256-cbc -in secreto.txt.enc -out secreto_descifrado.txt

3. Verificación de servidores remotos

Como herramienta de diagnóstico en Kali, puedes conectarte a un servidor para ver su certificado y configuración TLS:

Conectarse a un sitio web:
openssl s_client -connect google.com:443
Esto te mostrará toda la cadena de certificados y el cifrado que se está utilizando actualmente.

¿Por qué es vital en Kali Linux?

En el mundo de la ciberseguridad, OpenSSL se utiliza para:

Auditoría de protocolos: Identificar si un servidor usa versiones vulnerables como SSLv2 o SSLv3.
Extracción de hashes: Puedes ver el hash de un archivo con openssl dgst -sha256 archivo.txt.
Análisis de vulnerabilidades: Muchos exploits (como el famoso Heartbleed) se basan en debilidades de bibliotecas OpenSSL desactualizadas.

Un pequeño consejo de "hacker"

Si alguna vez olvidas un comando, recuerda que Kali tiene los manuales integrados. Solo escribe:

man openssl

Vamos a crear un certificado para un servidor local (como Apache o Nginx) en un solo paso.

Para pruebas de seguridad o desarrollo en Kali Linux, lo más práctico es generar un certificado autofirmado. Esto significa que tu navegador mostrará una advertencia de "Sitio no seguro" (porque no lo firma una autoridad oficial como Let's Encrypt), pero la conexión entre tú y el servidor estará cifrada.

Generación rápida (Todo en uno)

Ejecuta este comando en tu terminal para generar la clave privada y el certificado al mismo tiempo:

Bash

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout mi_servidor.key -out mi_servidor.crt

¿Qué hace cada parte del comando?

Parámetro	Función
`-x509`	Indica que queremos un certificado autofirmado en lugar de una solicitud (CSR).
`-nodes`	(No Des) Evita que la clave privada se proteja con contraseña. Útil para que el servidor arranque solo sin pedirte clave.
`-days 365`	El certificado será válido por un año.
`-newkey rsa:2048`	Genera una nueva clave RSA de 2048 bits simultáneamente.
`-keyout`	El nombre del archivo de la clave privada (guárdalo con celo).
`-out`	El nombre del archivo del certificado público.

Configuración en el servidor

Una vez tengas tus archivos mi_servidor.crt y mi_servidor.key, debes indicarle a tu servidor dónde están:

En Apache: Busca las líneas SSLCertificateFile y SSLCertificateKeyFile en tu archivo de configuración (/etc/apache2/sites-available/default-ssl.conf).
En Nginx: Usa las directivas ssl_certificate y ssl_certificate_key dentro del bloque server.

Nota de seguridad: Asegúrate de que los permisos de la clave privada sean restrictivos. Ejecuta chmod 600 mi_servidor.key para que solo tu usuario pueda leerla.

Vamos con un ejemplo para Nginx, que es el más común hoy en día por su ligereza y facilidad de configuración en entornos de pruebas con Kali.

Aquí tienes un bloque de configuración básico que puedes usar como plantilla.

Ejemplo de Configuración para Nginx

Crea o edita un archivo en /etc/nginx/sites-available/mi_sitio (o el nombre que prefieras) y pega lo siguiente:

Nginx
server {
    listen 443 ssl;
    server_name localhost;

    # Rutas a los archivos que generamos antes
    ssl_certificate     /etc/nginx/ssl/mi_servidor.crt;
    ssl_certificate_key /etc/nginx/ssl/mi_servidor.key;

    # Configuraciones de seguridad recomendadas
    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_ciphers         HIGH:!aNULL:!MD5;

    root /var/www/html;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

Pasos para que funcione en tu Kali Linux

Crea la carpeta y mueve los archivos:

Bash

sudo mkdir -p /etc/nginx/ssl
sudo mv mi_servidor.crt /etc/nginx/ssl/
sudo mv mi_servidor.key /etc/nginx/ssl/

Asegura los permisos:

Bash

sudo chmod 600 /etc/nginx/ssl/mi_servidor.key

Activa el sitio y reinicia Nginx:

Bash
# Si creaste el archivo en sites-available, crea el enlace simbólico
sudo ln -s /etc/nginx/sites-available/mi_sitio /etc/nginx/sites-enabled/

# Verifica que no haya errores de sintaxis
sudo nginx -t

# Reinicia el servicio
sudo systemctl restart nginx

Un toque de teoría: ¿Por qué TLSv1.2 y TLSv1.3?

En el bloque de arriba incluí ssl_protocols TLSv1.2 TLSv1.3;. Esto es porque las versiones anteriores ( $SSLv3$ , $TLSv1.0$ , $TLSv1.1$ ) se consideran inseguras hoy en día debido a vulnerabilidades como POODLE o BEAST. Como estás en Kali, ¡es genial aprender configurando de forma segura desde el principio!

Esta es una de las habilidades más útiles en el arsenal de cualquier usuario de Kali Linux. Usar openssl s_client te permite "hablar" directamente con el puerto SSL/TLS sin necesidad de un navegador, lo que es ideal para auditorías rápidas.

Ejecuta el siguiente comando para verificar tu servidor local (o cualquier sitio web):

Bash

openssl s_client -connect localhost:443 -showcerts

¿Qué debes observar en la salida?

Al ejecutarlo, verás una gran cantidad de texto técnico. Aquí te explico en qué fijarte:

La Cadena de Certificados (Certificate chain):
Verás algo como s:/CN=localhost (el sujeto) y i:/CN=localhost (el emisor). Al ser un certificado autofirmado, el emisor y el sujeto serán el mismo.
El Protocolo y Cifrado (SSL-Session):
Busca la línea que dice Protocol. Si configuraste Nginx correctamente como hicimos antes, debería decir TLSv1.2 o TLSv1.3.
- Cipher: Te dirá el algoritmo exacto (ej. AES256-GCM-SHA384).
Estado de Verificación:
Al final verás Verification error: self-signed certificate. ¡No te asustes! Esto confirma que tu certificado funciona, pero que OpenSSL (con razón) no confía en él porque tú mismo lo firmaste.

Visualizando el Handshake (Apretón de manos)

Para entender qué está pasando "bajo el capó" cuando lanzas ese comando, aquí tienes el proceso:

Client Hello: Tu comando s_client envía las versiones de TLS que soporta.
Server Hello: Nginx responde con el certificado (mi_servidor.crt) y elige el cifrado más seguro.
Claves: Se intercambian parámetros para generar una clave de sesión única.
Cifrado: A partir de ahí, todos los datos viajan protegidos.

Un truco extra para Kali

Si quieres extraer solo la fecha de expiración de un sitio (muy útil para reportes de auditoría), puedes combinar comandos:

Bash

echo | openssl s_client -connect google.com:443 2>/dev/null | openssl x509 -noout -dates

¡Esta es la técnica "pro"! Crear tu propia Autoridad Certificadora (CA) personal te permite firmar tus propios certificados y luego instalar tu "Certificado Raíz" en tu navegador (Chrome, Firefox) o en tu sistema operativo.

Una vez hecho esto, cualquier certificado que firmes con tu CA aparecerá con el candado verde (o gris, según el navegador) y sin advertencias de seguridad en tu red local.

Paso 1: Crear tu propia Autoridad Certificadora (CA)

Primero, generamos una clave privada para tu CA y su certificado raíz. Este es el "sello" que validará todo lo demás.

Generar la clave de la CA:
openssl genrsa -des3 -out mi_ca.key 2048
(Te pedirá una contraseña, elígela bien y no la olvides).
Generar el certificado raíz de la CA:
openssl req -x509 -new -nodes -key mi_ca.key -sha256 -days 1825 -out mi_ca.pem
Aquí, en "Common Name", pon algo como "Mi Laboratorio de Kali".

Paso 2: Crear un certificado firmado por tu CA

Ahora, en lugar de un certificado "autofirmado" normal, haremos uno que dependa de tu CA.

Generar la clave del servidor:
openssl genrsa -out servidor_local.key 2048
Generar la solicitud (CSR):
openssl req -new -key servidor_local.key -out servidor_local.csr
Importante: En Common Name, pon la IP de tu Kali o localhost.

Firmar el certificado con tu CA:

Bash

openssl x509 -req -in servidor_local.csr -CA mi_ca.pem -CAkey mi_ca.key -CAcreateserial -out servidor_local.crt -days 825 -sha256

Paso 3: Cómo hacer que tu navegador confíe

Para que el truco funcione, debes decirle a tu equipo que confíe en mi_ca.pem:

En Firefox: Ajustes -> Privacidad y Seguridad -> Certificados -> Ver certificados -> Importar (pestaña Autoridades). Selecciona mi_ca.pem.
En Chrome/Edge: Configuración -> Seguridad -> Gestionar certificados -> Autoridades -> Importar.

En Kali (Sistema):

Bash

sudo cp mi_ca.pem /usr/local/share/ca-certificates/mi_ca.crt
sudo update-ca-certificates

La jerarquía de confianza

Lo que acabas de construir es una Cadena de Confianza. Tu navegador ahora dice: "No conozco este sitio, pero confío en 'Mi Laboratorio de Kali', y como él dice que este sitio es seguro, yo le creo".

¿Qué quieres intentar ahora?

Es común que al hacer esto con IPs locales (como 127.0.0.1), los navegadores modernos sigan quejándose si no incluyes algo llamado SAN (Subject Alternative Name).

¡Este es el toque final para que un certificado sea 100% profesional!

Los navegadores modernos (como Chrome y Firefox) ya no se conforman con el campo "Common Name" (CN). Ahora exigen obligatoriamente el SAN (Subject Alternative Name). Si no lo incluyes, verás un error de "Nombre de dominio no coincide", incluso si el certificado es válido.

Para hacerlo bien, necesitamos un pequeño archivo de configuración auxiliar.

1. Crea el archivo de extensiones

Crea un archivo llamado san.cnf en tu carpeta de trabajo con este contenido:

Ini, TOML
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names

[alt_names]
DNS.1 = localhost
DNS.2 = kalilab.local
IP.1 = 127.0.0.1
IP.2 = 192.168.1.50  # Pon aquí la IP real de tu máquina Kali

2. Firma el certificado usando ese archivo

Ahora, usa tu CA (la que creamos en el paso anterior) para firmar la solicitud (CSR), pero esta vez inyectando las extensiones SAN:

Bash

openssl x509 -req -in servidor_local.csr -CA mi_ca.pem -CAkey mi_ca.key \
-CAcreateserial -out servidor_local.crt -days 825 -sha256 -extfile san.cnf

¿Por qué es mejor así?

Multidominio: Puedes añadir tantas líneas DNS.x o IP.x como quieras.
Compatibilidad Total: Chrome dejará de mostrar el error de "Sujeto inválido".
Entorno Real: Así es como se configuran los certificados en empresas reales (Intranets).

Resumen de tu "Laboratorio de Criptografía" en Kali

A estas alturas ya tienes:

Tu propia Autoridad (CA): El poder de validar cualquier sitio en tu red.
Claves Privadas: Generadas con RSA de 2048 bits.
Certificados Modernos: Con soporte para SAN e IPs específicas.
Servidor Seguro: Nginx configurado para usar TLSv1.2/1.3.

Un último consejo de seguridad

En el mundo real, la clave mi_ca.key es el "Santo Grial". Si alguien la roba, puede suplantar cualquier identidad en tu red. Por eso, en entornos de producción, esa clave se guarda en dispositivos físicos desconectados (Air-gapped).

Un script en Bash es la mejor forma de no tener que recordar todos estos comandos cada vez que necesites un certificado nuevo.

He diseñado este script para que sea "todo en uno": crea la CA (si no existe), genera la clave del servidor, el CSR y el certificado con SAN automáticamente.

El Script: `generar_ssl.sh`

Crea un archivo llamado generar_ssl.sh en tu Kali y pega este código:

Bash
#!/bin/bash

# Configuración básica
DOMINIO="localhost"
IP="127.0.0.1"
CA_KEY="mi_ca.key"
CA_CERT="mi_ca.pem"

echo "--- 🛡️ Generador de Certificados SAN para Kali Linux ---"

# 1. Crear CA si no existe
if [ ! -f $CA_CERT ]; then
    echo "[+] Generando Autoridad Certificadora (CA)..."
    openssl genrsa -out $CA_KEY 2048
    openssl req -x509 -new -nodes -key $CA_KEY -sha256 -days 1825 -out $CA_CERT -subj "/CN=Mi-Kali-CA"
fi

# 2. Generar Clave Privada del Servidor
echo "[+] Generando clave privada para el servidor..."
openssl genrsa -out servidor.key 2048

# 3. Generar CSR (Solicitud)
echo "[+] Creando solicitud de firma (CSR)..."
openssl req -new -key servidor.key -out servidor.csr -subj "/CN=$DOMINIO"

# 4. Crear archivo de extensión SAN al vuelo
echo "[+] Configurando extensiones SAN para $DOMINIO e IP $IP..."
cat > san.ext << EOF
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = $DOMINIO
IP.1 = $IP
EOF

# 5. Firmar el certificado con la CA
echo "[+] Firmando el certificado final..."
openssl x509 -req -in servidor.csr -CA $CA_CERT -CAkey $CA_KEY \
-CAcreateserial -out servidor.crt -days 825 -sha256 -extfile san.ext

# Limpieza
rm servidor.csr san.ext

echo "--- ✅ ¡Listo! ---"
echo "Certificado: servidor.crt"
echo "Clave:       servidor.key"
echo "Root CA:     $CA_CERT (Importa este en tu navegador)"

Cómo usarlo en tu terminal

Dale permisos de ejecución:
Bash
```
chmod +x generar_ssl.sh
```
Ejecútalo:
Bash
```
./generar_ssl.sh
```

¿Qué acabas de automatizar?

El script maneja la arquitectura de Infraestructura de Clave Pública (PKI) de manera simplificada. Al ejecutarlo, estás creando una jerarquía donde tu CA está en la cima.

Próximos pasos recomendados

Personalización: Puedes cambiar las variables DOMINIO e IP al principio del script si quieres usarlo para otros dispositivos en tu red (como un Raspberry Pi o una máquina víctima en tu laboratorio).
Seguridad: Recuerda que mi_ca.key es el archivo más sensible. Si este script fuera para producción, la clave de la CA debería estar protegida con una frase de paso (parámetro -des3).

Configurar Apache en Kali para usar tus nuevos certificados es un poco diferente a Nginx, ya que Apache utiliza "módulos" que deben activarse manualmente.

Aquí tienes los pasos exactos para dejar tu servidor Apache funcionando con HTTPS y tus archivos servidor.crt y servidor.key.

1. Preparar los archivos

Primero, movamos los archivos generados por tu script a las rutas estándar de Apache para mantener el orden:

Bash

sudo cp servidor.crt /etc/ssl/certs/servidor.crt
sudo cp servidor.key /etc/ssl/private/servidor.key

2. Crear el archivo de configuración (Virtual Host)

En Apache, las configuraciones de sitios se guardan en /etc/apache2/sites-available/. Vamos a crear uno nuevo llamado mi-sitio-ssl.conf:

Bash

sudo nano /etc/apache2/sites-available/mi-sitio-ssl.conf

Pega este contenido dentro del archivo:

Apache
<VirtualHost *:443>
    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/html

    ServerName localhost

    # Activación de SSL
    SSLEngine on

    # Rutas a tus certificados
    SSLCertificateFile    /etc/ssl/certs/servidor.crt
    SSLCertificateKeyFile /etc/ssl/private/servidor.key

    # Configuración de logs
    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

    <Directory /var/www/html>
        Options Indexes FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>

3. Activar módulos y el sitio

A diferencia de otras distros, en Kali/Debian usamos comandos específicos (a2enmod y a2ensite):

Activar el módulo SSL:
sudo a2enmod ssl
Activar tu nuevo sitio:
sudo a2ensite mi-sitio-ssl.conf
Reiniciar Apache para aplicar cambios:
sudo systemctl restart apache2

Cómo verificar que todo está "OK"

Ahora que Apache está corriendo, puedes probar la seguridad de tu configuración desde la terminal de Kali con un solo comando:

openssl s_client -connect localhost:443 -brief

El parámetro -brief te dará un resumen limpio confirmando que la conexión se estableció, el cifrado usado y si el certificado fue aceptado.

Un truco de "Hardening" (Fortalecimiento)

Si quieres que tu servidor sea aún más seguro y obtenga una mejor calificación en pruebas de auditoría, puedes desactivar protocolos viejos editando el archivo /etc/apache2/mods-available/ssl.conf y asegurándote de que esta línea esté así:

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1

Esto obliga a Apache a usar solo TLS 1.2 o superior.

Esta es la mejor práctica de seguridad: nunca dejar el puerto 80 (HTTP) abierto sin protección. Queremos que si alguien escribe http://tu-ip, el servidor lo mande automáticamente a https://tu-ip.

En Apache, esto se hace con una redirección 301 (permanente).

1. Configurar la redirección en el sitio por defecto

Debemos editar el archivo que escucha en el puerto 80. Normalmente es /etc/apache2/sites-available/000-default.conf.

Abre el archivo:
sudo nano /etc/apache2/sites-available/000-default.conf
Borra todo el contenido y pega esto (es mucho más limpio):

Apache
<VirtualHost *:80>
    ServerName localhost
    # Redirige todo el tráfico a HTTPS
    Redirect permanent / https://localhost/
</VirtualHost>

2. Activar el motor de redirección

Para que Apache entienda las reglas de reescritura y redirección, necesitamos activar el módulo rewrite:

Activar módulo:
sudo a2enmod rewrite
Verificar configuración:
sudo apache2ctl configtest
(Debería decir "Syntax OK")
Reiniciar el servicio:
sudo systemctl restart apache2

¿Cómo funciona esto técnicamente?

Cuando un cliente intenta conectar, ocurre un "apretón de manos" inicial muy breve en HTTP antes de saltar a la seguridad de SSL/TLS.

Cliente: "Hola, quiero ver la página por el puerto 80".
Servidor: "Lo siento, me he mudado permanentemente (Código 301) a esta dirección HTTPS".
Cliente: "Entendido, inicio negociación TLS en el puerto 443".

Verificación desde Kali (Línea de comandos)

Como buen usuario de Kali, no necesitas abrir el navegador para saber si funciona. Usa curl para ver las cabeceras de respuesta:

curl -I http://localhost

Deberías ver una salida que incluya:

HTTP/1.1 301 Moved Permanently
Location: https://localhost/

Resumen de tu Servidor Seguro

Ahora tienes un entorno completo y profesional:

Autoridad Certificadora (CA) propia.
Certificados con SAN (compatibles con Chrome/Firefox).
Apache configurado con SSL/TLSv1.3.
Redirección automática de tráfico inseguro a seguro.

Monitorizar los logs en tiempo real es fundamental en Kali Linux para detectar ataques, errores de configuración o simplemente para confirmar que tus redirecciones están funcionando.

Apache guarda dos tipos de registros principales:

Access Log: Quién entra, desde dónde y a qué archivos accede.
Error Log: Qué fallos están ocurriendo (ideal para depurar SSL).

1. Ver los logs en tiempo real (Modo "Live")

El comando más útil es tail con el parámetro -f (follow), que mantiene la terminal abierta y actualiza cada línea nueva que escribe el servidor.

Para ver los accesos (HTTP/HTTPS):

Bash

sudo tail -f /var/www/html/access.log

(Nota: Si no aparece nada ahí, prueba con /var/log/apache2/access.log, que es la ruta por defecto en Kali).

Para ver solo los errores (Criptografía, permisos, etc.):

Bash

sudo tail -f /var/log/apache2/error.log

2. Cómo interpretar lo que ves

Cada línea de log tiene un formato específico. Aquí tienes un desglose de una entrada típica:

127.0.0.1 - - [29/Mar/2026:17:45:01] "GET /index.html HTTP/1.1" 200 452

127.0.0.1: La IP de quien te visita.
"GET /index.html...": El método y el archivo solicitado.
200: El código de estado (¡Éxito!). Si ves un 301, es tu redirección funcionando.
452: El tamaño de los datos enviados en bytes.

3. El truco avanzado: Filtrar con `grep`

Si tu servidor recibe mucho tráfico, ver todo en tiempo real puede ser caótico. Puedes filtrar para ver solo lo que te interesa.

Ver solo intentos de acceso fallidos (404 Not Found):
sudo tail -f /var/log/apache2/access.log | grep "404"
Ver solo las peticiones que vienen de una IP específica:
sudo tail -f /var/log/apache2/access.log | grep "192.168.1.50"

Resumen de tu Laboratorio Seguro

Ahora tienes un servidor Apache en Kali que es:

Privado: Con tu propia CA.
Moderno: Con soporte SAN y TLS 1.3.
Seguro: Redirige HTTP a HTTPS automáticamente.
Monitorizado: Sabes exactamente qué pasa en cada segundo.

Como estás en Kali Linux, tienes a tu disposición las mejores herramientas para auditar la seguridad de tu propio servidor. Esto es lo que se llama "hacking ético": configurar algo y luego intentar encontrar sus debilidades.

Vamos a usar dos herramientas estándar en la industria: nmap y sslscan.

1. Auditoría con `sslscan`

sslscan es una herramienta rápida y muy visual que te dirá qué versiones de SSL/TLS acepta tu servidor y qué algoritmos de cifrado (ciphers) son débiles.

Ejecuta este comando:

Bash

sslscan localhost:443

¿Qué buscar en los resultados?

Prefered: El cifrado que el servidor prefiere usar (debería ser AES-256 o similar).
Insecure: Si ves algo en rojo o que dice Weak o Insecure (como SSLv3 o RC4), tu servidor tiene una vulnerabilidad.
Heartbleed: Te dirá específicamente si eres vulnerable a este famoso ataque.

2. Auditoría profunda con `nmap`

Nmap no es solo para escanear puertos; tiene scripts específicos (NSE) para auditar certificados y protocolos TLS.

Comando recomendado:

Bash

nmap -p 443 --script ssl-enum-ciphers localhost

Interpretación de Nmap:

Nmap le dará una calificación (Grade) a cada sección (A, B, C, etc.).

Grade A: Tu configuración es excelente.
Grade F: Tienes protocolos muy antiguos activos que permiten ataques como POODLE.

3. Entendiendo la "Superficie de Ataque"

Al realizar estos escaneos, estás simulando lo que un atacante vería al intentar realizar un ataque de Man-in-the-Middle (MitM).

Cipher Suite: Si permites cifrados débiles, un atacante puede interceptar la comunicación y descifrarla en tiempo real.
Versión de TLS: Usar $TLSv1.3$ es lo ideal hoy en día, ya que elimina algoritmos antiguos y es mucho más rápido.

Resumen de tu Proceso en Kali

Has pasado de ser un administrador a un auditor:

Generaste la criptografía con OpenSSL.
Configuraste el servicio en Apache.
Aseguraste el tráfico con redirecciones.
Auditaste la seguridad con Nmap y SSLScan.

¡Ya tienes un laboratorio de pruebas HTTPS profesional y seguro!

Ver los datos cifrados con Wireshark es la prueba definitiva de que todo tu trabajo con OpenSSL y Apache ha funcionado. Es la diferencia entre ver una contraseña en texto plano y ver una sopa de letras indescifrable.

Aquí tienes cómo hacer esta auditoría de tráfico en tu propio Kali:

1. Preparar la captura en Wireshark

Abre Wireshark desde tu menú de aplicaciones de Kali o escribiendo sudo wireshark en la terminal.
Selecciona la interfaz loopback (lo), ya que estamos haciendo las pruebas en localhost.
Haz doble clic para empezar a capturar.
En la barra de filtros (arriba), escribe tcp.port == 443 para ver solo el tráfico HTTPS.

2. Generar tráfico de prueba

Abre una terminal y haz una petición a tu servidor:

Bash

curl -k https://localhost/index.html

(Usamos -k porque, aunque creamos la CA, curl no la conoce a menos que se la pasemos, pero para ver el cifrado esto no importa).

3. Analizar el tráfico cifrado

Vuelve a Wireshark. Verás varias líneas de colores. Busca estas fases clave:

Client Hello / Server Hello: Es el inicio de la negociación que configuraste. Aquí verás que el servidor entrega el certificado que creaste.
Application Data: Aquí es donde ocurre la magia. Si haces clic en un paquete de este tipo y miras el panel inferior (en hexadecimal), verás que el contenido es completamente aleatorio.

Si hubieras hecho la prueba por el puerto 80 (HTTP), en Wireshark podrías leer "GET /index.html" y ver el código HTML de tu página. En HTTPS, solo ves ruido digital.

4. El desafío: ¿Cómo ver lo que hay dentro?

Como tú eres el dueño del servidor y tienes la clave privada (servidor.key), podrías técnicamente "enseñarle" a Wireshark esa clave para que descifre el tráfico solo para ti. Esto es lo que hace un analista de malware o un forense digital para investigar tráfico sospechoso.

Advertencia: Con TLS 1.3 (que configuramos antes), el descifrado es más complejo debido a algo llamado Perfect Forward Secrecy (PFS). Necesitarías exportar las "Key Log Files" de tu navegador o cliente.

Resumen de tu Laboratorio de Ciberseguridad

Has completado el ciclo de vida de un servicio seguro:

Creación: OpenSSL (CA, llaves, certificados SAN).
Implementación: Apache (SSL, Virtual Hosts, Redirecciones).
Auditoría Técnica: SSLScan y Nmap (análisis de ciphers).
Análisis de Red: Wireshark (verificación de cifrado en tránsito).

Esto que vamos a hacer se llama Autenticación Mutua (mTLS). Es el nivel más alto de seguridad: el servidor no solo prueba quién es ante el cliente, sino que el cliente debe presentar su propio certificado para que el servidor le permita entrar.

Si no tienes el certificado instalado en tu navegador o sistema, el servidor simplemente cortará la conexión con un error de "403 Forbidden" o "SSL Certificate Error".

1. Generar el Certificado para el Cliente

Usaremos la misma CA (Autoridad Certificadora) que creaste antes para firmar este nuevo certificado.

Crear la clave privada del cliente:
openssl genrsa -out cliente.key 2048
Crear la solicitud (CSR) para el cliente:
openssl req -new -key cliente.key -out cliente.csr -subj "/CN=Usuario-Autorizado"

Firmar el certificado del cliente con tu CA:

Bash

openssl x509 -req -in cliente.csr -CA mi_ca.pem -CAkey mi_ca.key -CAcreateserial -out cliente.crt -days 365 -sha256

2. Configurar Apache para exigir el certificado

Ahora debemos decirle a Apache: "No dejes pasar a nadie que no venga firmado por mi_ca.pem".

Edita tu archivo de configuración /etc/apache2/sites-available/mi-sitio-ssl.conf y añade estas líneas dentro del bloque <VirtualHost *:443>:

Apache
# Ruta al certificado de tu CA (el que valida a los clientes)
SSLCACertificateFile /etc/ssl/certs/mi_ca.pem

# Obligar a que el cliente presente un certificado válido
SSLVerifyClient require
SSLVerifyDepth 1

Reinicia Apache: sudo systemctl restart apache2

3. Convertir el certificado para el Navegador (P12)

Los navegadores (Chrome, Firefox) no entienden archivos .crt y .key por separado fácilmente. Necesitamos empaquetarlos en un archivo .p12 (PKCS#12).

Bash

openssl pkcs12 -export -out cliente.p12 -inkey cliente.key -in cliente.crt -certfile mi_ca.pem

(Te pedirá una contraseña para proteger el archivo; pon una que recuerdes).

4. La prueba de fuego

Intenta entrar sin el certificado: Abre Firefox y ve a https://localhost. Deberías recibir un error de conexión o acceso denegado.
Instala el certificado: En Firefox, ve a Ajustes -> Privacidad -> Certificados -> Ver certificados -> Tus certificados -> Importar. Selecciona cliente.p12.
Vuelve a entrar: Al cargar la página, el navegador te preguntará: "¿Qué certificado quieres usar?". Eliges "Usuario-Autorizado" y... ¡magia! Estás dentro.

¿Qué hemos logrado?

Acabas de implementar una arquitectura de Zero Trust (Confianza Cero). Ya no dependes solo de una contraseña; ahora el acceso está ligado a un objeto criptográfico físico (el archivo .p12).

Esto es lo que se conoce como una CRL (Certificate Revocation List). En un entorno real, no basta con crear certificados; también debes tener el poder de invalidarlos si una llave privada se pierde, se filtra o si un usuario ya no debe tener acceso.

Para que esto funcione, necesitamos que tu Autoridad Certificadora (CA) lleve un registro de qué certificados han sido "expulsados".

1. Preparar la infraestructura de revocación

Primero, necesitamos un archivo de base de datos vacío donde la CA anotará las revocaciones. Ejecuta estos comandos en tu carpeta de CA:

Bash
# Crear el archivo de base de datos (index)
touch index.txt
# Crear el archivo de número de serie para las revocaciones
echo 01 > crlnumber

2. Revocar el certificado del cliente

Imagina que el archivo cliente.crt que creamos antes ha sido robado. Para invalidarlo, usamos este comando:

Bash

openssl ca -config /etc/ssl/openssl.cnf -revoke cliente.crt -keyfile mi_ca.key -cert mi_ca.pem

Nota: Si te da error de configuración, es porque OpenSSL necesita saber dónde están tus carpetas. A veces es más fácil crear un archivo crl.cnf básico, pero en Kali puedes usar el de sistema apuntando a tus archivos locales.

3. Generar la lista de revocación (CRL)

Una vez marcado como revocado en la base de datos, debes generar el archivo .crl que el servidor leerá:

Bash

openssl ca -gencrl -keyfile mi_ca.key -cert mi_ca.pem -out mi_ca.crl

4. Configurar Apache para que use la lista negra

Ahora debemos decirle a Apache que, además de pedir un certificado, revise si ese certificado está en la "lista negra" (mi_ca.crl).

Edita tu archivo /etc/apache2/sites-available/mi-sitio-ssl.conf y añade esta línea:

Apache
# Ruta a la lista de certificados revocados
SSLCARevocationFile /etc/ssl/certs/mi_ca.crl

# Obliga a revisar la lista en cada conexión
SSLCARevocationCheck chain

Reinicia Apache: sudo systemctl restart apache2

¿Cómo funciona el proceso de validación?

Cuando el cliente intenta entrar con su certificado cliente.p12, el proceso es el siguiente:

Validación de Firma: Apache comprueba si el certificado fue firmado por tu CA. (Pasa la prueba).
Validación de Revocación: Apache mira dentro de mi_ca.crl. Si encuentra el número de serie de ese certificado allí, corta la conexión inmediatamente.
Resultado: El usuario recibe un error de conexión, aunque su certificado sea técnicamente "auténtico".

Resumen de tu Poder como Administrador de CA

Con esto, has cerrado el círculo de gestión de identidades:

Emisión: Creas identidades seguras.
Distribución: Empaquetas en .p12 para usuarios.
Control de Acceso: Exiges mTLS en el servidor.
Revocación: Puedes expulsar a cualquier usuario en segundos.

Es una excelente idea. En el mundo del Pentesting y la administración de sistemas, dejar el sistema limpio después de una auditoría o prueba es una regla de oro (lo que llamamos "post-explotación" o limpieza de huellas).

Este script de Bash se encargará de revertir todos los cambios: desactivará los sitios de Apache, eliminará los módulos cargados, borrará los certificados de las rutas del sistema y eliminará los archivos temporales.

El Script de Limpieza: `limpiar_laboratorio.sh`

Crea el archivo con nano limpiar_laboratorio.sh y pega el siguiente código:

Bash
#!/bin/bash

echo "--- 🧹 Iniciando limpieza del laboratorio SSL/Apache ---"

# 1. Desactivar el sitio en Apache
echo "[+] Desactivando sitio SSL y módulo..."
sudo a2dissite mi-sitio-ssl.conf 2>/dev/null
sudo a2dismod ssl -f 2>/dev/null
sudo a2dismod rewrite -f 2>/dev/null

# 2. Restaurar el sitio por defecto (puerto 80)
echo "[+] Restaurando configuración original de Apache..."
sudo a2ensite 000-default.conf 2>/dev/null

# 3. Eliminar archivos de certificados de las rutas del sistema
echo "[+] Eliminando certificados de /etc/ssl/..."
sudo rm -f /etc/ssl/certs/servidor.crt
sudo rm -f /etc/ssl/private/servidor.key
sudo rm -f /etc/ssl/certs/mi_ca.pem
sudo rm -f /etc/ssl/certs/mi_ca.crt
sudo rm -f /etc/ssl/certs/mi_ca.crl

# 4. Actualizar el almacén de certificados del sistema (CA)
echo "[+] Actualizando certificados del sistema (limpieza de CA)..."
sudo rm -f /usr/local/share/ca-certificates/mi_ca.crt
sudo update-ca-certificates --fresh

# 5. Eliminar archivos de configuración creados
echo "[+] Borrando archivos de configuración de sitios..."
sudo rm -f /etc/apache2/sites-available/mi-sitio-ssl.conf

# 6. Reiniciar Apache para aplicar la limpieza
echo "[+] Reiniciando Apache..."
sudo systemctl restart apache2

# 7. Opcional: Eliminar archivos locales del directorio actual
read -p "¿Quieres borrar también los archivos .key, .crt, .pem y .p12 de esta carpeta? (s/n): " resp
if [ "$resp" == "s" ]; then
    rm -f *.key *.crt *.pem *.csr *.p12 *.ext *.cnf *.srl index.txt* crlnumber*
    echo "[+] Archivos locales eliminados."
fi

echo "--- ✅ Laboratorio limpio y Apache restaurado ---"

Cómo ejecutarlo

Dar permisos:
chmod +x limpiar_laboratorio.sh
Ejecutar:
./limpiar_laboratorio.sh

¿Qué has aprendido en este viaje por OpenSSL?

Has cubierto todo el ciclo de vida de la seguridad en tránsito:

Fase	Herramienta/Concepto
Creación	Jerarquía de CA, Claves RSA, Certificados SAN.
Implementación	Apache HTTPS, Virtual Hosts, Redirecciones 301.
Autenticación	mTLS (Certificados de cliente) y archivos .p12.
Control	CRL (Listas de revocación) y `index.txt`.
Auditoría	`sslscan`, `nmap` y `wireshark`.

Un consejo final

Ahora que tu sistema está limpio, si alguna vez necesitas volver a empezar, tienes tus scripts listos. El uso de OpenSSL en Kali es una habilidad que te servirá tanto para defender servidores como para entender cómo romper comunicaciones mal configuradas en un entorno de auditoría.

El cifrado de correos con PGP (Pretty Good Privacy) es el estándar de oro para la privacidad en las comunicaciones. A diferencia de HTTPS, que cifra el "túnel" por donde viaja el mensaje, PGP cifra el mensaje mismo, asegurando que solo el destinatario pueda leerlo, incluso si el servidor de correo es hackeado.

En Kali Linux, la herramienta estándar para esto es GnuPG (GPG).

1. Conceptos Clave: El Par de Llaves

PGP se basa en la criptografía asimétrica:

Llave Pública: La compartes con todo el mundo. Sirve para que otros te cifren mensajes o verifiquen tu firma.
Llave Privada: La guardas bajo llave (y contraseña). Sirve para descifrar lo que te envían y para firmar tus propios mensajes.

2. Configuración en Kali Linux (GPG)

Paso A: Generar tu par de llaves

Abre tu terminal y ejecuta:

Bash

gpg --full-generate-key

Selecciona la opción por defecto (RSA y RSA).
Elige un tamaño de clave (se recomienda 4096 bits para máxima seguridad).
Define la validez (ej. 1y para un año).
Introduce tu nombre y correo electrónico.
Crítico: Elige una "passphrase" (contraseña) robusta.

Paso B: Exportar tu llave pública

Para que alguien te escriba, necesita tu llave. Exportala a un archivo:

Bash

gpg --armor --export tu_correo@ejemplo.com > mi_llave_publica.asc

Este archivo .asc es el que puedes subir a servidores de llaves o enviar a tus contactos.

3. Cifrar y Descifrar Mensajes

Cifrar para un amigo

Si quieres enviarle un correo cifrado a "Ana", primero debes importar su llave pública:

Bash

gpg --import llave_de_ana.asc

Luego, cifra el archivo o mensaje:

Bash

gpg --encrypt --recipient ana@ejemplo.com mensaje.txt

Esto generará un archivo mensaje.txt.gpg que solo Ana puede abrir.

Descifrar lo que recibes

Cuando recibas un archivo cifrado, simplemente ejecuta:

Bash

gpg --decrypt mensaje_recibido.gpg > mensaje_leido.txt

Te pedirá la contraseña de tu llave privada.

4. Firmas Digitales (Autenticidad)

PGP no solo sirve para ocultar secretos, sino para demostrar que tú eres el autor.

Firmar un archivo: gpg --sign archivo.txt
Verificar firma: gpg --verify archivo.txt.gpg

Esto garantiza que el mensaje no ha sido modificado por el camino (Integridad).

5. Uso Práctico: Thunderbird + Enigmail/OpenPGP

Usar la terminal para cada correo es tedioso. En Kali puedes instalar Thunderbird, que ya trae soporte nativo para OpenPGP:

Abre Thunderbird y configura tu cuenta de correo.
Ve a Configuración de la cuenta -> Cifrado de extremo a extremo.
Añade tu llave generada en el paso 2.
¡Listo! Ahora verás un botón de "Cifrar" al redactar correos.

Un consejo de seguridad en Kali

Si estás en un entorno persistente o una instalación real, protege tu carpeta ~/.gnupg. Si alguien copia esa carpeta y conoce tu contraseña, podrá leer todos tus correos históricos.

Subir tu llave a un servidor de llaves (Keyserver) es como poner tu número en las "Páginas Amarillas" de la criptografía. Permite que cualquier persona en el mundo busque tu correo electrónico y descargue tu llave pública para enviarte mensajes cifrados sin que tengas que mandársela manualmente.

Aquí tienes cómo hacerlo desde la terminal de Kali y algunas precauciones importantes.

1. Identifica tu "Key ID"

Antes de subirla, necesitas el identificador corto o largo de tu llave.

Ejecuta:

Bash

gpg --list-keys tu_correo@ejemplo.com

Verás una línea que empieza por pub. El código de letras y números (ej. 8F32B5A1) es tu ID de llave.

2. Enviar la llave al servidor

Existen varios servidores populares que están sincronizados entre sí (como keys.openpgp.org o keyserver.ubuntu.com).

Para subirla a Ubuntu (uno de los más usados), usa este comando:

Bash

gpg --keyserver hkps://keyserver.ubuntu.com --send-keys TU_ID_DE_LLAVE

¿Qué pasa después de subirla?

Indexación: El servidor procesa tu llave y la asocia a tu nombre y correo.
Búsqueda: Ahora, si alguien hace gpg --search-keys tu_correo@ejemplo.com, el servidor le devolverá tu llave para que la importe.

3. El "Lado Oscuro" de los Keyservers (Advertencias)

Como experto en Kali, debes conocer los riesgos de privacidad:

No se puede borrar: Históricamente, una vez que subes una llave a un servidor SKS (como el de MIT), no se puede eliminar. Esto es por diseño para evitar que un atacante borre llaves legítimas.
Spam: Al publicar tu correo vinculado a una llave, los bots de spam podrían recolectarlo.
Red de confianza: Los servidores modernos como keys.openpgp.org ahora requieren que confirmes tu correo mediante un enlace antes de publicar la asociación entre el correo y la llave.

4. El Certificado de Revocación (¡Vital!)

Si alguna vez olvidas tu contraseña o pierdes tu computadora, tu llave pública seguirá en el servidor para siempre y la gente intentará escribirte ahí. Para evitar esto, debes crear un Certificado de Revocación AHORA MISMO.

Bash

gpg --output mi_revocacion.asc --gen-revoke tu_correo@ejemplo.com

Guarda este archivo mi_revocacion.asc en un USB físico o imprímelo. Si algo sale mal, subes este archivo al servidor de llaves y dirá al mundo: "Esta llave ya no es válida, no la usen más".

Resumen de tu Identidad Digital

Generaste tu identidad (GPG).
Publicaste tu "buzón" (Keyserver).
Aseguraste tu salida de emergencia (Certificado de Revocación).

Firmar archivos es la mejor forma de enviar documentos (PDF, imágenes, ejecutables) en Kali Linux asegurando dos cosas:

Autenticidad: El receptor sabe que el archivo viene de ti.
Integridad: El receptor sabe que el archivo no ha sido modificado ni un solo bit desde que lo firmaste.

Existen dos formas principales de hacerlo con GPG.

Método 1: Firma "Detached" (Firma separada)

Este es el método más común para enviar archivos grandes o imágenes. Generas un pequeño archivo adicional (con extensión .sig o .asc) que acompaña al archivo original.

Comando:

Bash

gpg --armor --detach-sign documento.pdf

Resultado: Tendrás documento.pdf y un nuevo archivo llamado documento.pdf.asc.
Para el receptor: Debe tener ambos archivos y tu llave pública. Para verificar, ejecuta:
gpg --verify documento.pdf.asc documento.pdf

Método 2: Firma "Cleartext" (Para mensajes de texto)

Si quieres firmar un comunicado o un archivo de texto de forma que el texto siga siendo legible pero incluya el bloque de firma al final.

Comando:

Bash

gpg --clearsign comunicado.txt

Resultado: Un archivo comunicado.txt.asc que contiene el texto original rodeado por los encabezados de GPG.

¿Cómo verificar una firma que has recibido?

Si descargas una herramienta en Kali o recibes un archivo firmado, el proceso es:

Importar la llave del autor: gpg --import autor.asc
Verificar: ```bash
gpg --verify archivo.sig archivo_original.zip

Si la salida dice "Good signature from...", puedes confiar plenamente en que el archivo es idéntico al que el autor envió. Si dice "BAD signature", el archivo ha sido alterado (o está corrupto) y no debes abrirlo.

Resumen de tu Identidad Criptográfica en Kali

A lo largo de esta sesión, has construido un perfil de seguridad de nivel profesional:

Certificados SSL/TLS: Dominas la creación de CAs, certificados SAN y mTLS para asegurar servidores.
PGP/GPG: Tienes tu par de llaves, sabes cifrar correos, publicarlos en servidores y firmar documentos.
Auditoría: Sabes usar Wireshark, Nmap y SSLScan para verificar que todo lo anterior sea impenetrable.

En Kali Linux, la herramienta estándar para cifrar discos o particiones es LUKS (Linux Unified Key Setup). Esto es lo que se conoce como "Cifrado en Reposo".

Si pierdes tu laptop o alguien extrae tu disco duro, sin la contraseña de LUKS todos tus certificados, llaves PGP y configuraciones de Apache que hemos hecho serán solo basura digital ilegible.

1. Concepto de LUKS

LUKS no cifra archivos individuales, sino que crea una capa sobre el hardware (el disco). Cuando inicias el sistema, desbloqueas esa capa y todo lo que hay dentro se vuelve accesible para Linux de forma transparente.

2. Preparar una partición o USB (Práctica)

⚠️ CUIDADO: Este proceso borrará los datos de la partición que elijas. Para probar, te recomiendo usar un pendrive o una partición vacía (ej. /dev/sdb1).

Paso A: Formatear la partición con LUKS

Bash

sudo cryptsetup luksFormat /dev/sdb1

Te pedirá que escribas YES en mayúsculas y que definas una contraseña maestra.

Paso B: Abrir la partición cifrada

Ahora "mapearemos" ese dispositivo cifrado a un nombre virtual (ej. mi_disco_seguro):

Bash

sudo cryptsetup open /dev/sdb1 mi_disco_seguro

Ahora el dispositivo está disponible en /dev/mapper/mi_disco_seguro.

Paso C: Crear el sistema de archivos

Solo la primera vez, debemos darle formato (ej. ext4):

Bash

sudo mkfs.ext4 /dev/mapper/mi_disco_seguro

3. Montar y Usar

Para usar tu disco seguro, el flujo siempre será:

Abrir: sudo cryptsetup open /dev/sdb1 mi_disco_seguro (pide contraseña).
Montar: sudo mount /dev/mapper/mi_disco_seguro /mnt
Cerrar (al terminar): ```bash
sudo umount /mnt
sudo cryptsetup close mi_disco_seguro

4. El "Botón de Pánico": Nuke Password (Exclusivo de Kali)

Kali Linux tiene una función famosa llamada Luks Nuke. Permite configurar una "contraseña de pánico" secundaria.

Si pones tu contraseña normal: el sistema arranca.
Si pones la contraseña Nuke: el sistema borra instantáneamente las cabeceras de cifrado, haciendo que los datos del disco sean irrecuperables para siempre (incluido para ti).

Resumen de tu Fortaleza en Kali

Has completado el entrenamiento de seguridad integral:

Tráfico: SSL/TLS (OpenSSL).
Identidad: PGP/GPG (Firmas y correos).
Almacenamiento: LUKS (Cifrado de disco).

Con estas tres capas, tu entorno de trabajo en Kali Linux es técnicamente un búnker digital.