Archivo de la categoría: L3

Primeros pasos con Comware

Posted on por
12
Anuncios

Hola de nuevo. Vamos con otra entrada, esta vez sobre cómo configurar equipos de redes. Sin embrago, no me voy a meter con Cisco sino con HP. HP tiene un área de Networking donde tienen una gama de productos para distintos ámbitos, Data Center, Acceso, Servidores, etc. Inicialmente HP tenía su línea de equipos denominándose Procurve. Sin embargo, en 2010 compra la empresa 3Com, que a su vez en 2007 compra H3C. H3C a su vez era lo que conoce como “joint venture” entre 3Com y Huaweii.

Actualmente podríamos resumir la gama de equipamiento de la siguiente manera:

En mi caso me está tocando pegarme con los de la serie A que viene con el sistema operativo Comware, vamos lo que vendría a ser la IOS de los Cisco. También podremos encontrarnos con equipos, esta vez de la serie E, que vengan con Provision, otro sistema operativo.

Existe en la web una guía comparativa entre los comandos de los tres sistemas operativos que podréis encontrar aqui.

No obstante utilizando encontraremos más de una similitud entre Comware e IOS, lo cual nos llevará en muchas ocasiones a confusión especialmente se venimos del mundo Cisco. Pero bueno, es lo que hay.

Empecemos pues.

EL equipo en el que voy a hacer las configuraciones es un HP A3600 Series con una versión de software Comware 5.2. Me conectaré por consola, siendo los valores por defecto:

9600 bps

8 bits de datos

Sin paridad

1 bit de parada

Sin control de flujo.

Una vez arrancado el equipo entraremos directamente al equipo sin autenticación ni nada. Veremos que el prompt del switch nos aparecerá como entre signos de menor y mayor que, estos:

<HP>

Los switches HP tiene dos vistas. Al arrancar el equipo ey ver el prompt tal y como lo he puesto con anterioridad, estaremos en la vista de usuario, user-view. Esta es una vista en la que se realizan operciones sobre la memoria flash; listar, renombrar o borrar ficheros; salvar configuraciones, etc. Para poder entrar a configurar el equipo en si mismo como VLANs, puertos, IPs, etc. deberemos entrar en lo que se denomina system-view. Para ello deberemos ejecutar:

Ahora podremos ver que los símbolos “< >” han cambiado “[ ]”. Ahora sí que podremos entrar configurar el equipo.

Otros aspectos a tener en cuenta es que a diferencia de Cisco IOS que puede haber hasta 15 niveles, Comware sólo tiene 4, lo cual simplifica mucho la cosa. Estos niveles son:

Visitor                 0

Monitor              1

System                2

Manager             3

Cada nivel estará autorizado a ejecutar una serie de comandos.

El nivel Visitor, incluye herramientas de diagnóstico típicas como ping y traceroute, sin embargo no está permito salvar la configuración.

El nivel Monitor, incluye los comandos display y debugging los cuales pueden ser usados para tareas de diagnóstico y mantenimiento. Aquí tampoco está permitido guardar configuraciones.

El nivel System, incluye comandos como los de routing y para las distintas capas de red y está orientado proporcionar servicios de red al usuario.

El nivel Manager, es el nivel más alto y con él se podrán realizar los ajustes de la configuración del equipo.

Lo primero que haremos será asignar una contraseña a la línea de comandos y el acceso remoto vía SSH.

Configuraremos una contraseña para el usuario de nivel 3:

[HP]super password level 3 cipher p4ssw0rd 

Configuramos el puerto de consola, en HP “aux 0”, indicándole que el modo de autenticación es “password” y que la contraseña será “4uxp0rt”

[HP]user-interface aux 0

[HP-ui-aux0]authentication-mode password

[HP-ui-aux0]set authentication password cipher 4uxp0rt

[HP-ui-aux0] 

Hecho esto ya tendríamos configurada una contraseña si nos conectásemos por el puerto de consola. Ahora pasamos configurar el acceso por SSH.

Habilitamos el acceso por SSH.

HP]ssh server enable

Info: Enable SSH server. 

Generamos la contraseña RSA. Aqui nos aparece que ya teneemos una porque ya la había generado con anterioridad.

 [HP]public-key local create rsa

Warning: The local key pair already exist.

Confirm to replace them? [Y/N]:Y

The range of public key size is (512 ~ 2048).

NOTES: If the key modulus is greater than 512,

It will take a few minutes.

Press CTRL+C to abort.

Input the bits of the modulus[default = 1024]:

Generating Keys…

++++++

++++++

+++

+++

Ahora creamos un usuario local “netadmins”. Le autorizaremos a emplear SSH y su contraseña será n3t4dm1ns:

 [HP]local-user netadmins

New local user added.

 [HP-luser-netadmins]service-type ssh

 [HP-luser-netadmins]password cipher n3t4dm1ns

 [HP-luser-netadmins]

Ahora pasaremos a definir una IP al equipo. Por defecto está definida la VLAN 1 al igual que en los equipos Cisco.

[HP]interface Vlan-interface 1

 [HP-Vlan-interface1]ip address 192.168.10.10 24 

Finalmente deberemos configurar las interfaces virtuales. Ahí le diremos que el modo de autenticación será “scheme”, esto es por usuario y contraseña y que el protocolo que lo utilizará será SSH.

[HP]user-interface vty 0 4 

[HP-ui-vty0-4]authentication-mode scheme

 [HP-ui-vty0-4]protocol inbound ssh

Y ahora guardamos la configuración

[HP-ui-vty0-4]save

The current configuration will be written to the device. Are you sure? [Y/N]:Y

Please input the file name(*.cfg)[flash:/config.cfg]

(To leave the existing filename unchanged, press the enter key):

flash:/config.cfg exists, overwrite? [Y/N]:Y

Validating file. Please wait….

The current configuration is saved to the active main board successfully.

Configuration is saved to device successfully.

[HP-ui-vty0-4]

Y así ya tendríamos configurado de una manera básica nuestro switch de HP. A continuación os dejo la captura con el login.

Al abrir la sesión con SSH nos logueamos con el usuario y contraseña de “netadmins”. Luego tenemos que escalar privilegios con el somando “Super 3” para acceder a administrar el equipo. Ahí tendremos que meter la correspondiente contraseña. Luego con “system-view” accederemos al resto de opciones.

Como decía, de  esta manera ya tendríamos configurado el switch. Ahora a seguir con el resto de configuraciones…

ACLs, Listas de Control de Acceso

Posted on por
Anuncios

Siguiendo el hilo de la entrada anterior, «Cuando las VLANs y Firewall no son suficientes» vamos hablar de las ACL, Access Control List o Listas de Control de Acceso.

¿Qué son?

Una Lista de Control de Acceso es un conjunto de sentencias que permiten o deniegan un tráfico determinado. Algo similar a lo que viene hacer un cortafuegos.

¿Para qué se utilizan?

Aunque pueden tener diversos usos, es una manera “sencilla” de filtrar el tráfico que pasa por un dispositivo de red de capa 3, o también para el acceso al mismo vía SSH. Es útil para aplicar ciertas políticas de seguridad.

¿Qué tipos hay?

Hay varios tipos, pero poniendo como ejemplo los dispositivos Cisco, las más utilizadas son las “Standard” y “Extended”. En las “Standard” emplearemos como parámetro de filtrado las direcciones IP de origen; mientras que las “Extended” utilizaremos la IPs de origen, destino y puertos. También tendremos las “Named”, que es lo mismo que las dos anteriores pero nos permiten asignarlas un nombre en lugar de un número. Más adelante lo explicaremos.

¿Cómo funcionan?

Una Lista de Control de Acceso se compone de una serie de sentencias que permiten o deniegan un tráfico determinado. El equipo irá comparando cada paquete con cada una de las sentencias de la ACL, de la primera a la última. En el momento que un paquete coincida con la sentencia, ésta se ejecuta y no se sigue comparando. Cada ACL tiene un “deny any” implícito al final de las sentencias, esto es, si un paquete no coincide con ninguna de las sentencias se descarta.

¿Cómo se utilizan?

Una vez que la ACL está creada, se debe aplicar a una intefaz, y también en un sentido determinado. Es decir, en sentido entrante (Inbound) o saliente (Outbound) a esa interfaz.

A este respecto debemos tener en cuenta dos aspectos importantes. Cuando una ACL se aplica en sentido entrante, los paquetes que serán evaluados primero por dicha ACL, y en caso de ser permitidos será entonces cuando el equipo los enrute por alguna interfaz de salida. Obviamente, todos los paquetes que se denieguen no serán sometidos a la tabla de enrutamiento.

Sin embargo, cuando una ACL se aplica a en sentido “Saliente”, ésta se aplicará una vez los paquetes hayan sido enrutados. O lo que es lo mismo, primero se enrutan y luego se ve si se permiten o deniegan.

¿Por qué este matiz? Tanto el enrutamiento, como comparar cada paquete con cada sentencia de las ACL son procesos que consumen recursos hardware. Por tanto, deberemos tener en cuenta el sentido ya que si tenemos que descartar paquetes, será mejor hacerlo en ACL entrantes de tal manera que el equipo no tenga que malgastar recursos en enrutarlo para luego descartarlo en caso denegar ese mismo tráfico en una ACL saliente.

Por otro lado, es conveniente crear el contenido de las ACL en un editor de texto y luego aplicarla en el equipo haciendo un “copy/paste”. ¿Por qué? Cada vez que añadamos una sentencia ésta será anexada al final de la ACL y tampoco tendremos la posibilidad de borrar una entrada concreta.

ACLs Standard

Las Listas de Control de Acceso Estándar son aquellas que efectúan el filtrado, permitiendo o denegando inspeccionando la IP de origen. Cada ACL de este tipo lo podremos numerar de un rango que podrá ir de 1-99 o 1300-1999.

Switch01(config)#access-list ?
   <1-99> IP standard access list
   <100-199> IP extended access list
   <1000-1099> IPX SAP access list
   <1100-1199> Extended 48-bit MAC address access list
   <1200-1299> IPX summary address access list
   <1300-1999> IP standard access list (expanded range)
   <200-299> Protocol type-code access list
   <2000-2699> IP extended access list (expanded range)
   <300-399> DECnet access list
   <600-699> Appletalk access list
   <700-799> 48-bit MAC address access list
   <800-899> IPX standard access list
   <900-999> IPX extended access list
    dynamic-extended Extend the dynamic ACL absolute timer
    rate-limit Simple rate-limit specific access list

Definido el número, a continuación deberemos especificar si permitimos o denegamos el tráfico en cuestión.

Switch01(config)#access-list 5 ?
   deny Specify packets to reject
   permit Specify packets to forward
   remark Access list entry comment

El siguiente paso será proporcionar los valores:

Switch01(config)#access-list 5 deny ?
   Hostname or A.B.C.D Address to match
   any Any source host
   host A single host address

La primera de las opciones hace referencia a la IP o rango de éstas. La segunda y la tercera permiten, en lugar de especificar en formato numeral “cualquier IP” o “una IP concreta”, introducir los términos “any” y “host” respectivamente.

Máscaras Wildcard

Las Máscaras Wildcard son utilizadas por las ACLs para indicar un equipo, un conjunto de éstos o una red completa. Se asemeja a lo que vendría ser una máscara de subred aunque con bien significado es distinto.

Cuando en una Máscara Wildcard figura un “0” se entiende que el valor que consta en la IP debe coincidir. Sin embargo cuando aparece un “255” puede tomar cualquier valor. Por ejemplo:

192.168.1.0 0.0.0.255

Quiere decir que los tres primeros octetos “192.168.1” que coincidan con el paquete se les aplicará esa sentencia en la ACL. El cuarto octeto podrá tener cualquier valor, de 1 a 254.

Por ejemplo:

Switch01(config)#access-list 10 deny 192.168.1.0 0.0.0.255 

Esto añadirá una sentencia en la que se denegarán todos los paquetes con IP de origen “192.168.1” ya que la máscara tiene un “0”. El cuarto octeto puede tener cualquier valor “255”, entre 1 y 254.

Para indicar rango de subredes deberemos de realizar cálculos. Una manera sencilla para indicar redes es restar “255” a la máscara de subred de una dirección IP contenida en ese rango.

No os asustéis, aquí os dejo unos enlaces donde una calculadora hará el trabajo por vosotros:

Link 1

Link 2

Os dejo unos enlaces que hablan de las Máscaras Wildcard

Link 1

Link 2

Como dije antes, no sólo tenemos que crear las ACL sino además aplicarlas a una interfaz en alguno de los sentidos, bien entrante, bien saliente. Esto es:

Switch01#config t
Switch01(config)#access-list 10 deny 192.168.1.0 0.0.0.255
Switch01(config)#access-list 5 permit any
Switch01(config)#interface Ethernet 0
Switch01(config-if)#ip access-group 10 out 

En la configuración anterior configuramos la access list “Standard”, número 5, en la que denegaríamos la red 192.168.1.0/24, y luego permitiríamos el resto de tráfico. Luego, aplicaríamos dicha ACL a la interfaz Ethernet 0 en sentido saliente.

ACLs Extended

A diferencia de las ACL Standard, las “Extended”, pueden llevar a cabo el filtrado considerando la IP de origen, la de  destino, y los puertos.

Los rangos para identificar estas ACLs van de 100 a 199 y de 2000 a 2699.

Switch01(config)#access-list 115 ?
   deny Specify packets to reject
   dynamic Specify a DYNAMIC list of PERMITs or DENYs
   permit Specify packets to forward
   remark Access list entry comment

Acto seguido definiremos si denegamos o permitimos:

Switch01(config)#access-list 115 deny ?
   <0-255> An IP protocol number
   ahp Authentication Header Protocol
   eigrp Cisco's EIGRP routing protocol
   esp Encapsulation Security Payload
   gre Cisco's GRE tunneling
   icmp Internet Control Message Protocol
   igmp Internet Gateway Message Protocol
   ip Any Internet Protocol
   ipinip IP in IP tunneling
   nos KA9Q NOS compatible IP over IP tunneling
   ospf OSPF routing protocol
   pcp Payload Compression Protocol
   pim Protocol Independent Multicast
   tcp Transmission Control Protocol
   udp User Datagram Protocol

Ahora definiremos el protocolo:

Switch01(config)#access-list 110 deny tcp ?
   A.B.C.D Source address
   any Any source host
   host A single source host

El siguiente parámetro de definir es la IP, red o subred, o cualquier IP de origen. Cabe mencionar que  podremos indicar el puerto de origen con los parámetros eq, gt, lt, neq o range. Para nuestro ejemplo no consideraremos puertos de origen:

Switch01(config)#access-list 110 deny tcp any ?
   A.B.C.D Destination address
   any Any destination host
   eq Match only packets on a given port number
   gt Match only packets with a greater port number
   host A single destination host
   lt Match only packets with a lower port number
   neq Match only packets not on a given port number
   range Match only packets in the range of port numbers

Como es lógico habrá que especificar la IP, red o subred, o cualquier IP de destino.

Switch01(config)#access-list 110 deny tcp any host 172.16.30.2 ?
   ack Match on the ACK bit
   dscp Match packets with given dscp value
   eq Match only packets on a given port number
   established Match established connections
   fin Match on the FIN bit
   fragments Check non-initial fragments
   gt Match only packets with a greater port number
   log Log matches against this entry
   log-input Log matches against this entry, including input interface
   lt Match only packets with a lower port number
   neq Match only packets not on a given port number
   precedence Match packets with given precedence value
   psh Match on the PSH bit
   range Match only packets in the range of port numbers
   rst Match on the RST bit
   syn Match on the SYN bit
   time-range Specify a time-range
   tos Match packets with given TOS value
   urg Match on the URG bit
   <cr>

Aquí sí que tendremos que definir un puerto de destino o parámetros a tal efecto. Los equipos tienen predefinidos el nombre de los servicios en lugar de los números de puertos para que sea más intuitivo.

Switch01(config)#access-list 110 deny tcp any host 172.16.30.2 eq ?
   <0-65535> Port number
   bgp Border Gateway Protocol (179)
   chargen Character generator (19)
   cmd Remote commands (rcmd, 514)
   daytime Daytime (13)
   discard Discard (9)
   domain Domain Name Service (53)
   drip Dynamic Routing Information Protocol (3949)
   echo Echo (7)
   exec Exec (rsh, 512)
   finger Finger (79)
   ftp File Transfer Protocol (21)
   ftp-data FTP data connections (20)
   gopher Gopher (70)
   hostname NIC hostname server (101)
   ident Ident Protocol (113)
   irc Internet Relay Chat (194)
   klogin Kerberos login (543)
   kshell Kerberos shell (544)
   login Login (rlogin, 513)
   lpd Printer service (515)
   nntp Network News Transport Protocol (119)
   pim-auto-rp PIM Auto-RP (496)
   pop2 Post Office Protocol v2 (109)
   pop3 Post Office Protocol v3 (110)
   smtp Simple Mail Transport Protocol (25)
   sunrpc Sun Remote Procedure Call (111)
   syslog Syslog (514)
   tacacs TAC Access Control System (49)
   talk Talk (517)
   telnet Telnet (23)
   time Time (37)
   uucp Unix-to-Unix Copy Program (540)
   whois Nicname (43)
   www World Wide Web (HTTP, 80)

Pues si lo que queremos es bloquear el Puerto 80, quedaría:

Switch01(config)#access-list 110 deny tcp any host 172.16.30.2 eq 80 log 

Como veréis podremos loguear cada vez que un paquete “machee” con esa sentencia. Eso está bien como control, pero ojo que nos puede inundar de mensajes la consola.

ACL Named

Las ACl Named (Nombradas) son aquellas que en lugar de configurarlas con un número, lo podremos hacer con un nombre para que nos sea más intuitivo. La única diferencia será anteponer el término IP a lo que hemos visto.

Switch01(config)#ip access-list standard BlockSales
Switch01(config-std-nacl)#
Switch01(config-std-nacl)#deny 172.16.40.0 0.0.0.255
Switch01(config-std-nacl)#permit any
Switch01(config-std-nacl)#exit 

Y en lo referente a las ACLs esto es todo. EL tema da para mucho más así que aquí os dejo algún otro enlace para que profundicéis sobre el tema.

Link 1

Link 2

Link 3

Link 4

El objetivo de este artículo ha sido mostrar una funcionalidad que no debemos dejar de pasar de alto para proteger nuestras comunicaciones entre sistemas, equipos y dispositivos. Las ACLs son son uns sustituto de un cortafuegos pero pueden ser un aliado muy, muy bueno.

Espero que os haya gustado.

Un saludo!!!

Cuando VLANs y Firewalls no son suficientes

Posted on por
Anuncios

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:

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.

 Link 1

Link 2

Link 3

Fortinet también tiene soluciones similares. Os dejo más links:

Link 1

Link 2

Link 3

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 .