En el último post hemos visto la teoría de cómo se guarda la información en los logs. En fase de implantación de proyecto nos tocará ir analizando los logs para comprobar desde qué red a qué red nos conectamos, qué puertos son necesarios, etc. y poco a poco ir creando unas reglas lo más acotadas que podamos.
Como en mi entorno de pruebas tengo una infraestructura pelada pero necesitaba ruido para tener logs he dejado una regla «super recomendada» para un entorno productivo: un ANY ANY a cualquier puerto 😱
Lo he dejado un ratejo para ver qué sucedía… Os dejo una muestra al poco de encender la VM y levantarme a tomar un café.
Vemos en el log que tenemos acceso a diferentes Ips. Yo estaba con un café pero oye… alguien se estaba tratando de conectar a la Vm.
Tengo logs con diferentes puertos.
En fin… muchas conexiones con diferentes puertos.
Para diferenciar el ruido del ANY all IN. He creado otra regla para «poner en producción» 😉 RDP ANY ANY
Vamos a ver qué pasa. Me hice un amigo al poco tiempo que quería entrar «80.66.88.208«. Está bien esto de hacer amigos que con esto del teletrabajo se pierde el contacto humano.
Fíjate que en algunos no llego a pasar del B (begin) pero en otras hay cierto intercambios de bits B y luego E (End – fin de transferencia).
Finalmente dejé la regla de este modo.
Lo que hago es crear una regla con prioridad 101 para ver si me quito así al «80.66.88.208«. Pero lamentablemente se ve que el «amigo» comprobó que mi usuario/clave no estaba en su diccionario y no volví a verlo 🙁
Comprobé la Ip pública que me facilita mi proovedor en ese momento y pude ajustar la regla para que sólo me dejara pasar a mi. La regla 1000
https://www.cual-es-mi-ip.net/
En el log compruebo que soy yo quien entra por la regla «RDP» que acababa de crear.
La siguiente regla se llevaba todo el ruido de esas Ips «raras». Que en la Web me aparecián como Ips «amistosas» https://www.abuseipdb.com/
La mía no aparece en la BBDD de AbuseIp.
Con estas tres reglas hemos visto que primero intentamos «captar» al primer amigo. Como no coincide la Ip, se salta a la siguiente regla (que es mi ip pública) y como no aparece, se va a la regla de denegación.
La gestión de los NSG puede ser un poco aburrido pero es muy necesario. Lo de siempre, puertos de estos críticos lo mejor es no tenerlos expuestos. Y si necesitas conectarte a la VM, intenta hacerlo con una Vm de salto, Azure Bastion, abrir el puerto a demanda, etc.
Y bueno… hasta aquí la serie de post. Espero que con estos ejemplos haya quedado claro cómo funciona el sistema de prioridades de las reglas y el cómo podemos acudir al log del «NSG Flow» para comprobar qué está pasando realmente en nuestro entorno.
Nos vemos en el canal de telegram ☁
Deja una respuesta