He decidido terminar este artículo, que lleva en borradores desde hace ya varios meses, debido principalmente a la recién descubierta vulnerabilidad de Ubiquiti relacionada con el puerto 10001, que permite la ejecución de un ataque DDoS debido a la “amplificación” de datagrama UDP (más info -> https://www.zdnet.com/article/over-485000-ubiquiti-devices-vulnerable-to-new-attack/).

Desde hace no mucho, los equipos de Ubiquiti y Mikrotik se popularizaron tanto que prácticamente cualquier persona lo usa para los más diversos motivos: crear pequeños enlaces de radio, sustituir al router por defecto que instala la operadora, levantar túneles VPN… en definitiva, todas las aplicaciones que se nos pasen por la cabeza, todo gracias a su precio económico y facilidad (!) de configuración, algo válido tanto en el ámbito profesional como en el doméstico.

Incluso, a raíz de su gran versatilidad y prestaciones han surgido nuevas líneas de negocio, como lo somos los WISP, donde usando estos equipamientos hemos conseguido llevar el acceso a Internet a zonas donde  parecía imposible, y en muchas ocasiones, compitiendo de tú a tú con grandes operadoras.

Son varias las personas que me han pedido que les ayude a securizar un poco sus instalaciones, a lo que inicialmente me remito al documento redactado por mi amigo David Vaello y que puedes descargar en este enlace o bien, leer el post que se publicó en este mismo blog hace algún tiempo sobre seguridad en Mikrotik.

En este sentido, mi filosofía personal es la de “si no quieres que lo toquen, escóndelo“. Manteniendo ese principio en mente, las medidas básicas a tomar para minimizar situaciones de riesgo, es evitar que, ni nuestros clientes ni un atacante externo puedan si quiera “oler” nuestro equipo, o al menos, no tengan acceso de ninguna manera a interfaces administrativas.

Para ello, os doy algunos tips para llevarlo a cabo:

UBIQUITI

He decidido empezar con mi marca favorita simplemente porque me han llegado a decir que con AirOS no se pueden tomar excesivas medidas de seguridad porque no lo permite (¡falso!), además que tampoco he encontrado ningún texto que hable sobre seguridad bajo AirOS aparte del documento oficial de buenas prácticas de Ubiquiti, así que, desde aquí quiero mostraros unos pequeños trucos que seguro que os irán bien.

Los dispositivos con AirOS v5 fueron objeto de un ataque importante en 2016 debido a una vulnerabilidad. Las consecuencias de estos ataques se podrían haber evitado o al menos, atenuado, siguiendo unas sencillas precauciones. A continuación, enumero algunas que considero importantes.

ASEGURANDO NUESTRO DISPOSITIVO AirOS

  1. Definir una gestión aislada de la red de clientes. Esto se consigue usando una VLAN a la que sólo tengamos acceso nosotros, como administradores de la red que somos.
    Para ello es necesario crear una VLAN asociada a la interface WLAN0 y configurar esa interface como interface de gestión. Aquí podemos elegir entre fijar una IP estática local de gestión a cada CPE (esto es engorroso y difícil de mantener),  o bien, definir un cliente DHCP para dicha interface VLAN. Es importante bloquear el acceso a la gestión desde la interface WAN (ya sea la WLAN o PPP) y definir esta VLAN que acabamos de crear como interface de gestión.   

     

    ¿Qué es lo que he hecho?
    · He creado una VLAN con ID 500
    · He bloqueado el acceso desde la WAN
    · Se ha añadido la interface de gestión WLAN0.500 (es decir, nuestra VLAN 500) y se ha configurado como cliente DHCP.


    Evidentemente, en el extremo remoto se debe configurar igualmente esa VLAN sobre la interface de servicio a clientes, un servidor DHCP y enrutar esa red para que sea accesible desde nuestro NOC.

  2. Cambiar los puertos por defecto. Esto en sí mismo sólo nos protegerá en cierta medida de ataques automatizados o escaneos sobre puertos conocidos, realmente no es una medida eficaz contra un atacante que va decididamente contra nosotros, pero como aquí la idea es poner tantas trabas como sea posible, nunca vendrá de más.
    Los puertos en AirOS se cambian en SERVICES, y es recomendable poner puertos aleatorios para HTTP, HTTPS  y SSH. Evidentemente, es importante no activar nunca el Telnet (recuerda que Telnet es un protocolo en el que va en texto plano, sin cifrar).  

     

  3. Restringir el acceso al CPE en la parte LAN. Puede ocurrir que el atacante sea incluso un cliente: conozco un caso de un atacante que contrató el servicio de su competencia para atacar “desde dentro”, pero esa es otra historia.
    Esto es un poco más difícil, o más bien imposible de impedir, pero siempre podemos usar las reglas de Firewall del CPE y restringir el acceso al mismo a una LAN distinta y desde una IP concreta. Es decir, hablamos de crear una red de gestión LAN separada de la red de cliente. La estrategia es la siguiente:  

     

    – Versión 1.:
         · DROP a todo con protocolo TCP con destino a la IP LAN de nuestro CPE, EXCEPTO (!) la IP que llamaremos “IP del Técnico” y puerto de destino el que hayamos definido, una que definiremos previamente y que el cliente no debe conocer. Evidentemente, esto es una medida muy light, y que podemos complicar aún más si añadimos una VLAN… lo malo es el equilibrio entre facilidad de uso / seguridad… complicándolo todo demasiado.

    En el siguiente ejemplo, la IP del CPE es la 192.168.1.1 y la IP autorizada (“IP del técnico”) es la 192.168.1.222.
    Por descontado, es buena idea que el DHCP del lado del cliente nunca ofrezca la IP .222

    – Versión 2.:
         · Creamos una nueva LAN con un rango IP diferente. En este ejemplo he escogido 192.168.1.1/24 para la LAN de cliente y 192.168.2.65/30 para la “LAN de gestión”.
         · Creamos una regla de firewall que bloquee el acceso al CPE desde cualquier IP de la LAN de cliente.

    Con lo anterior lo que hemos conseguido es que sólo se pueda acceder al CPE (192.168.2.65) desde la IP 192.168.2.66. Es una red que no tiene acceso a internet (no hay NAT hacia la WAN).Evidentemente, esto no puede considerarse un auténtico método de seguridad… simplemente evitamos intentos de acceso por parte del cliente e incluso, nos protegerá en buena medida de ataques automatizados.

  4. Bloquear en tu router de borde el acceso al puerto 10001 desde el exterior. Quizás no eras consciente de esto, y deberías ir corriendo a resolverlo: Ubiquiti usa el puerto 10001 para mostrar cierta información de utilidad, usada principalmente por AirControl y UNMS. A través de él se puede acceder a información muy sensible del CPE, como la MAC address, la IP de la parte LAN y su MAC, el nombre de host (aquí el tema se pone serio), la referencia del producto y ¡TACHAN! la versión de AirOS.Veamos los dos que, a mi juicio, son los más delicados:

    · HostName.: La mayoría de los WISP usamos el campo “Device Name” en la pestaña SYSTEM de AirOS como campo para poner el nombre del cliente. Esto la verdad es que ayuda mucho, sobre todo al ver los CPEs registrados en una BS o bien, en los mismos AirControl y UNMS antes mencionados. Hay también quien pone el DNI y/o una combinación de Nombre y DNI. El problema es que si nuestro cliente tiene IP pública, cosa que es bastante habitual hoy en día, esa información que a priori es PRIVADA, está accesible desde internet.

    · Version.: aquí viene otro tema delicado, y es que vemos la versión del CPE. ¿Cuál es el problema? que básicamente podemos tirar de base de datos de exploits para fallos conocidos y un atacante malicioso puede aprovecharse. Este problema viene magnificado por la existencia de herramientas online como SHODAN (si no la conocéis, ya estáis tardando) que permiten buscar por múltiples parámetros… si no, probadlo. En mi caso, si lanzo una búsqueda limitada a España con el puerto 10001 abierto, ¡me salen más de 54.000 equipos!. De todas formas, tened en cuenta que ese puerto es usada también por un sistema de SCADA de gasolineras… (hay muchas en las que se pueden ver los niveles de los depósitos, su temperatura y…. bueno, ese es otro tema).En el siguiente listado veréis un pequeño resumen de equipos visibles desde shodan, es decir, con el puerto 10001 abierto. En todos y cada uno de esos 54K equipos se puede ver el HostName, version, MAC, IP Lan… todo lo citado anteriormente.

Aquí tenéis un ejemplo de un equipo con IP pública de los que aparece en el listado anterior, donde se puede leer el nombre completo del cliente y vemos, por si esto fuera poco, que se trata de una versión de AirOS vulnerable:

Un punto importante en toda esta ecuación es considerar la complejidad de la contraseña. Es curioso pero casi todos tenemos por costumbre cambiar el usuario por defecto (ubnt) por “admin”, esto es algo que es contraproducente y que también debe cambiarse: evitad el uso de “admin”, “root”, “administrator” y similares, escogiendo algo más esotérico e improbable (pero que seamos capaces de recordar). Usar ese tipo de usuarios estándar supone facilitar la mitad del trabajo a un atacante que utilice la fuerza bruta para reventar nuestra seguridad.

He dejado para el final algo que para mi es obvio: mantener actualizado el firmware de nuestros equipos, tanto los CPE como los equipos de nuestra propia red (routers, enlaces, cobertura). El mantenerse actualizado no sólo nos protege ante posibles problemas de seguridad, sino que además nos aporta en muchos casos mejoras, por lo que ¿cuál es la excusa para no actualizarse? decídmelo porque no veo razones para ello… incluso las actualizaciones masivas, aquellas que entiendo que más recelo pueden crear, se pueden hacer de forma escalonada, programada y fácil con AirControl en el caso de Ubiquiti.

En definitiva, para estar al tanto de las nuevas versiones de AirOS, es tan fácil como suscribirte al blog de Ubiquiti sobre nuevas versiones de firmware (https://community.ubnt.com/t5/airMAX-Updates-Blog/bg-p/Blog_airMAX), así permanecerás al tanto de las nuevas versiones cada vez que se publiquen.

 

MIKROTIK

Aquí el asunto se vuelve más delicado: con Mikrotik tenemos más vectores de ataque, tiene más servicios en funcionamiento y es más fácil cometer un error en la configuración que suponga una catástrofe importante. Os recomiendo leer el PDF que publicó David Vaello al respecto, que podéis descargar aquí, así como el post que se publicó en esta misma web hace ya algún tiempo.

Recuerda que Mikrotik no está exenta de fallos de seguridad, de hecho, sólo en 2018 han habido varios casos… quizás el más grave, o al menos el que más repercusión mediática ha tenido, el descubierto el pasado mes de Abril de 2018, donde se vieron afectados más de 200.000 routers Mikrotk. Aquí el más perjudicado fue un operador de ámbito nacional, en Brasil (más info), con unos 72K routers afectados en el pasado mes de Agosto de 2018 ¿os imagináis el tiempo que se tarda en acceder router a router para corregir el desastre y actualizarlos? no quiero ni pensarlo.

Adicionalmente a lo que comenta David en su PDF, sólo quiero añadir un par de ideas:

Puesto que normalmente Mikrotik se usa como router de borde y es justamente este el lugar donde un equipo está más expuesto a ataques, estas son las medidas que deberías tomar:

  • Restringe el acceso administrativo a las IPs desde la que lo vayas a gestionar y deniega el resto. De hecho, añade en un Address List cualquier intento de acceso no autorizado y hazle un DROP durante un tiempo.
  • Para acceder por WINBOX desde la interface pública, es conveniente configurar una secuencia de PortKnoking con al menos 3 puertos a tocar. Puedes aprender más sobre esto aquí: https://wiki.mikrotik.com/wiki/Port_Knocking
  • Igual que con Ubiquiti, insisto en la necesidad de cambiar los puertos para evitar ataques automatizados.
  • Cierra todo, ABSOLUTAMENTE todo lo que sea innecesario. Eso incluye el BandWidth server, que viene activado por defecto, aunque requiere autenticación y no tiene fallos conocidos… ¿para qué lo podrías necesitar expuesto hacia internet?. Si haces test de velocidad desde fuera, puedes también usar la técnica de PortKocking.

 

Al igual que con Ubiquiti, es fundamental estar al tanto de las nuevas versiones de RouterOS: para ello simplemente puedes seguir la cuenta oficial de Mikrotik en Twitter, donde generalmente avisan de las nuevas versiones.

Como podrás intuir, todo esto requiere una sobrecarga de trabajo importante, y no hablo de la implementación de estas medidas, sino en el trabajo del día a día . No obstante, te propongo un sencillo ejercicio mental: Qué tomará más tiempo ¿invertir unos minutos más en administrar la red? o bien ¿salir corriendo porque un ataque la ha tumbado completamente?. Creo que la respuesta es obvia: me quedo con la primera opción.

 

Para terminar sólo me falta aclarar que estoy muy lejos de ser un experto en seguridad, tampoco lo pretendo: simplemente he querido tratar aquí un tema de interés general, proponiendo algunas ideas para evitar dejar la red expuesta a atacantes y minimizar las posibilidades de ocasionar un desastre.

 

Espero que mi experiencia te sea útil y apliques la información que aquí he querido compartir.

 

por Víctor De La Nuez

Artículo de: Víctor De La Nuez

Por overdrv