Dado lo bien que salio el ejercicio anterior, vamos a probar aislar un servicio por completo para posteriormente, aislar parcialmente un servicio. En este caso, FreshRSS.

Introducción

En el caso anterior, lo que hicimos fue segmentar un servicio que ya era privado y del que solo queríamos un segmento específico atendiendo a Internet. Este proceso se llama «reducción de superficie de ataque». Este proceso permite cerrar las puertas que pueden intentar forzar para entrar y causarte daño, pero en mi caso es más como reemplazar la puerta por una pared. Te adelanto que tal vez esta técnica no aplique para todos los casos, así que numeraré unos cuantos para que veas si te conviene seguir el camino del ermitaño o continuar como ya estabas.

• Eres el único usuario de tus servicios e infraestructura. Es decir, montaste un servicio público por alguna necesidad puntual como, un lector RSS que puedas alcanzar desde cualquier parte de Internet o algún servicio de notas o algún servicio de sincronización.
• Quieres tener control de tu infraestructura por una «puerta trasera» Suena feo, pero es cuestión de seguridad. No necesitas que todo el mundo esté tocando a la puerta todo el tiempo si eres el único que tiene la llave y el único que puede (y debe) entrar.
• Quieres tener un terreno seguro de juego mientras desarrollas tus cosas. No necesitas desplegar SSL en un entorno privado. Eso facilita muchas cosas.

En ese sentido, reducir la superficie de ataque puede ayudarte a no tener que preocuparte tanto por vulnerabilidades, pero puede complicar un poco la administración. Además claro, tienes que confiar en servicios que pueden caer y dejarte aislado de todo.

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 expuesta a 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
• 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

Mira tú, ya tenemos casi todo completo y ahora solo falta ir resolviendo los casos particulares.

Cambiando puertas por paredes

En este ejercicio vamos a bloquear por completo el acceso y uso publico de un servicio que no necesita mas visitas que las mías. En este caso, FreshRSS.

Esta vez no comparto los logs porque realmente hay poco trafico basura que mostrar.  La cosa es muy distinta cuando intente bloquear parcialmente el wp-admin y ya verán por que.

Como esta vez el dominio es distinto del equipo de origen, tendremos que hacer algunos ajustes. Recuerda que esto es parte de un tutorial anterior.

Agregamos nuevas reglas a Nginx para que solo permita el acceso desde la interfaz de Wireguard

Al principio del archivo de configuración de nginx:

1
2
3
4
5

map $remote_addr $es_vpn {
    default 0;
    "~^10\.0\.0\." 1;  # Esto usa una expresión regular para atrapar a cualquiera que empiece con 11.0.0.

}

Dentro de tu regla server

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

           # 1. REGLA ESPECIAL PARA AJAX (WordPress la necesita pública)
           location = /wp-admin/admin-ajax.php {
               include fastcgi_params;
               fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
               fastcgi_pass unix:/run/php/php8.4-fpm.sock;
           }
       
           # 2. BLOQUE ÚNICO PARA TODO PHP (Incluye la seguridad VPN)
        location ~ \.php(?:$|/) {
            # 1. Definir una variable de control
            set $permitido 0;
        
            # 2. Si es la VPN, sumamos 1
            if ($es_vpn = 1) {
                set $permitido 1;
            }
        
            # 3. Si NO es zona restringida (o sea, es el front del sitio), sumamos 1
            if ($uri !~* "(wp-admin|wp-login)") {
                set $permitido 1;
            }
        
            # 4. Si después de ambas comprobaciones sigue en 0, es que es zona restringida Y NO es VPN
            if ($permitido = 0) {
                return 403;
            }

Esta acción genera un error 403 para todos los directorios del dominio. Es justo lo que buscamos. Ahora tenemos que editar en el archivo que creamos antes. el hosts.wireguard para cambiar las rutas y dominios.

10.0.0.2 freshrss.misitio.com #la ip en la red wireguard de tu servicio

Y ejecutas el systemctl restart dnsmasq y listo. Como puedes ver, esta vez tuvimos que hacer muchos menos pasos y recuperamos, esta vez de forma exclusiva, el acceso a nuestra pagina de lector de RSS.

Debido a que el firmado SSL no se encuentra fuera del servidor, esta vez no tenemos que mover nada mas. Lo tendremos firmado apenas lo abrimos.

Conclusiones

Esta vez logramos hacer esta tarea mucho mas rápido y metiendo menos código. Para este ejercicio, la verdad pensaba que iba a ser mas sencillo y funcionar a la primera con un simple deny al directorio correspondiente, pero como puedes ver, es un monton de lineas de codigo. Esto es porque tras algunas pruebas descubrí que si bien bloqueaba efectivamente al Internet abierto, en la VPN dejaba libre como esperabamos, pero dejaba de procesar el archivo php, devolviendo un wp-login.php en texto plano. Es decir, cualquiera que estuviera en tu VPN iba a poder ver los archivos PHP de tu servidor. Pero solo los que bloqueamos, claro. Tras algunas practicas, finalmente llegue a esta conclusion y creo que es la mas funcional. Lo sigo revisando por si hay alguna sorpresa, pero parece muy funcional.

¿Sobre los resultados de esto? han pasado varias semanas desde que lo implementé. Parece que si el servidor responde con 403, los crawlers llegan a cansarse y dejar de insistir. En el caso del log de hoy, solo hay un intento de acceder. mientras que para el día de ayer, solo fueron 4. Parece funcionar, ¿no?

Estoy cuestionándome un poco sobre la practicidad de esto, puesto que si desplegaste Freshrss en una VPS o hosting, es probable que haya sido por lo práctico que es tener el lector unificado y accesible desde cualquier parte de Internet. En ese sentido, podrías elegir tener un lector local en tu dispositivo, pero esto es una práctica y vamos a hacer estas locuras hasta encontrarle un uso práctico. En próximas entregas ya hablaremos de un uso más serio, segmentando un sitio con más tráfico para probar y ver resultados.