Bueno ya estamos aquí con la tercera entrega, con algo de retraso pero llega. Como ya hemos visto el enrutamiento es fundamental en entornos corporativos pero también la correcta configuración del mismo. Vista la manera en la que nos pueden comprometer nuestras tablas de rutas y provocar un funcionamiento distinto al original, veremos la manera en la que podemos evitarlo.
Para empezar vamos a aplicar una idea fundamental, “Si algo no es estrictamente necesario para el funcionamiento, lo deshabilitamos”. De igual manera que la gente de sistemas deshabilita servicios, cierra puertos, etc. vamos a aplicarnos el cuento, y hacer lo mismo con el enrutamiento. Si éste se produce entre los switches de Core, en nuestro ejemplo CORE_OF_01, CORE_OF_02, CORE_SRV_01 y CORE_SRV_02; ¿para qué mandar actualizaciones hacia los switches de acceso como OF_01 si éstos no llevan a cabo enrutamiento? ¿Por qué mandar anuncios hacia ellos? El enrutamiento, hemos visto que se produce entre los de Core, con lo que no deberían propagarse más allá de ellos ya que no es necesario. Por tanto, accedemos a la configuración del protocolo en cuestión y deshabilitaremos dichos anuncios.
core-of-01#conf t
core-of-01(config)#router ospf 1
core-of-01(config-router)#passive-interface vlan 10
Con el commando passive-interface lo que vamos a conseguir es que se no se envíen actualizaciones del protocolo con lo que en nuestro caso la aplicación “Loki” no podrá capturarlas y por lo tanto nuestro atacante obtener la información sobre nuestras redes y posterior posible inyección de rutas. En esta ocasión la hemos aplicado a una interfaz virtual.
Otra opción es habilitar la autenticación entre interfaces que participan en el enrutamiento. Esto es, emplear un secreto compartido entre ellas, necesario para procesar el paquete con la información recibida. Podremos elegir entre una autenticación simple, en la que el secreto compartido va implícito en texto plano dentro de dicho paquete o bien emplear algún algoritmo que en lugar de éste enviará un hash que deberá ser recalculado en destino, y si coincide con el enviado, se procesará.
En nuestro caso emplearemos esta segunda opción siendo el algoritmo MD5. Para ello en primer lugar habilitaremos la autenticación en el protocolo para las áreas que deseemos. En nuestro caso el área 1:
core-of-01#conf t
core-of-01(config)#router ospf 1
core-of-01(config-router)#area 1 authentication message-digest
El siguiente paso será habilitar la autenticación para las interfaces implicadas en el enrutamiento. Como hemos dicho con anterioridad estamos empleando interfaces virtuales con lo que:
core-of-01(config)#interface vlan 20
core-of-01(config-if)#ip ospf message-digest-key 1 md5 edorta
De aquí queda por decir que el “1” hace referencia al identificador de la contraseña; MD5 al tipo de algoritmo de hashing, y “edorta” la contraseña en sí. Obviamente la contraseña debe ser la misma que en nuestro router vecino.
Parece sencillo pero habrá quien no lo implemente y luego vengan los disgustos. Son pocas líneas, pero necesarios para proteger nuestra red, a los usuarios y sobre todo la información que viaje por ella y que éstos utilizan.
Un saludo y seguiremos informando.
