Los 8 errores de seguridad que cometí con mi servidor casero (y cómo arreglarlos)
Esta web que estás leyendo se sirve desde una Raspberry Pi 5 en mi habitación. No es un experimento: aquí viven 420+ artículos, 58 cron jobs y un sistema de agentes de IA que publica contenido todos los días. Y durante meses, la seguridad fue lo último en lo que pensé.
Hasta que las cosas empezaron a romperse. Un agente me generó una factura de 6.531,30 dólares en AWS en una sola noche. Mi firewall de intrusiones no arrancaba desde el primer día y nadie se había dado cuenta. Mi sistema de auto-reparación corrompió la base de datos dos veces mientras intentaba arreglarla.
Estos son los 8 errores que cometí, en orden de gravedad, con el arreglo exacto que funcionó. Si tienes una Raspberry Pi, un mini PC viejo o cualquier equipo sirviendo algo desde casa, esto te va a ahorrar las noches que a mí me costaron.
¿Por qué un servidor casero es un objetivo?
Porque los escáneres de internet no distinguen entre un banco y tu Raspberry Pi. Recorren rangos de IP completos buscando puertos abiertos, y cuando encuentran uno, prueban contraseñas por defecto y exploits conocidos. No te atacan a ti: te encuentran a ti.
La buena noticia: el 90% del problema desaparece si simplemente no abres ningún puerto. Los errores que cometí no fueron de hacking sofisticado, fueron de configuración básica descuidada. Y eso es lo mejor que te puede pasar: se arreglan con una tarde y cero presupuesto.
Error 1: Abrir puertos en el router sin pensar en las consecuencias
Cuando monté el primer servidor, hace tres años, hice lo que hacen todos los tutoriales: port forwarding del 80 y el 443 a la IP local de la máquina. Funcionó. También dejó mi equipo expuesto a internet con un SSH por contraseña y sin firewall configurado.
El problema no es el port forwarding en sí. Es que convertir un servicio privado en público sin capas de protección te deja a un exploit de distancia de perder el equipo. Un servicio web con una vulnerabilidad conocida y sin parchear es una puerta abierta.
El arreglo: cero puertos abiertos con Cloudflare Tunnel
Hoy la web sale a internet por un túnel saliente de Cloudflare. La Raspberry Pi hace una conexión hacia fuera y Cloudflare la mantiene. Mi router no tiene ni un solo puerto abierto: ni 22, ni 80, ni 443. Escaneas mi IP y no hay nada que atacar.
Alternativas si no quieres depender de Cloudflare: Tailscale o WireGuard para acceso privado, y para algo público, un VPS de 4 euros como proxy inverso. La regla es la misma: ningún puerto abierto en el router.
Error 2: Creer que fail2ban estaba protegiendo mi SSH
Instalé fail2ban el primer día. Lo olvidé. Meses después descubrí que nunca había arrancado: en Debian 12 la jail de SSH busca /var/log/auth.log, y en instalaciones mínimas ese archivo no existe. El servicio fallaba al inicio con «Have not found any log file for ssh jail» y se quedaba desactivado, en silencio.
Esto es un problema conocido de fail2ban en Debian 12: el backend por defecto espera archivos de log que el sistema ya no escribe porque todo va al journal de systemd.
El arreglo: backend systemd
Después del cambio, fail2ban funciona como debe. Y aprendí la lección general: verificar que un servicio de seguridad está activo no una vez, sino de forma recurrente. Un firewall que no corre no protege nada.
Error 3: Permisos de archivo que daban 403 a mis propios artículos
Durante semanas, cada artículo nuevo que publicaba daba error 403 al abrirlo desde el navegador. El problema: Caddy corre como usuario caddy y mis archivos se creaban como usuario luigy con permisos que el servidor no podía leer. La web funcionaba, pero cada publicación era una lotería.
El arreglo es aburrido pero vital: permisos correctos en todo lo que sirve el servidor. Y como soy olvidadizo, lo automatizamos con un watchdog que corrige permisos cada 30 minutos.
La regla de oro: si un archivo da 403 y el servidor corre con otro usuario, es permisos, no magia. Míralo antes de perder una hora.
Error 4: Darle a un agente de IA acceso a dinero sin límite
Este es el que más caro me salió. En junio de 2026 documenté el caso: un agente autónomo desplegó 5 instancias masivas en AWS para escanear la red DN42. Nadie lo supervisó. La factura: 6.531,30 dólares.
No era mi agente, pero podría haberlo sido perfectamente. Mi sistema ejecuta 17 agentes automáticos con acceso a APIs de pago. Si uno se engancha en un bucle, quema tokens hasta que la tarjeta diga basta.
De hecho me pasó a pequeña escala: 25 agentes cayeron en cascada por 4 centavos de saldo insuficiente en una API. No fue caro, pero demostró que no había ninguna red de seguridad.
El arreglo: presupuesto duro, alertas y kill switch
Tres cosas que implementé y que cualquier persona con agentes IA debería copiar:
- Límite duro de gasto en cada proveedor (billing alerts de AWS, presupuesto en OpenAI/DeepSeek/Anthropic).
- Watchdog de facturación: un cron que comprueba el saldo cada hora y me avisa por Telegram si baja de un umbral.
- Kill switch manual: un comando que detiene todos los agentes de golpe. Lo tengo en Telegram, que es mi centro de control.
Un agente con acceso a dinero sin límite no es una herramienta: es una bomba con calendario.
Error 5: Dejar que la auto-reparación actúe sin supervisión
Tenía un sistema que detectaba errores en la base de datos y los reparaba solo cada noche. Suena genial. Hasta que un día la reparación corrompió la base de datos. Dos veces seguidas. El sistema detectaba la corrupción, la «reparaba» en caliente, y la reescritura dejaba la base en peor estado.
El problema de fondo no era el bug: era que nadie miraba lo que el sistema hacía. Llevaba cuatro semanas reparándose a sí mismo en silencio, 13 veces con el mismo patrón, y ningún humano se había enterado.
El arreglo: alertas, no solo reparación
- Alertas ante cualquier acción automática: si un script modifica datos, manda un mensaje a Telegram. Siempre.
- Backup antes de auto-reparar: la reparación automática solo puede tocar una copia, nunca el original.
- Límite de intentos: si la misma reparación falla dos veces, se detiene y avisa. No insistes: escalas.
La automatización no elimina la supervisión: la cambia de sitio. Si automatizas sin alertas, lo único que automatizas es el desastre silencioso.
Error 6: Guardar secretos donde no puedes verlos
Una semana entera perdida porque una contraseña en un archivo .env tenía dos comillas tipográficas invisibles pegadas al valor. El parser la leía, el sistema la usaba, y la API respondía 401. Nadie la veía porque en el editor parecía un carácter normal.
Los caracteres invisibles, los espacios al final de línea y los BOM de UTF-8 son la pesadilla silenciosa de cualquier servidor. Se cuelan al copiar texto desde un chat, un documento o una web.
El arreglo: validación y visibilidad
Y la regla que más me ha ahorrado dolores de cabeza: los secretos se generan, no se escriben a mano. openssl rand -base64 32 y a copiar. Nada de teclear contraseñas que luego no puedes reproducir.
Error 7: Confiar en que «el dominio y el DNS están bien»
Cuando migré el DNS de un proveedor a otro, la web dejó de resolverse durante horas. El motivo: no había verificado los nameservers antes de cambiar, y los registros tardaron en propagarse mientras el certificado TLS apuntaba al sitio antiguo.
Otra variante del mismo error: contenido duplicado por canonical incorrecto. Google empezó a reportar «página alternativa con etiqueta canónica adecuada» porque el servidor servía la misma página por dos URLs distintas. No rompe la web, pero diluye el SEO.
El arreglo: checklist de DNS antes de tocar nada
- Verificar los nameservers con
dig NS dominio.comantes y después de migrar. - Canonical único en cada página: una URL canónica, el resto redirige con 301.
- TTL bajo (300s) 48 horas antes de cualquier cambio de DNS, para que la propagación sea rápida.
- Comprobar con
dig +shortdesde fuera de tu red (un móvil con datos, por ejemplo) que la resolución es correcta.
El DNS no se toca a lo loco un domingo a las 23:00. Se toca con checklist, con TTL bajo y con alguien que pueda mirar la web desde fuera mientras propagas.
Error 8: No tener un plan de actualizaciones
El servidor estuvo meses sin actualizarse porque «si funciona, no lo toques». Ese es el peor consejo para un equipo expuesto. Cada día salen parches de seguridad, y un servidor sin actualizar es la puerta que los escáneres buscan.
El arreglo: actualizaciones automáticas + reinicio programado
Actualizaciones automáticas de seguridad, reinicio semanal programado y un vistazo rápido a los logs una vez a la semana. Son diez minutos que te evitan el «mi servidor tiene un minero de criptomonedas» que le pasa a mucha más gente de la que crees.
Tabla resumen: el error y su arreglo
| Error | Riesgo real | Arreglo |
|---|---|---|
| Puertos abiertos en el router | Exposición total a escáneres | Cloudflare Tunnel / Tailscale, cero puertos |
| fail2ban sin arrancar | SSH sin protección de fuerza bruta | Backend systemd en paths-debian.conf |
| Permisos incorrectos | 403 en contenido nuevo | chmod 644 + watchdog cada 30 min |
| Agente con acceso a dinero | Facturas de miles de dólares | Límite duro, watchdog de billing, kill switch |
| Auto-reparación sin alertas | Corrupción silenciosa de datos | Alertas en cada acción, backup previo, máx. 2 intentos |
| Secretos con caracteres invisibles | Fallos 401 imposibles de debuggear | cat -A, generación con openssl, validación |
| DNS tocado sin checklist | Caída de la web horas | dig NS, TTL bajo, canonical único, verificación externa |
| Sin plan de actualizaciones | Exploits conocidos sin parchear | unattended-upgrades + reinicio semanal |
Lo que nadie te dijo
Tres cosas que no leí en ningún tutorial y que ahora considero las más importantes:
1. La seguridad de un servidor casero es 90% configuración y 10% hardware. El modelo exacto de Raspberry Pi da igual. Lo que te protege es no abrir puertos, tener los permisos bien y actualizar. La paranoia por el hardware es humo.
2. Los errores más caros no vienen de los atacantes, vienen de tus propias automatizaciones. Mi factura de 6.531 dólares, mi base de datos corrompida y mi semana perdida con la contraseña invisible: todo fue culpa mía, de mis scripts y de mi falta de límites. El enemigo más probable eres tú con un bucle mal escrito.
3. Si algo de seguridad no te da alertas, asume que está roto. fail2ban llevaba meses caído y nadie lo sabía. Un servicio de seguridad silencioso es un servicio que no existe. Todo lo que protege algo debería avisarte cuando deja de proteger.
Checklist final de seguridad para tu servidor casero
- ✅ Cero puertos abiertos en el router (verifica con un escaneo externo).
- ✅ SSH solo con clave pública, contraseña desactivada.
- ✅ fail2ban activo y verificado (
fail2ban-client status sshd). - ✅ Permisos correctos en web, JSON e imágenes.
- ✅ Límite de gasto + alertas en todas las APIs con coste.
- ✅ Backups automáticos y probados (restaurar al menos una vez).
- ✅ Actualizaciones automáticas de seguridad activas.
- ✅ Un canal de alertas (Telegram, email) que de verdad mires.
Si marcas estas 8 casillas, tu servidor casero está más seguro que la mayoría de los VPS de 5 euros que hay en internet. Y si no marcas alguna, ya sabes cuál es el arreglo: está en la tabla de arriba.
Hardware con el que trabajo
Por si te estás planteando montar tu propio servidor casero, este es el equipo real que uso desde hace meses para servir esta web y ejecutar los agentes de IA:
- Raspberry Pi 5 8GB — el cerebro: web, agentes y cron jobs 24/7 con un consumo de risa.
- SSD NVMe 1TB M.2 — el arranque y la base de datos van muchísimo mejor que con microSD.
- Disipador con ventilador para RPi 5 — con carga sostenida la CPU agradece no ir a 80 °C.
Conclusión
Servir una web desde casa es viable, barato y, con las decisiones correctas, seguro. Las decisiones correctas no son complicadas: no abras puertos, verifica que tus protecciones están activas, pon límites a tus automatizaciones y actualiza. Cada error de esta lista tuvo un arreglo de menos de 30 minutos. Lo caro no fue el arreglo: fue el tiempo que tardé en darme cuenta de que el problema existía.
Si te ha servido, cuéntame tu caso en el contacto. Los errores de servidor casero son un clásico, y compartirlos es la única forma de que no los pague todo el mundo dos veces.