Dado que aprovechar la inteligencia artificial para tareas sencillas es imposible sin una supercomputadora (o muchas supercomputadoras), volvemos a los orígenes con un nuevo plan de mejora para las VPS. Contamos con WireGuard, lo hemos pulido hasta que funciona con el ancho de banda completo. Vamos a confiar un poco más en el para administrar los servicios que tenemos expuestos por internet… ¡En privado!

Introducción

La idea es simple y se basa en la siguiente premisa: «¿Si soy el único que usa los logins y demás sistemas de autenticación, ¿para qué tengo que dejarlos al aire para que todos los días estén dale que dale tratando de hackearlos por fuerza bruta los Crawlers de Internet? Así que la idea es simplemente negar el acceso a los sistemas de autenticación a la red expuesta a Internet y dejarla solo para la red local o la red de WireGuard. Así que en teoría, lo que se necesita es lo siguiente:

• Crear una red WireGuard.
• Crear un servidor DNS para la red WireGuard ←Estamos aquí
• Configurar el DNS para que solo funcione en la interfaz de WireGuard
• Configurar un servicio para que trabaje en la interfaz de WireGuard
• Limitar los accesos a áreas públicas por la interfaz de red
• Limitar los accesos a áreas de autenticación solo a la red de WireGuard

Todo esto se me ocurre en el contexto de que tengo un servidor NextCloud que trabaja en público y a diario tengo crawlers intentando entrar. La solución simple es fácil. Ya que ahora trabaja mediante WireGuard, puedo agregar la IP de la VPN y usarla de forma privada. No es gran problema excepto porque me interesa que se mantengan las funciones públicas, como los enlaces compartidos, las agendas de calendarios y alguna cosa que se me antoje por ahí.

En ese sentido, la complejidad aumenta bastante porque no es solo desconectar de la interfaz pública, sino también elegir las rutas que dejarán de ser accesibles por Internet y que estas sean accesibles por la red WireGuard.

Si la teoría es posible, me gustaría poder aplicar esto a más servicios en los que soy el único que se autentica, como por ejemplo este blog. Por esa razón, vamos a necesitar la ayuda de un DNS local exclusivo para WireGuard.

Agregando Reglas Nginx

Para empezar, tomaré como modelo mi servidor de Nextcloud, puesto que no necesito hacer mas maromas para lograr lo que quiero. Lo primordial será bloquear el acceso de las rutas de autenticación a través de Internet. Para eso vamos viendo como están los logs.

Como se puede ver en la imagen, hay varios intentos de acceso por la url login, pero un montón de escaneos de directorios (debo mejorar las reglas de fail2ban) Ya he descontado mis propios accesos y también del monitor uptime.

Lo primero es agregar las reglas apropiadas para limitar el acceso a la ruta /login

Hay que recordar que NextCloud tiene una regla que redirecciona el trafico no autenticado desde el directorio raíz al directorio /login, por lo que si tienes algo monitorizando esa ruta, disparará la alarma de inmediato.

location /admin {
    allow 10.0.0.0/24; # Tu red de WireGuard
    deny all;          # Bloquea al resto del mundo
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/var/run/php/php8.4-fpm.sock; # Ajusta a tu versión de PHP
}

Recuerda cambiar la ruta que quieres bloquear. en el caso de NextCloud, la ruta es /login

Apenas aplicas los cambios con systemctl restart nginx ya notaras el cambio al acceder al login desde Internet.

Por supuesto, esto nos deja pateados afuera. Pero puedes acceder a Nextcloud mediante la VPN normalmente. Aunque faltan hacer algunos ajustes todavía.

Un DNS personal

Si dejamos esto hasta aquí, nos encontraremos con que Nextcloud desconfía de nosotros.

Esto es normal y bastaría con agregar la ip de tu servidor como dominio de confianza, pero queremos tener más servicios con la autenticación escondida. Y eso que no estamos contando que los servicios que dependen de SSL pueden dar conflictos al acceder solo por IP.

lo primero es instalar dnsmasq

sudo apt install dnsmasq

Dnsmasq es un software ligero y de código abierto diseñado para redes pequeñas, que actúa como servidor DNS (sistema de nombres de dominio) caché y servidor DHCP (protocolo de configuración dinámica de host). Proporciona servicios esenciales como la resolución de nombres locales y la asignación de IPs, siendo muy común en routers domésticos y entornos Linux.

Aunque puedes instalar esta herramienta en cualquiera de tus equipos de la red WireGuard, es recomendable instalarlo en la que hace de servidor.

Lo que vamos a hacer, es crear un servidor DNS intermediario, que reemplace las direcciones de tu dominio para que apunte a las redes locales de forma prioritaria. De esta manera, tu configuración de red normal va a seguir apuntando al Internet de siempre, pero con esta configuración, al encender wireguard, las consultas DNS se harán mediante dnsmasq, permitiendo poder acceder normalmente con la dirección de dominio anterior sin cambiar nada mas.

En la configuración de los clientes de wireguard debes poner ya la IP de tu servidor. Esto lo hace opcional pues cada cliente puede configurar sus cosas a gusto, asi que no estas forzando a nadie que no quiera.

Ahora, vamos a /etc/dnsmasq.conf

interface=wg0          # Escucha solo en la interfaz de la VPN
listen-address=127.0.0.1, 10.0.0.1
bind-interfaces        # Evita conflictos con otros servicios DNS
domain-needed          # No reenvía nombres sin punto (seguridad)
bogus-priv             # No reenvía IPs privadas a internet
# DNS públicos para lo que no sea tu red local
server=8.8.8.8
server=1.1.1.1

# No busques en el archivo de hosts de internet
no-hosts
# Pero SÍ usa este archivo que crearemos para tus dominios locales
addn-hosts=/etc/hosts.wireguard

Recuerda revisar tu archivo dnsmasq.conf por si estas lineas no están comentadas ya. Dado que es una instalación nueva, basta con agregar todo esto al final del archivo pues todo esta comentado.

Ahora tenemos que crear el archivo /etc/host.wireguard para agregar los dominios e ip que necesitamos

10.0.0.1  ://tu-dominio.com

y ya con esto, basta con reiniciar el servicio dnsmasq

systemctl restart dnsmasq

A partir de este momento, cuando ingreses a tu dominio con wireguard apagado, veras el mismo error 403 como todos. pero cuando lo hagas con wireguard encendido, veras tu instancia de Nextcloud completamente funcional.

Últimos Pasos

He estado describiendo estos pasos asumiendo que ya te has encargado de los problemas relacionados con SSL. Después de todo, si tienes un sitio web, seguro sale por https. Sin embargo, aunque la redireccion permite aprovechar las mismas credenciales que los servicios que quieres ocultar, en este caso en particular teniamos el siguiente esquema:

Internet → dominio publico/Nginx → WireGuard → servidor privado/Nginx

Por lo que tenemos que lidiar con dos servidores Nginx, asi que el paso que buscabamos ahorrarnos, pues nos lo tenemos que cargar.

Pero tampoco es para tanto.

SI ves las configuraciones de tu sitio publico, encuentras las rutas donde deben estar los certificados y tambien como habilitar https. basta con que copies los archivos en el mismo lugar de tu servidor privado. Entonces ya todo vuelve a quedar funcional y bonito.

Conclusiones

Digamos que esta serie de tutoriales serán un caso de «Sobreingeniería de la pereza«. Me gusta cómo están funcionando las cosas ahora, pero empieza a cansarme teniendo los crawlers ahí tocando la puerta todo el tiempo. Al hacer estos ajustes, puedo seguir como siempre sin tener expuestas las puertas de mis servicios y claro, tengo menos exposición a vulnerabilidades de las que no estén pendientes. Además, tampoco es necesario tener tanta cosa expuesta. Siendo el único que usa los servicios que estoy desplegando, tampoco es que me haga falta que más gente conozca dónde está la cerradura para intentar forzarla.

Aún estoy decidiendo cuál es el próximo servicio a ocultar, pero estoy entre WordPress y mi servidor de correo electrónico. Mi blog, aunque tiene códigos y funciones especiales, prácticamente es un sitio estático y en cuanto al correo, solo hace falta tener a postfix ahí escuchando los correos entrantes. Los salientes, ni siquiera necesitan un puerto abierto.

Actualización

Aunque aún no se ha publicado este post, he estado haciendo pruebas y viendo los resultados. Efectivamente el tráfico ha disminuido y a fail2ban solo le queda bloquear a toda IP que haga 404 o 302. El uso del VPS bajo muchísimo, así que se puede aprovechar el potencial extra en otras tareas. Pero ya sé cuál será el próximo servicio que oculte mediante este método.