Un Jedi no deja su sable en manos del Imperio. Nadie debería dejar datos en un disco que ya no es suyo. Estás dando datos de tu vida al enemigo y es muy peligroso.

Cuando pulsas Supr, el sistema operativo tacha el nombre del fichero de la lista. Los datos siguen ahí, exactamente donde estaban. Cualquier herramienta de recuperación puede leerlos. Eso incluye el portátil vendido en Wallapop, el disco al contenedor de electrónica y el servidor devuelto al proveedor al final del contrato de leasing. Un día me encontré en un punto limpio un ordenador antiguo que funcionaba perfectamente, tenía el disco duro y fotos de una familia que se podían recuperar, esto es un peligro.

El RGPD tiene opinión sobre esto. El ENS también. La sanción no es por haber tenido los datos — es por no haberlos destruido cuando tocaba.

shred, nwipe y ATA Secure Erase existen para eso. Esta guía cubre HDDs, SSDs y NVMe, qué exige la ley y por qué formatear no es borrar.

Un Jedi no muestra su posición. Ya lo vimos con Cloudflare Tunnel: sin puertos abiertos, sin IP expuesta, invisible desde internet. Ya sabemos que cuántas más capas de protección, mejor. Invisible no tiene que ser inaccesible. La URL existe. Cloudflare la atiende. Y cualquiera que la conozca puede llamar a esa puerta.

Sun Tzu lo escribió hace dos mil quinientos años: defender la posición no es suficiente. Hay que controlar quién entra y quién nos observa.

Cloudflare Access es esa capa de control. Antes de que una sola petición llegue a tus dominios, el usuario tiene que identificarse, tenemos que saber si es de confianza o no — con Google, GitHub o un código de un solo uso enviado al email. Sin contraseña compartida. Sin VPN. Sin cuenta local que gestionar. Solo: demuestra quién eres. Y si tu identidad cumple la política y eres de confianza, entras. Con el plan gratuito, hasta 50 usuarios.

Todo el contenido publicado aquí —artículos, scripts, herramientas y configuraciones— tiene fines exclusivamente educativos y refleja mi experiencia personal trabajando sobre infraestructura propia o en entornos de laboratorio controlados.

Las técnicas, metodologías y herramientas descritas están pensadas para su uso en sistemas propios o con autorización explícita de sus propietarios. El conocimiento de técnicas ofensivas forma parte del aprendizaje defensivo; publicar algo no implica que sea adecuado para cualquier contexto.

Si reutilizas o adaptas lo que encuentres aquí, eres responsable de hacerlo dentro del marco legal de tu país, especialmente en materia de protección de datos (RGPD), acceso no autorizado a sistemas (art. 197 bis CP) y privacidad. El autor no asume responsabilidad por usos que contravengan la legislación aplicable.

Este contenido está dirigido a un público técnico con criterio propio. Úsalo con cabeza.

Sun Tzu lo dejó escrito hace 2.500 años: conoce al enemigo y conócete a ti mismo.

El problema es que en seguridad tendemos a obsesionarnos con el primero y saltarnos el segundo. Escaneamos redes, analizamos vulnerabilidades, buscamos CVEs —y en ningún momento nos preguntamos si las herramientas que usamos para hacer eso son de fiar.

Eso es lo que hice diferente esta vez.

Antes de poner en marcha un servidor MCP con 27 herramientas de inteligencia de vulnerabilidades, hice una auditoría completa del código. Cuatro análisis paralelos. Treinta y cuatro hallazgos clasificados por severidad. Y la conclusión fue que el código es apto —pero por razones que no son evidentes a simple vista.

Esto es lo que encontré, lo que apliqué como mitigación, y cómo encaja en un flujo real de pentesting.

El Imperio controla la Holonet. Cada mensaje que viaja por los canales oficiales pasa por sus filtros, sus inspectores, sus reglas de firewall.

La Alianza aprendió pronto que la única forma de comunicarse con seguridad era no usar esos canales. Había otra red — más discreta, construida con nodos de confianza conectados por rutas encubiertas. Un paquete que parecía ir de Tatooine a Mos Eisley llevaba en realidad las coordenadas de Echo Base cifradas en su interior. El firewall imperial solo veía una conexión SSH normal. Lo que viajaba dentro era otra cosa.

SSH funciona así. No mueve solo sesiones de terminal — mueve cualquier tráfico TCP dentro de un canal cifrado. Un servicio bloqueado por el firewall puede aparecer en tu localhost. Un servidor interno puede exponerse al exterior con un solo comando. La red privada de otro sistema se convierte en tu red.

Ocho escenarios. Tres flags (-L, -R, -D). Un solo canal SSH. Esta es la guía completa de port forwarding actualizada a 2026: los comandos de hoy, ProxyJump, Sshuttle y lo que los libros no cuentan.

Un Jedi no muestra su sable hasta que es necesario. Un sysadmin no abre puertos hasta que no queda otra opción.

El acceso remoto clásico hace lo contrario: abre puertos en el router y publica tu posición. El 8443 de tu Proxmox, el 8096 de tu Jellyfin, el 22 de tu SSH — visibles para cualquier bot que escanee internet, esperando a que alguien encuentre el exploit del mes.

Cloudflare Tunnel gira esa lógica. Tu servidor establece una conexión saliente hacia Cloudflare — son ellos quienes reciben el tráfico exterior y lo reenvían hacia ti. El router no abre nada. Tu IP real no aparece en ningún sitio. El atacante no puede atacar lo que no ve.

Sin un solo puerto abierto. Sin IP fija. Sin NAT. Y tu Jellyfin accesible desde cualquier lugar del mundo con HTTPS y con tu propio dominio.

Sun Tzu escribió que la victoria real no es ganar la batalla — es no tener que librarla.

En seguridad de red, eso se llama Zero Trust. No esperar a que el atacante entre para pararlo. Diseñar la red para que, si entra, no encuentre nada que merezca la pena atacar.

Y no necesitas un presupuesto de Fortinet para aplicarlo.

En el Imperio , Darth Vader tenía acceso a todo. Ninguna puerta cerrada, ningún sistema restringido, ninguna contraseña que conociera, ….. usuario ALL=(ALL:ALL) ALL y listo — el equivalente en sudoers para darle la llave de la Estrella de la Muerte a alguien sin más explicación.

El problema es que no todos los usuarios de tu sistema son Darth Vader. Algunos son técnicos de mantenimiento que solo necesitan reiniciar un servicio. Otros son scripts de automatización que ejecutan un rsync a las 3 de la mañana. Y algunos, simplemente, no deberían tener acceso a un sudo bash de distancia.

La mayoría de guías de sudo se quedan en esa primera línea y punto. Útil para empezar, pero en la práctica real necesitas más matices: permisos granulares por comando, comportamiento fino con Defaults, diferencias entre distribuciones y saber auditar quién ha estado haciendo qué en tu infraestructura.

Este artículo va un paso más allá del básico. Vamos a pasar de aprendiz a caballero Jedi.

Una Raspberry Pi funcionando 24/7 escribe en su tarjeta SD constantemente. Los logs del sistema, el journal de systemd, las rotaciones periódicas — todo aterriza en la misma memoria flash que tiene un número limitado de ciclos de escritura. El resultado es predecible: la tarjeta falla antes de tiempo, normalmente en el peor momento.

log2ram resuelve esto con una idea simple: mover /var/log a la RAM del sistema y sincronizar a disco periódicamente. El resultado es una reducción de escrituras de entre el 70 y el 80%.

La investigación OSINT siempre ha requerido combinar herramientas distintas, copiar resultados entre terminales y sintetizar todo a mano. harper-osint integra maigret, holehe, sherlock, theHarvester y varias librerías especializadas en un único servidor MCP. Claude hace la investigación. Tú lees el informe.

Hace unos años configurar un servidor de correo era instalar Postfix y listo. Hoy, si no tienes SPF, DKIM y DMARC bien configurados, tus correos acaban en spam — o peor, alguien puede enviar correos suplantando tu dominio sin que puedas hacer nada.

Los tres son registros DNS. Los tres sirven para autenticar el correo. Pero hacen cosas distintas y se despliegan en un orden concreto. Este artículo explica cómo funcionan, cómo se configuran y cómo se verifica que todo está bien.