Archivo de la etiqueta: enrutamiento

Distribuciones para seguridad y servicios de red

Posted on por
Responder

Que la seguridad es un elemento clave en cualquier entorno sea en infraestructuras de comunicaciones, informática o entornos industriales es algo que a esta altura del partido nadie se cuestiona.  Controlar el acceso a la red, los ficheros, gestionar los permisos y derechos de los usuarios, cifrado de comunicaciones, filtrado de contenidos, etc. etc. son algunas de tantas medidas que podremos adoptar para garantizar una seguridad global y proteger así nuestra información.

Como es costumbre no voy hablar de las configuraciones que nos ofrecen los Sistemas Operativos o aplicaciones sino que nos ceñiremos, como siempre, a las comunicaciones. Desde este punto de vista los firewalls e IDS/IPS juegan un papel clave. Deberemos empezar por tener muy claro dónde situarlos para proteger unos u otros segmentos de red en función de lo que allí tengamos. Mientras que los Cortafuegos permitirán o denegarán el tráfico dirigido equipos que prestan algún tipo de servicio; los IDS/IPS se encargarán de analizarlo y detectar posibles patrones de ataques o “movimientos” hostiles en nuestra red. Y si es posible, tomar alguna medida para bloquearlo.

Cada uno de nosotros tenemos una disciplina profesional definida, lo cual no quita que tengamos que saber de otras que circulan a nuestro alrededor. Todo lleva un aprendizaje previo, y con él un tiempo que puede no tengamos, al menos, para especializarnos todo que quisiéramos. Da igual si hablamos de tecnologías, comunicaciones, sistemas, aplicaciones, entornos,… todo lleva lo suyo. Por no hablar de las soluciones propietarias de fabricantes, que si Cisco saca tal o cual prestación, Juniper hace algo parecido con distinto nombre, etc. etc. vamos, la historia de nunca acabar.

Para facilitarnos las cosas, por suerte, existen algunos proyectos e iniciativas con los que podemos contar para que, con una menor inversión de tiempo y conocimientos, podamos acceder a ciertos sistemas, aplicaciones y funcionalidades. Tal es el caso de las distribuciones con un conjunto de herramientas dispuestas a cumplir con un fin concreto. Así como dentro del mundo de la seguridad y pentesting tenemos a “Kali” existen otras, las cuales están orientadas a la seguridad o servicios de red, que presento a continuación.

Firewalls

SmoothWall Firewall

M0n0wall

BrazilFW, Firewall and Router

IDS

SmoothSec

EasyIDS

Monitorización de redes

FAN, Fully Automated Nagios

Seguridad de redes

NST, Network Security Toolkit

Router

BSD Router Distribution

En el siguiente enlace os dejo un listado que podréis encontrar en Wikipedia donde se incluyen bastantes más, algunos incluso descontinuados. Pinchar aqui.

Almacenamiento

FreeNAS

Openfiler

Aparte de la facilidad de su despliegue y su uso gracias a sus interfaces gráficas, otra de las ventajas a destacar es su costo. Al estar basados en software libre, se hacen propicios en entornos donde no se cuente con recursos económicos para adquirir otro tipo de soluciones comerciales, o incluso sustituirlas según sean los casos. Pensemos, por ejemplo, en una PYME que pueda reutilizar un equipo reemplazado y que dotándolo con unas tarjetas de red adicionales pueda convertirse en un cortafuegos, router, web proxy, servidor VPN, o lo que sea. Lo que quiero decir es que no necesitamos invertir una cantidad de dinero más o menos considerable para garantizar la seguridad sino que además no tenemos que renunciar a ella en caso de no disponer de un capital para adquirir algún producto de los tantos que hay en el mercado.

En fin, bien por falta de tiempo o recursos económicos, no tenemos porqué perder unos servicios o funcionalidades en nuestras redes de datos. Tenemos a nuestra disposición un gran número de distribuciones, que sin tener un conocimiento exhaustivo de los sistemas sobre los cuales están basados, pueden cumplir con nuestras necesidades.

Otros modelos…

Posted on por
4

Para que nuestra red “funcione” y se comporte de la manera que necesitemos, no sólo tendremos que configurar e interconectar los equipos de la manera que más se ajuste a nuestros requerimientos, sino hacerlo siguiendo el mejor modelo. Cada organización, empresa o cualquiera que tenga una infraestructura de comunicaciones tendrá los suyos propios, con lo que establecer un patrón genérico puede a veces no ser lo más idóneo.

Por ejemplo, muchos de nosotros se nos ha enseñado la idea de que una red está compuesta por 3 capas, “Acceso”, “Distribución” y “Core”. Obviamente debe existir una jerarquía  y una segmentación de las funciones pero, no siempre puede darse esta estructura. Os dejo un par de imágenes que representan esta idea:

Como digo, todas las organizaciones pueden no necesitarlo, y es más, con los tiempos que corren los recursos económicos no son los suficientes como para invertir en tanto equipo. Por eso, puede darse el caso como el que os traigo.

Lo que vamos a  hacer, es unir tanto la capa de “Core” como la de “Distribución”, con switches de Capa 3 y definiendo interfaces virtuales. Os dejo en enlace donde podréis ver un artículo donde hablaba de ello, pincha aquí.

¿Por qué esto? Bueno puede haber distintos motivos. El primero de ellos es que directamente no sea necesario; otro que al eliminar una de las capas, eliminamos los equipos que están en ella, y por tanto es menos dinero a invertir. Otra es que los equipos de hoy en día traen consigo muchas funcionalidades (Protocolos, configuraciones, medidas de seguridad, etc.) y capacidades (velocidad de conmutación,  densidad de puertos, etc.) comunes a ambas capas y por tanto no hacen necesario segmentarlo de esta manera. Sin embargo no todos son ventajas, y deberemos por tanto ser cuidadosos a la hora de diseñar la red. Es decir, si suprimimos una capa, podremos penalizar la escalabilidad.  Como todo, antes de hacer nada deberemos pensar muy bien lo que hacemos y analizar todas las necesidades de deba cumplir, a corto y medio plazo, nuestra infraestructura y los requerimientos que debamos ponerle a nuestros equipos.

Así pues a continuación ilustro este concepto de “unión”.

Como podemos ver, se colapsan las dos capara de “Core” y “Distribución”. Es un entorno que ofrece redundancia entre los equipos de acceso situados en la parte inferior de la imagen y los servidores en la superior. Tras haber evaluado las características de los equipos, éstos soportan protocolos de alta disponibilidad como HSRP, VRRP, STP, etc; también disponemos de enlaces redundantes tanto desde los switches de acceso, sw-of-01, así como como entre switches de Core/Distribución que nos proporciona una tolerancia ante fallos. Contando de que éstos tengan puertos a 1 Gbps podremos agregar enlaces (Etherchannel) para vencer posibles cuellos de botella al conectar más switches de acceso; también podremos implementar “Listas de Control de Acceso” (ACLs); y como no, al ser equipos de L3 configurar algún protocolo de enrutamiento (OSPF, EIGRP) o enrutado manual (ip route XXX.XXX.XXX.XXX ….) para el envío de pquetes.

Lo que se trata de hacer ver es que podremos llevar a cabo otras topologías, al margen claro está, de que los modelos “genéricos” no sean la mejor opción para posibles implementaciones a las que tengamos que hacer frente. Eso deberemos conocer y tener en cuenta todas las funcionalidades que los equipos y tecnologías nos ofrecen, sus costes y alternativas de fabricantes.

 Nos vemos en la próxima!!!

Aegurando el enrutamiento Parte III

Posted on por

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.