VPS sin logs: como convertir tu servidor VPN en no-logs

Qué se registra realmente en un servidor

El atractivo de montar tu propia VPN es sencillo: no hay ninguna empresa entre tú e internet anotando lo que haces. Pero un servidor Linux estándar sigue guardando registros propios, y si quieres una configuración sin logs de verdad necesitas saber cuáles son:

• WireGuard en sí no guarda ningún registro de tráfico. Por defecto no escribe nada sobre tus conexiones en el disco. Solo mantiene en memoria la hora del último handshake y tu endpoint actual, que ves con wg show - y eso se borra al reiniciar. Así que la capa de la VPN ya está limpia.
• El sistema operativo es la parte ruidosa. El journal de systemd (journald) registra los eventos de los servicios. Si rsyslog está instalado también escribe archivos de texto plano como /var/log/syslog y /var/log/auth.log - y auth.log registra absolutamente cada inicio de sesión SSH. Archivos aparte (wtmp, btmp, lastlog) llevan la cuenta de quién inició sesión y cuándo, y tu shell mantiene un ~/.bash_history.
• Y algunas rutas más silenciosas hacia el disco. Si el servidor tiene swap activado, el kernel puede volcar páginas de RAM - claves incluidas - al disco. Un programa que se cuelga puede dejar un core dump de su memoria. Y el gestor de paquetes escribe registros de actualización en /var/log/apt. Una configuración minuciosa cierra también estas rutas.

El límite honesto: qué puede y qué no puede hacer el sin-logs

Antes de tocar nada, ten claro qué estás comprando en realidad. Desactivar los logs impide que tu propio servidor guarde registros - así que si el disco alguna vez es incautado, copiado o leído por alguien que consigue entrar, hay mucho menos que encontrar. Esa es una ganancia real y valiosa.

Lo que no hace es ocultarte de la empresa que te alquila el servidor. Tu proveedor de VPS siempre sabe que existe una máquina en esa IP, puede ver cuánto ancho de banda mueve y podría en principio observar el tráfico a nivel de red o de hipervisor - ningún ajuste dentro de tu servidor cambia eso. El sin-logs consiste en minimizar tu propia huella, no en volverte invisible para el anfitrión. Elige un proveedor con el que te sientas cómodo, y trata los pasos de abajo como una reducción del riesgo, no como su eliminación.

El sin-logs no es una garantía de anonimato. Dos límites que ningún ajuste del servidor puede cambiar:

• Tu proveedor ve las IP que se conectan. El contenido está cifrado, pero pueden ver que tu IP doméstica llegó al puerto de WireGuard, y cuándo.
• Tu proveedor puede capturar la RAM. Un VPS es una máquina virtual; el anfitrión controla el hipervisor y puede capturar la memoria en vivo (las claves activas de WireGuard y los peers conectados) y puede ser obligado a entregarla a la policía ante una solicitud legal válida.

En resumen: eres dueño del software, no de la máquina. El sin-logs reduce tu riesgo, no lo elimina.

Paso 1: Mover el journal de systemd a la RAM

Primero, dile a journald que mantenga su journal solo en memoria, para que nunca aterrice en el disco y desaparezca en cada reinicio. Abre su configuración:

nano /etc/systemd/journald.conf

Bajo la sección [Journal], establece estas dos líneas (quita el # inicial si está presente):

[Journal]
Storage=volatile
RuntimeMaxUse=16M

Aplícalo y el journal ahora vive en /run (RAM), limitado a 16 MB y desaparece al reiniciar:

systemctl restart systemd-journald

Paso 2: Poner todo /var/log en la RAM

El journal ya está en memoria, pero varias herramientas siguen dejando archivos de texto plano en /var/log - rsyslog, el auth.log que registra los inicios de sesión SSH, los registros de actualización de apt y los registros de sesión wtmp/btmp/lastlog (que se reescriben en cada inicio de sesión, así que simplemente borrarlos no sirve de nada). El arreglo limpio y universal es montar todo el directorio /var/log como un tmpfs - un sistema de archivos respaldado por RAM que se borra en cada reinicio. Añade una línea a /etc/fstab:

echo "tmpfs /var/log tmpfs defaults,noatime,nosuid,nodev,mode=0755,size=50M 0 0" >> /etc/fstab

Ahora todo lo que hay bajo /var/log vive en memoria y se vacía en cada reinicio. Reinicia una vez para que los servicios en ejecución reabran sus archivos de log dentro del nuevo disco RAM:

reboot

Paso 3: Desactivar el swap

Si el servidor tiene swap activado, el kernel puede empujar páginas de RAM - posiblemente incluyendo claves activas - al disco cuando la memoria escasea. En una máquina sin logs quieres que la memoria se quede en la memoria. Desactiva el swap ahora y mantenlo desactivado tras los reinicios:

swapoff -a
sed -i.bak '/\sswap\s/s/^/#/' /etc/fstab

Muchos VPS pequeños vienen sin ningún swap - en ese caso swapoff -a simplemente no hace nada, lo cual está bien.

Paso 4: Desactivar los core dumps

Si un programa se cuelga, systemd-coredump puede escribir un core dump - una instantánea de la memoria de ese programa - en el disco, bajo /var/lib/systemd/coredump/. Desactívalo:

mkdir -p /etc/systemd/coredump.conf.d
printf '[Coredump]Storage=none' > /etc/systemd/coredump.conf.d/99-nolog.conf
systemctl daemon-reload

Paso 5: Desactivar el historial del shell y del editor

Tu shell guarda cada comando en ~/.bash_history, y los editores dejan sus propios rastros (~/.viminfo, ~/.lesshst). Apúntalos a todos hacia /dev/null para que nunca se escriba nada. Para el usuario actual:

ln -sf /dev/null ~/.bash_history
ln -sf /dev/null ~/.viminfo
ln -sf /dev/null ~/.lesshst

Luego evita que bash mantenga un archivo de historial para cada shell de inicio de sesión del sistema, de modo que otras cuentas queden cubiertas también:

printf 'unset HISTFILEexport HISTSIZE=0' > /etc/profile.d/00-nohistory.sh

Si tienes otras cuentas de usuario, repite las tres líneas ln -sf también para cada uno de sus directorios de inicio.

Paso 6: Mantén activa la protección contra intrusiones - no estás a ciegas

Un mito común es que desactivar los logs te deja indefenso. No tiene por qué ser así. fail2ban - la herramienta que banea una IP tras repetidos inicios de sesión fallidos - puede leer directamente del journal de systemd, que ahora vive en la RAM. Así mantienes la protección automática contra fuerza bruta sin escribir nada en el disco. Instálalo:

apt install fail2ban -y

Apúntalo al journal creando /etc/fail2ban/jail.local con:

[DEFAULT]
backend = systemd

Luego reinícialo y, además de eso, cierra las puertas obvias:

systemctl restart fail2ban

• Solo claves SSH. Desactiva el inicio de sesión con contraseña en /etc/ssh/sshd_config (PasswordAuthentication no) y reinicia ssh. Una clave no se puede adivinar como una contraseña.
• Firewall cerrado por defecto. Mantén ufw permitiendo solo SSH y tu puerto de WireGuard (51820/udp), todo lo demás denegado.
• Actualizaciones de seguridad automáticas. Instala unattended-upgrades; sus logs ahora viven en el /var/log respaldado por RAM, así que también desaparecen al reiniciar.

Paso 7: Verificar que nada persiste

Reinicia una vez más, vuelve a iniciar sesión y comprueba las cuatro cosas que cambiaste:

mount | grep /var/log
swapon --show
journalctl --no-pager | wc -l
ls -lh /var/log

Deberías ver /var/log montado como tmpfs, sin swap activo, un journal casi vacío y un /var/log nuevo y casi vacío. A partir de aquí el servidor prácticamente no guarda nada en el disco sobre lo que pasa a través de él.

Cuándo podrías querer conservar algunos logs

El sin-logs no es automáticamente lo correcto para todo el mundo. Si el servidor hace más que ejecutar tu VPN personal - aloja un sitio, gestiona el tráfico de otras personas - quizás quieras un poco de historial para detectar problemas. Buenas noticias: la configuración de arriba ya mantiene logs a corto plazo en la RAM (en el journal y en el tmpfs /var/log), así que obtienes visibilidad durante la misma sesión sin escribir nada permanente en el disco. Si necesitas más, sube RuntimeMaxUse en el Paso 1 o el size del tmpfs en el Paso 2. Ajusta la agresividad a cómo usas la máquina en realidad.