En la entrada anterior hemos hablado de Cisco Prime LMS. En ella hemos visto las posibilidades que nos da este tipo de herramientas, poniendo como ejemplo la visualización de un switch y la configuración de un puerto de forma gráfica. Seguidamente hemos puesto un ejemplo sobre cómo planificar el reinicio de uno o varios switches.
Puesto que Cisco Prime LMS ha sido reemplazado por Cisco Prime Infraestructure, ahora vamos a ver las posibilidades que nos brinda pero en este caso sobre un equipo inalámbrico dentro de nuestra infraestructura Wireless.
Al igual que LMS tenemos la pantalla de inicio. Allí podemos encontrar gráficas sobre inventario hardware. Aquí a diferencia del anterior ya nos aparecen los Puntos de Acceso Inalámbrico. Si nos fijamos podemos encontrar 4 equipos que han sido identificados con un porcentaje de utilización de memoria de hasta el 93%. Ahí pasa algo raro….
Así como en redes cableadas en caso de producirse un problema de conectividad suele ser sencillo identificar el problema, en el caso de las redes inalámbricas nos puede dar más de un quebradero de cabeza. Las señales pueden cancelarse, atenuarse, producirse rebotes, existir focos de ruido, compartir frecuencias con otros dispositivos, etc. y todo ello aparte de la propia naturaleza de la transmisión Wifi, CSMA/CA. Esta herramienta podría ayudarnos enormemente a la hora de tratar de solucionar problemas. Por ejemplo si introducimos la IP del dispositivo, en nuestro caso, XXX.XXX.XXX.99 el software nos dirá su dirección MAC, fabricante, en nuestro caso una infraestructura centralizada en Controladores Wireless (WLC, Wireless LAN Controller); nombre del AP asociado en ese momento; intensidad de la señal; relación Señal/Ruido; histórico de asociaciones, etc. Vemos las capturas:
Además de los indicado en el párrafo anterior, la aplicación nos indica unos gráficos donde podemos ver el histórico de la intensidad de señal, relación Señal/Ruido; Bytes enviados y recibidos, etc. Con todo ello podremos analizar lo que está sucediendo, o sucedido, y poder solucionar el problema en cuestión.
Como decía antes estas herramientas pueden dar más de sí y tiene una gran cantidad de funcionalidades extra que resultaría imposible contar aquí.
Obviamente estas aplicaciones tienen un mayor sentido en entornos donde el volumen de dispositivos y clientes es considerable. Si vemos la primera de las capturas del Cisco Prime, en este caso estamos hablando de más de 240 Puntos de Acceso y 117 equipos de red, entre switches y routers. ¿Os imagináis lo que puede llegar a ser la administración de esta infraestructura si no tenemos aplicaciones como ésta? Un auténtico infierno…
A lo dicho creo que la idea de fondo habrá quedado clara, nos vemos en la siguiente en que hablaremos de HP IMC. No todo es Cisco …
Muchas veces nos ponemos a hablar de distintos temas y nos olvidamos de otros muchos más básicos que han de darse para que éstos puedan llevarse a cabo. Que no cunda el pánico, me explico…
Una de las labores principales que tienen los administradores de infraestructuras es garantizar el correcto funcionamiento de las mismas, ya que sobre ellas se sustenta la actividad de las organizaciones a las que pertenecen, ya sean organismos, instituciones o empresas privadas. Para que esto sea así, han de establecerse unas políticas y estrategias de tolerancia a fallos, seguridad, emergencia, etc. con las que poder hacer frente a los posibles incidentes que se puedan dar. Aquí podríamos establecer dos tipos de planteamientos; el preventivo, cara a la realización de tareas y ejercicios controlados, con los cuales poder evitar que estos sucesos ocurran, como pueden ser el apagado controlado de equipos, eliminación de enlaces redundantes, apagado de fuentes de alimentación, etc. Y por otro lado, el reactivo, esto es, la capacidad de respuesta ante un incidente que pueda comprometer la operativa de la red y que dependiendo de su categorización requerirá de unos tiempos de respuesta máximos para restablecer los servicios de los sectores afectados.
En cualquier caso, se requiere pues de un control y una gestión estricta de nuestro equipamiento, especialmente cuando se habla de infraestructuras de una envergadura considerable donde no sólo porque se puedan ver afectados un número importante de clientes finales sino también por el volumen de dispositivos de networking.
En este punto los administradores han de tener una serie de herramientas que permitan gestionar y monitorizar la red. Aquí debemos definir bien estos dos conceptos ya que, a veces, inducen a error. Cuando hablamos de herramientas de gestión, estamos hablando de software con el que podremos intervenir sobre nuestros equipos, realizando tareas como el cambio de parámetros, configuraciones, actualizaciones de software, representación gráfica de la topología de la red, etc. Por otro lado, tendríamos las herramientas de monitorización, con la que podemos conocer el estado funcional de nuestros equipos y componentes, así como volumen de tráfico en enlaces, porcentaje de utilización, etc. Además, en el caso de producirse algún comportamiento anómalo, poder recibir, algún tipo de alerta como un correo electrónico o SMS.
Los distintos fabricantes ofrecen entre sus productos dichas herramientas, previo pago claro está de una licencia que puede ir en función del tipo de funcionalidades disponibles, volumen de equipos o cualquier otro criterio que consideren oportuno. No obstante, las hay también de software libre, especialmente en lo que a monitorización se refiere.
Algunas de las herramientas de gestión que podemos encontrar podría ser Cisco Prime Infraestructure, la cual, ha sustituido a Cisco Prime LMS (Lan Management Solution). Cisco Prime Infraestructure ha sido diseñada para poder hacer frente no sólo a redes cableadas sino también a inalámbricas, pudiendo aglutinar las funcionalidades que daba el appliance WCS (Wireless Control System). Por ahora yo trabajo con ambas, y personalmente en lo que a redes cableadas se refiere me gusta más LMS que Infraestructure, justo lo contrario que para las redes inalámbricas.
Cualquiera de ellas tienen una gran cantidad de funcionalidades, no sólo puramente de gestión sino además de monitorización, troubleshooting, auditoría, reporting, etc. Alguna de ellas son:
1.- Actualización de software en dispositivos.
2.- Cambios en las configuraciones.
3.- Representaciones gráficas.
4.- Elaboración de informes.
5.- Gestión de alertas.
6.- Gestión de logs.
7.- Detección de discrepancias en red.
8.- Monitorización.
Aquí os dejo algunas capturas que, muchas veces una imagen vale más que mil palabras.
Pantalla de login.
Página inicial. Allí ya podemos ver una gráfica con el resumen del hardware detectado, discrepacias en configuraciones, desviaciones de las mejores prácticas, etc.
Funcionalidad para ver la imagen del switch. En verde puertos en funcionamiento; en naranja, los deshabilitados; y en amarillo, los operativos pero que no tienen ningún equipo conectado.
Si pinchásemos sobre alguno de los puertos podríamos realizar algunas configuraciones. En nuestro caso el 1/1.
Si quisiésemos programar un reinicio de uno o varios switches podríamos ir a Configuration-NetConfig y allí, pincharemos sobre Create.
En función del elemento sobre el cual realizaremos la acción en cuestión, deberemos elegir entre dispositivo, módulo o puerto. En nuestro caso puesto que vamos a reiniciar el equipo elegiremos, Device Based.
Elegimos el, o los equipos, y la tarea, en nuestro caso “Reload”.
Damos un nombre y si queremos programarla fecha y hora; y algunos parámetros adicionales.
Finalmente nos sale un resumen con los pasos a seguir y ya estaría lista la tarea.
Así cómo hemos visto se podrían llevar a cabo otras muchas tareas de distinta índole y explotar otra gran cantidad de funcionalidades. Lo que se pretende es hacer una vista rápida de este tipo de herramientas y de lo que pueden llegar a hacer. Para la próxima daremos algunos ejemplos de Cisco Prime Infraestructure.
Como comentaba en la entrada anterior, hace poco terminé el curso sobre Ciberseguridad en Sistemas de Control y Automatización Industrial impartido por el Instituto Nacional de Ciberseguriad (INCIBE) antes, INTECO.
Dentro de su contenido, en uno de sus módulos se trataba el tema de los incidentes de seguridad sobre dichos sistemas, analizando desde los posibles objetivos potenciales hasta las deficiencias técnicas, pasando por controles de acceso físico pobres o incluso nulos.
Entre esos puntos se apuntaba como orígenes a la red corporativa y a cortafuegos perimetrales mal configurados. En el primero de ellos, se explicaba que tanto los sistemas empresariales como industriales comparten la misma infraestructura de comunicaciones permitiendo llevar ataques desde la red corporativa a la de control aprovechando alguna vulnerabilidad en aquéllos. En lo referente a los cortafuegos perimetrales, se comentaban las malas configuraciones sobre ciertos protocolos y también, no considerar el sentido de las conexiones. Como ejemplo se hablaba de una intrusión en los sistemas de control, la ejecución de un “payload” en ellos e iniciar una conexión a un equipo remoto empleando un puerto abierto en el firewall.
Partiendo de la base que ninguna red es igual ya que las necesidades y usos pueden ser bien distintos, en la entrada de hoy voy a hablar de dos aspectos que afectan a las ideas descritas en los apartados anteriores.
Por mi experiencia, es muy común que equipos corporativos convivan con los de control dentro del mismo switch. Por ejemplo, en una cadena de producción tenemos un PC donde ejecutamos distintas aplicaciones relacionadas con el proceso de fabricación, mientras que en otros puertos tenemos los autómatas que controlan la maquinaria (robots, sensores, válvulas, etc.). También puede ocurrir que existan incluso puntos de acceso inalábricos para aquellos dispositivos no cableados tipo PDAs industriales, lectores de códigos de barras, PCs portátiles de personal de mantenimiento, etc. ¡Y posiblemente todo dentro de la misma VLAN! Resultaría costosísimo, o incluso inviable, implementar dos o tres infraestructuras paralelas para separar físicamente todo el tráfico, así que la realidad es que unos y otros deben “viajar” por el mismo equipo y por la misma red, aunque separados lógicamente mediante el uso deVLANs.
Por otro lado, debemos pensar que a la hora de interconectarlo todo, no se puede implementar cortafuegos por cada enlace, subred, equipo, etc. para regular el tráfico a permitir o denegar. Si bien la inversión, condiciona en gran medida la solución tecnológica a utilizar (salvo que sobre el dinero, que viendo los tiempos que corren es poco probable…), debemos pensar, en lo a la parte técnica se refiere, que los switches nos pueden ofrecer una serie de ventajas que, a veces, los cortafuegos no lo hacen. Por ejemplo, mayor densidad de puertos y uso de módulos SFP para distintos medios físicos como cable y fibra óptica. También es cierto que los cortafuegos realizan tareas que no hacen los switches. Unos no son mejores que los otros, sino que cada cual hace su papel y se complementan.
A estas ideas debemos sumar también la implantación de medidas que garanticen una alta disponibilidad de los servicios prestados, con lo que aparte de equipos de comunicaciones, de seguridad, control, automatización, etc. debemos disponerlo todo de tal manera que en caso de producirse un fallo, la red pueda seguir funcionando sin que esto suponga un impacto en la calidad del servicio ofrecido.
Como bien dice el refrán “Una imagen vale más que mil palabras” he creado un escenario para tratar de entender mejor lo dicho. He utilizado la aplicación de Cisco Systems, Packettracer, utilizada para la preparación de las certificaciones CCNA y CCNP, entre otras.
Basándome en los criterios de este post, aquí os dejo la topología:
Para explicarlo empezaremos de izquierda a derecha.
Tenemos el equipo “Switch Acceso” (Switch L2) al que se conectan por un lado los autómatas PLC-01 y PLC-02, y por otro un PC que pueda ser utilizado para la ejecución de aplicaciones relacionadas con la actividad industrial. También se ha incluido una impresora, como un elemento de red más que pueda ser utilizado para la impresión de algunos documentos, órdenes de montaje, códigos de barras para temas logísticos, etc.
Para segmentar el tráfico, los PLCs, el PC y la impresora se han situado en VLANs distintas. PLC-01 y PLC-02 en la VLAN 10 con direccionamiento 192.168.10.0 /24; y PC-01 y Printer0 en la VLAN 20, y red 192.168.20.0/24. Como puerta de enlace será la primera IP de ambas redes, la .1.
Dado que es un entorno de alta disponibilidad, se ha configurado en los switches “sw-core-01” y “sw-core-02” (Ambos multicapa o L3) interfaces virtuales para cada una de las VLANs, y en ellas, el protocolo HSRP, aunque también hubiera servido VRRP. Si no sabéis o queréis refrescar los conceptos de interfaces virtuales o dejo un link a un artículo que publiqué hace un tiempo, aquí.
Luego tenemos los cortafuegos, que filtrarán el tráfico entre la red de servidores donde se sitúa el servidor de SCADA, Historiadores, etc y el resto. Esta red tiene un direccionamiento 192.168.254.0/24, y está en la VLAN 254. También está configurado HSRP.
No he dibujado la red corporativa como oficinas ya que no viene por ahí el problema de seguridad que quiero explicar, pero de existir, deberían colgar de cada uno de los nodos del firewall, como lo están las dibujadas.
Como podréis ver los cortafuegos tiene un enlace entre sí. Todo tiene una explicación.
Al igual que en los equipos de red tenemos HSRP, VRRP y GLBP para implementar alta disponibilidad, los cortafuegos tienen los suyos también. Lo que se hace es una topología tipo “Activo-Pasivo” o “Activo-Activo”. La primera de ellas, sería equiparable al comportamiento de HSRP y VRRP, donde uno de los nodos soporta todo el tráfico, el “Master”, mientras que el otro está de respaldo, el “Backup”. En caso de que el “Master” falle, el “Backup” entra en funcionamiento. El modo “Activo-Activo” es aquél en el que ambos nodos funcionan a la par, proporcionando no sólo una alta disponibilidad, ya que si uno falla el otro asume su rol, sino que además existe un balanceo de carga ya que se puede repartir el tráfico entre ambos.
En cualquiera de los dos casos, ambos nodos deben tener un enlace donde compartir una tabla con las conexiones que tiene abiertas, ya que si el nodo “Master” falla, el de “Backup” debe seguir permitiéndolas. Si no existiese este enlace y el nodo de “Backup” no tuviese dicha tabla, cuando uno de los equipos finales volviesen a generar tráfico de una sesión ya establecida, las cortarían.
Por no estar hablando siempre de Cisco, Juniper tiene su protocolo NSRP. Os dejo algunos enlaces pero si buscáis en por ahí encontraréis un montón de información al respecto.
Vale, tenemos el PC y la impresora en una VLAN; y los PLCs en otra de tal manera que a nivel de capa 2 los tenemos “aislados” y cada uno en su propio dominio de broadcast. Mismo criterio con los servidores. Sin embargo, los equipos PLC no están todo lo protegidos que debieran.
¿Por qué? Porque si nos fijamos el PC-01 a pesar de estar en una VLAN distinta de los PLCs puede llegar a ellos sin problemas. Vamos a abrir un navegador del PC-01 y la IP del PLC-01.
¿Por qué? Sencillo. Cuando abrimos el navegador el tráfico llega al switch sw-core-01. Como éste tiene acceso a la VLAN donde está la dirección IP de destino, la 192.168.10.100, es el propio switch el que lo envía por la interfaz de la VLAN 10 ya que están ambas en el mismo equipo. La 10 y la 20. Podríamos cambiar manualmente el enrutamiento para que fuese todo al tráfico hacia el firewall y éste lo descartase, pero tampoco tiene mucho sentido hacerlo “subir” hasta ahí para luego descartarlo y ocupar un ancho de banda por poco que sea, nos puede resultar necesario, especialmente a los PLC en su comunicación con el servidor SCADA.
Por tanto, hay una cosa que es clara y es que tenemos que filtrar el tráfico para evitar que ningún equipo de la red 192.168.20.0/24 pueda llegar a la 192.168.10.0/24. Sin embargo, sí que tenemos que permitir el tráfico desde la red 192.168.20.0/24 a cualquier otro equipo de la red.
Así que, ¿qué alternativa tenemos? La alternativa son las ACL, Access List. Pero esto lo dejamos para la siguiente entrada.
Un saludo a todos, nos vemos en la siguiente y no te olvides que puedes seguirnos también en @enredandoconred .
