Archivo de la categoría: L3

Otros modelos…

Posted on por
4
Anuncios

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!!!

FWBuilder

Posted on por
Responder
Anuncios

Uno de los elementos que contribuyen a garantizar la seguridad en una red son los Cortafuegos (Firewalls). Estos equipos, básicamente,  permiten o deniegan, el tráfico en una red en función de unos parámetros dados que como norma general son las IPs de origen y destino, números de puertos (80, 443, 21, 22, etc.) y protocolos, generalmente TCP y UDP. Dependiendo de las características del Firewall en cuestión, éstos ofrecen otras funcionalidades adicionales como filtrado a nivel de aplicación (HTTP, FTP, DNS, etc.), creación de VPNs, etc.

Existen muchos fabricantes como Cisco, Juniper, Checkpoint, que ofrecen este tipo de equipos, pero independientemente de cualquiera de ellos,  diseñar, implementar y mantener una correcta y estricta política de filtrado de tráfico es vital para garantizar la seguridad de red.  Para poder llevar a cabo esta tarea los propios fabricantes disponen de herramientas propietarias para configurarlos, o incluso equipos específicos de administración.

Pero al margen de soluciones propietarias, GNU/Linux nos trae la herramienta iptables la cual nos permite no sólo filtrar el tráfico que pasa por el equipo sino además manipular los paquetes. Esta funcionalidad aparte de proteger equipos también nos puede servir para crear un firewall si a éste le añadimos varias tarjetas de red. Aquí os dejo un manual que explica muy bien esta funcionalidad, pincha aqui.

Como habréis podido ver, configurar las reglas tiene  los suyo sobre todo a medida que vamos añadiendo reglas y más reglas. Sin embargo existe una herramienta que nos puede ayudar mucho en esta tarea, y es FWBuilder. Con FWBuilder podremos crear reglas para distintas plataforma las cuales podremos consultar aquí.

En mi caso lo he probado sobre un Ubuntu 12.04 LTS, con lo que me he bajado el .deb correspondiente y gracias a la herramienta gdebi la he instalado.

Una vez instalada la aplicación, la abrimos y tendremos la siguiente ventana:

Para empezar a crear nuestra primera política pincharemos en “Create new firewall” apareciéndonos un asistente donde definiremos la plataforma. En nuestro caso iptables.

Luego nos pedirá definir las interfaces, paso que podremos saltarnos y hacerlo a posteriori si queremos. 

En la ventana encontraremos  distintos apartados. Por ejemplo en “Library” optaremos por “Standard” y “User”. En el primero tendremos predefinidos los servicios más utilizados en función sean en TCP o UDP. En “User” podremos definir aquellos que por una razón u otra personalizaremos según nuestras necesidades. Por ejemplo correr SSH en el puerto 65500 en lugar del 22.

Otra de las partes es la que cuelga bajo el nombre que le hayamos dado a nuestra regla, que son “Policy”, “NAT” y “Routing”. En Policy, indicaremos las reglas de filtrado como tal, IP origen, destino, servicio, interface, etc. y la correspondiente acción, denegar, permitir, etc.

En NAT, obviamente las reglas de “NATeo” que vayamos a definir en el caso de ser necesario.

Y finalmente “Routing” las tablas de rutas a las que estarán sujetos los paquetes que pasen por nuestro Firewall.

Para agregar una entrada en cada una de los puntos anteriores bastará con hacer doble click en la cruz verde bajo la opción “Install”.

Luego tendremos otros dos apartados denominados “Objects” y “Services”.  En el primero definiremos todo lo relacionado a equipos, grupos de equipos, redes, subredes, etc. mientras que en el segundo aquello vinculado a servicios, es decir protocolos IP, TCP, UDP, y sus correspondientes números de puerto.

Una vez tengamos todo hecho, tendremos que ir al apartado “Compile”. Con esto, la herramienta compilará todas las reglas (Policy, NAT y Routing) y generará un archivo si todo está correcto. Si no lo está, nos dará un error, el cual tendremos que corregir modificando el apartado erróneo. Finalmente, ejecutaremos el fichero en cuestión y se aplicará todo lo que hayamos configurado.

 Lo que he tratado de hacer en este post es presentar una herramienta que nos puede ayudar mucho en nuestras tareas de administración para elaborar nuestras reglas de filtrado en nuestro Firewall, y que, en caso de no disponer uno, si tenemos la posibilidad de instalar unas tarjetas de red en un PC, nos bajamos una distribución GNU/Linux como Ubuntu y con FWBuilder montarnos nuestro propio firewall.

También tenemos otras alternativas como utilizar alguna de las distribuciones ya creadas como pueden ser Smoothwall Firewall o Monowall Firewall

Seguiremos informando.

Switching Multicapa y SVI

Posted on por
Anuncios

Aquí estamos  de nuevo. Esta vez nos vamos a meter con una característica de los switches multicapa.

Para empezar definiremos qué es esto de los switches multicapa cuando, es posible, que hasta la fecha nos hayan contado que los switches son equipos de Capa 2 dentro del modelo OSI.  En origen, los switches sí que lo eran, pero como todo en esta vida, las cosas cambian y evolucionan. A veces a mejor, a veces a peor, pero en nuestro caso, y como no podía ser de otra manera, a mejor J. Como ya sabemos, los switches en el sentido tradicional de la palabra, efectúan los envíos de tramas considerando las direcciones MAC de los equipos que tiene conectados a cada una de sus bocas, permitiendo así las comunicaciones de la misma red, subred o VLAN. En el momento que queramos hacerlo contra otros fuera de éstas, por ejemplo una granja de servidores, con otro direccionamiento IP y VLAN (es lo suyo), necesitamos, entonces, un equipo de Capa 3 como puede ser un router o un switch multicapa. En un switch multicapa, la principal diferencia con los de Capa 2, es que ahora ya no se va a considerar la dirección MAC del equipo final sino la IP. Es decir, el direccionamiento de Capa 3; o sea, como lo hace un router. Y claro alguien preguntará ¿y en qué más se diferencian un router y un switch multicapa? Una de ellas es el rendimiento. Un switch multicapa está orientado a entornos LAN, pudiendo ofrecer rendimientos a la velocidad del medio que tengan conectado, ya sea 100 Mbps, 1Gbps o 10 Gbps. Esto se consigue gracias a una electrónica especializada denominada ASIC en lugar de un microprocesador que es lo que emplea un router.  Además como buen switch poseen una densidad de puertos mayor pudiendo ser de 12, 24, 48, puertos con medios de transmisión como cable UTP o Fibra Óptica dependiendo de fabricante, gama, modelo, etc. Y ni qué decir que puesto que son equipos que operan en capa 3 también dispondrán de funciones de enrutamiento, tanto estático como dinámico (OSPF, EIGRP, RIP, etc.).

Ahora bien, si tenemos un switch de estas características ¿cómo los echamos a andar? Esta vez tiraré de Packettracer, simulador de redes de Cisco, y tomaré el de capa de capa 3, el 3560.

Aquí tendremos un par de opciones.

Una de ellas es asignar a cada interfaz física del switch una dirección IP. Para ello deberemos configurar dicho puerto como uno de capa 3 en lugar de capa 2 que es como suelen venir por defecto. Para ello:

Switch>enable

Switch#conf t

Enter configuration commands, one per line.  End with CNTL/Z.

Switch(config)#interface fastEthernet 0/1

Switch(config-if)#no switchport

Switch(config-if)#ip address 192.168.1.1 255.255.255.0

Switch(config-if)#exit

Switch(config)#ip routing 

Una vez que entramos en el modo de configuración de la interfaz con “no switchport” indicamos que ese puerto (fastethernet 0/1) no tendrá capacidades L2 (Layer 2, Capa 2) sino L3. Luego con “ip address 192.168.1.1 255.255.255.0” le asignamos la IP y finalmente con “ip routing” habilitamos la capacidad de enrutamiento entre las distintas interfaces que tenga.

Esta es una opción, pero no la única. La otra es definir interfaces virtuales, lo que se denomina como SVI (Switch Virtual Interface). Una SVI es una interfaz definida en el quipo y asociada a una VLAN concreta. Uno de los requisitos es que tiene que haber un puerto activo en esa VLAN para que la SVI correspondiente se habilite. Un enlace troncal también vale. Aunque sea virtual podremos configurar en ella los mismos protocolos y funcionalidades que a una interfaz física como pueden ser HSRP, VRRP, GLBP, ACL´s, etc.

Para ponerlo en funcionamiento, tenemos que definir las VLANs, crear las SVI correspondientes a cada VLAN y asignar una IP, configurar las interfaces físicas bien en modo troncal o de acceso asociada a una VLAN, y habilitar el enrutamiento como en el paso anterior

Esto es:

Entramos en modo configuración:

Switch>ena

Switch>enable

Switch#conf t

Definimos las VLAN 10 y 20:

Switch(config)#vlan 10

Switch(config-vlan)#name VLAN_10

Switch(config-vlan)#exit

Switch(config)#vlan 20

Switch(config-vlan)#name VLAN_20

Switch(config-vlan)#exit

Configuramos las interfaces físicas:

Switch(config)#interface fastEthernet 0/1

Switch(config-if)#switchport mode access

Switch(config-if)#switchport access vlan 10

Switch(config-if)#exit

Switch(config)#interface fastEthernet 0/2

Switch(config-if)#switchport mode access

Switch(config-if)#switchport access vlan 20

Switch(config-if)#exit

Definimos las SVIs:

Switch(config)#interface vlan 10

Switch(config-if)#

Switch(config-if)#ip address 192.168.10.1 255.255.255.0

Switch(config-if)#exit

Switch(config)#interface vlan 20

Switch(config-if)#ip address 192.168.20.1 255.255.255.0

Switch(config-if)#exit

Habilitamos el enrutamiento:

Switch(config)#ip routing

Otra funcionalidad aparte de la comunicación entre redes,  es utilizarlas para la gestión de los propios equipos mediante protocolos como SSH, Telnet, monitorización, etc. para lo cual deberemos definir también una puerta de enlace para la comunicación con otras redes. No nos debemos olvidar que aún en este caso nuestros equipos de red al estar dotados con una IP aunque sea la de gestión, también puede ser objeto de escaneos de red con objeto de recolectar información, y realizar a posteriori algún tipo de explotación contra alguno de los servicios que puedan correr en ellos.

A continuación os dejo una captura de un escaneo sencillo contra un switch Catalyst 6509 dotado con sistema operativo CatOS.

Como se puede ver nmap lo ha detectado sin problemas. Para evitarlo es aconsejable definir algún tipo de ACL donde se permita algún tipo de tráfico desde una estación central de gestión. Pero eso lo dejamos para otro rato, por hoy lo dejamos.

Seguiremos informando…