Informe
SISTEMA SCADA MONARCH
COMUNICACIร N INTERSITE CCP-CCR
Esteban Hermosilla Cornejo Alumno en Prรกctica OACT-SCADA Transelec S.A.
Resumen Se pidió investigar las comunicaciones existentes entre la subestación de Cerro Navia y Alto Jahuel, con el fin de poder encontrar y aislar la aplicación que, al enviar paquetes de datos, colapsa el sistema. Para ello primero se procedió a entender la arquitectura del sistema SCADA, con el fin de estar en conocimiento del tipo de información y su relevancia en la comunicación entre las subestaciones. El primer desafío fue encontrarse en la arquitectura con un Firewall marca WatchGuard, siendo este un entorno desconocido, a nivel de configuración, por lo que tuvo que indagar, tanto en el modelo que estaba presente en la arquitectura SCADA, como en sus métodos de configuración. Luego se crearon propuestas y alineamientos de trabajo, para el desarrollo de la actividad. Para esto se realizaron visitas a terreno, en específico a subestación Cerro Navia a sala de operaciones de TECNET, donde se pudo ver en terreno que la estructura en el plano no se ve reflejada en la parte física. Con esta adversidad, se replantearon un poco las propuestas para poder dar curso a las mediciones correspondientes. En la primera instancia de medición, en la cual se obtuvo datos a través del software Wireshark, donde se encontró con la primera traba para el desarrollo del proyecto. De los 6.571.034 paquetes de datos obtenidos un 94.59% de estos estaba encriptado, correspondiendo a 6.215.227 paquetes, de los cuales no se pudo obtener ningún tipo de información. Por lo que se generaron propuestas para proseguir con la investigación, escogiendo la más prudente para un servicio que está en uso. Dado la propuesta escogida, se realizaron nuevas mediciones en los Switch correspondientes a cada LAN que desemboca en el Firewall. En esta adquisición de datos se obtuvo resultados, claros y no encriptados, con estos se dispusieron a realizar análisis, el cual se expone a lo largo de este trabajo.
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Índice Resumen.............................................................................................................................................. 2 Índice ................................................................................................................................................... 3 Introducción ........................................................................................................................................ 6
1.
Antecedentes Generales. ........................................................................................... 7 1.1.
Arquitectura SCADA ............................................................................................. 7
1.2.
Comunicación ....................................................................................................... 8
2.
Cursos de acción. ........................................................................................................ 9
3.
WatchGuard.............................................................................................................. 10 3.1.
Configurar WatchGuard XTM510 ....................................................................... 10 Entorno de Configuración ........................................................................... 10
4.
5.
6.
7.
Información Preliminar ............................................................................................. 14 4.1.
Especificaciones/Características ........................................................................ 14
4.2.
Contenido Softraid ............................................................................................. 16
4.3.
Ancho de Banda ................................................................................................. 18
4.4.
Tabla de Direcciones IP ...................................................................................... 19
Primera Adquisición de Datos .................................................................................. 22 5.1.
Wireshark ........................................................................................................... 22
5.2.
Firewall WatchGuard.......................................................................................... 25
5.3.
Conclusiones....................................................................................................... 31
Segunda Adquisición de Datos ................................................................................. 32 6.1.
Switch Cisco ........................................................................................................ 32
6.2.
Wireshark ........................................................................................................... 33
6.3.
Tablas Dinámicas ................................................................................................ 35
Tráfico por Switch ..................................................................................................... 37 7.1.
Aporte por Switch al Firewall ............................................................................. 37
7.2.
Switch A (SCADA/FEP/PDS) ................................................................................ 38
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Conclusiones Tráfico INTERSITE .................................................................. 39 7.2.1.1. IPv4........................................................................................................ 40 7.2.1.2. TCP ........................................................................................................ 47 7.2.1.3. UDP ....................................................................................................... 54 Conclusiones Tráfico LOCAL ........................................................................ 57 7.2.2.1. IPv4........................................................................................................ 57 7.2.2.2. TCP ........................................................................................................ 58 7.2.2.3. UDP ....................................................................................................... 63 7.3.
Switch D (ICCP) ................................................................................................... 67 Conclusiones Tráfico INTERSITE .................................................................. 68 7.3.1.1. IPv4........................................................................................................ 69 7.3.1.2. TCP ........................................................................................................ 71 7.3.1.3. UDP ....................................................................................................... 72 Conclusiones Tráfico LOCAL ........................................................................ 73 7.3.2.1. IPv4........................................................................................................ 73 7.3.2.2. TCP ........................................................................................................ 75 7.3.2.3. UDP ....................................................................................................... 78
7.4.
Switch E (Corporativo)........................................................................................ 81 Conclusiones Tráfico INTERSITE .................................................................. 83 7.4.1.1. IPv4........................................................................................................ 84 7.4.1.2. UDP ....................................................................................................... 85 Conclusiones Tráfico LOCAL ........................................................................ 85 7.4.2.1. IPv4........................................................................................................ 85 7.4.2.2. TCP ........................................................................................................ 86 7.4.2.3. UDP ....................................................................................................... 90
8.
Conclusiones Tráfico INTERSITE ............................................................................... 92 8.1.
DAC ..................................................................................................................... 93 IPv4.............................................................................................................. 93 TCP .............................................................................................................. 96 SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
UDP ............................................................................................................. 97 8.2.
HIS....................................................................................................................... 99 IPv4.............................................................................................................. 99 TCP ............................................................................................................ 101 UDP ........................................................................................................... 102
9.
IP Desconocidas ...................................................................................................... 104
10. Conclusiones Generales del Trabajo ...................................................................... 106
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Introducción Hoy en día las redes, como internet, cobran vital importancia a la hora de hacer envío de información que consideramos relevante. En este tipo de comunicación se presentan diferentes tipos de tráficos que demandan ancho de banda para poder circular por nuestras redes y/o por internet. Ya que siempre queremos hacer uso de la máxima capacidad de nuestras redes, termina siendo de gran valor controlar el uso que se hace del ancho de banda, para esto se debe administrar según nuestras necesidades. Para estos fines existes funciones dentro de los equipos enrutadores, como la Calidad de Servicio (QoS), que se refiere a diversos mecanismos destinados a asegurar el flujo ágil de datos en la red, valiéndose de mecanismos de asignación de prioridades a diferentes tipos de tráfico que requieran tratamiento especial. Debemos entender el concepto de QoS como diferenciado y comprensivo de control de ancho de banda. En esta ocasión se nos presenta la oportunidad de hacer uso de esta función para solucionar la problemática que presenta la comunicación de la subestación Cerro Navia, Centro de Control Principal (CCP) y Alto Jahuel, Centro de Control de Respaldo (CCR), línea que de ahora en adelante denominaremos INTERSITE. El problema principal en comunicación, es que cada cierto intervalo de tiempo, la línea se satura y se pierde comunicación entre ambas subestaciones, perdiendo información vital. Objetivo general •
Comprender flujo de información en INTERSITE, para optimizar el rendimiento del ancho de banda entre CCP y CCR.
Objetivo específico • • •
Comprender la arquitectura SCADA. Realizar mediciones que permitan estimar el ancho de banda utilizado en INTERSITE. Determinar los puertos IP, TCP y UDP relevantes, en comunicaciones INTERSITE.
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Antecedentes Generales. 1.1. Arquitectura SCADA Se inicia el proyecto por la comprensión de la arquitectura SCADA, en la cual radica la importancia de los paquetes de datos que el INTERSITE intercambia entre la subestación Cerro Navia y Alto Jahuel.
Dentro de la arquitectura SCADA se reconocen equipos que presentan un desafío, ya que el modo de programación que presentan se aleja de lo conocido, como lo es la configuración por CLI de Cisco, por lo que los Firewalls de marca WatchGuard presentan una oportunidad de ampliar dicho ambiente. He aquí el primer paso para la comprensión del INTERSITE. Para poder conocer los firewall de WatchGuard, se requirió el modelo de este, el cual corresponde a un XTM510. Luego retomaremos y ahondaremos en este equipo.
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
1.2. Comunicación La comunicación del INTERSITE se efectúa actualmente a través de una línea de cobre con capacidad máxima de 18Mbps y se tiene una de respaldo de 2Mbps. Se tiene como plan a futuro, y por esto la realización de este proyecto o estudio, la implementación de fibra óptica (FO) de capacidad de 100Mbps.
CCP
CCR 18 Mbps 100 Mbps Lı́nea Respaldo
2 Mbps
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Cursos de acción. A continuación, se expondrán las actividades realizadas para alcanzar el objetivo planteado. Estas actividades se expondrán de una forma evolutiva en la recopilación de información, como en el desarrollo, dejando en otro plano la cronología de estas. • • • • •
Comprender la arquitectura SCADA y los antecedentes generales. Conocer el tipo de configuración que usan los equipos WacthGuard. Obtención de información preliminar de los equipos. Realizar la adquisición de datos. Realizar análisis de estos y proponer solución.
En el caso de encontrarse con alguna dificultad, se estima realizar un feedback y plantear nuevos cursos de acción, o realizar propuestas de avance.
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
WatchGuard 3.1. Configurar WatchGuard XTM510 Para el desarrollo del proyecto es necesario entender el entorno donde se configuran los Firewalls de WatchGuard, ya que deberemos obtener información de estas configuraciones que posteriormente serán de utilidad. Entorno de Configuración Los dispositivos WatchGuard, presentan para su configuración entornos e interfaces muy amigables, alejándose de un nivel de configuración de Cisco que ocupa CLI. Para estos entornos la empresa cuenta con manuales muy detallados para poder realizar las configuraciones necesarias. Estos entornos son: • •
XTM Web UI WSM (WatchGuard System Manager)
El primero es un entorno tipo web browser, que se accede por la IP del dispositivo conectado a una LAN, el cual tiene una presentación como se muestra a continuación, para la configuración de las VLAN.
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Mientras que el segundo es un programa que se instala en un sistema operativo, el que presenta la siguiente interfaz, para el mismo ejemplo anterior.
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
En TECNET constan con WSM por lo que de ahora en adelante trabajaremos en ese entorno, a continuación, se muestra la pantalla de configuración para INTERSITE. Aquí se puede apreciar configuraciones iniciales y las opciones de monitoreo de cada una de las terminales o firewall.
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Información Preliminar 4.1. Especificaciones/Características Si bien la primera visita realizada a la subestación de Cerro Navia estaba bajo el marco de ver en terreno, en conjunto con TECNET, la arquitectura SCADA y como es su centro de operación, de igual forma se pudo recopilar información básica de configuración del Firewall, para poder contrastarla con la encontrada en la web de WatchGuard para la serie XTM500. Según catalogo los Firewall XTM500 pueden tener hasta 75 VLAN, contrastando con los instalados en la subestación que tienen un máximo de 200 VLAN.
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Otros datos que se recopilaron inicialmente son las interfaces y sus LAN respectivas, las que se muestran a continuación.
También se pudo observar y corroborar, que el esquema de la arquitectura presenta switch Cisco en la mediación entre INTERSITE y las respectivas LAN. Estos switch son Catalyst 2960G, en su mayoría, y 3750G.
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
4.2. Contenido Softraid Con el fin de seguir indagando, se optó por analizar que carpetas de Softraid, el cual se estima que hace colapsar la línea, son las que se copian a través del INTERSITE. Para esto se accedió por escritorio remoto a un entorno Linux, donde por comando se fue extrayendo la información de cada carpeta, registrando el peso en kilobytes y los flags correspondientes. Un ejemplo de esta toma de datos es la siguiente imagen.
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
De esta información se realizó una tabla resumen de cada carpeta.
Donde los flags corresponden a: • • • • • •
r: habilitar la recursión de árbol de directorios. x: habilitar el reflejo de eliminación de archivos y directorios. n: mantener el más nuevo. c: deshabilitar el procesamiento de verificación por redundancia cíclica. z: habilitar compresión para archivos Softraid. h: habilita añadir solo procesamiento.
De este resumen se pudo obtener el peor caso, es decir, que si en los servidores de respaldo se llegase a perder toda la información, el tamaño (en KB) total de cada carpeta deberá ser copiado y enviado por el enlace de 18Mbps. Se puede observar que hay carpetas que en su totalidad tienen un tamaño de GB, por lo que sería irrisorio enviar dicha información por tal enlace. Ahora bien, cada flag indica cómo y en qué circunstancias se enviaran los paquetes de datos, en su gran mayoría responden solo a los archivos creados recientemente.
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
También se puede extraer el tiempo en donde ocurre cada proceso de copia y su ciclo de repetición, es decir, tomando como ejemplo la primera carpeta de DAC1 “SYNC_FSPEC_1 =${OSI}/bin/*_cal*” se tiene que su frecuencia de ocurrencia o de copia de datos, es cada 30 min y su offset con respecto al tiempo inicial es 1 min, siendo más precisos, una vez transcurrido 1 min desde el inicio de la conexión esta carpeta copiará los archivos nuevos, y luego de 30min, es decir, 31 min después del inicio, intentará copiar una vez más los archivos recientes. Si extrapolamos esto, ocurrirá algo parecido al sistema solar, todos los planetas tienen un tiempo de traslación distinto, pero cada cierto tiempo estos se alinean, por lo que proyectamos esto ocurrirá que cada cierto tiempo todas las carpetas empezaran a solapar información, por lo que se puede provocar un cuello de botella, en caso de la existencia de nuevos archivos en más de una carpeta. 4.3. Ancho de Banda Posterior al análisis del contenido que Softraid debiese copiar entre los servidores, se realizó la medida gráfica del ancho de banda ocupado por cada servicio en el INTERSITE. A continuación, se muestra la gráfica obtenida en el transcurso del tiempo.
Se presentan algunos pick de salida de 17,449.47 Kbps, solo considerando los servicios atribuidos a Softraid.
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
4.4. Tabla de Direcciones IP TECNET hace entrega de una tabla con todos los Direcciones IP en uso de la configuraciรณn del sistema SCADA/EMS redundante. Con estas direcciones IP podremos reconocer cada LAN presente en la configuraciรณn SCADA y se identificรณ cada elemento presente en la arquitectura entregada con anterioridad. A continuaciรณn se muestra la tabla de direcciones IP con sus respectivas LAN.
SISTEMA SCADA MONARCH - COMUNICACIร N INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Con esta información se procedió a realizar un re-mapeo de la arquitectura pero en esta ocasión sin las especificaciones técnicas de cada dispositivo, sino más bien, solo con sus direcciones IP. Para esto se cruzó información de la arquitectura SCADA “vigente” (Tecnet ya emitió una orden de trabajo, para realizar un levantamiento y poder precisar tanto conexiones y equipos en el sistema), con el Excel de IP entregado anteriormente, a continuación, se muestra una sección de ésta, ya que por su tamaño sería ilegible ajustar a tamaño carta.
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Primera Adquisición de Datos Con ésta información recopilada se propone realizar una conexión de un SNIFFER al Firewall con el fin de realizar un monitoreo de tráfico de la red, en este caso INTERSITE y así poder observar su tráfico en el tiempo y tomar decisiones con respecto a que puerto y aplicación hace uso de éste.
Para poder realizar el puerto espejo en los Firewall WatchGuard se pide a personal de Tecnet realice la configuración necesaria para poder realizar la medición. 5.1. Wireshark Para la toma de datos se ocupó Wireshark, el cual es un analizador de protocolos.
Una vez realizada la conexión del computador al puerto espejo en el INTERSITE, desde el Firewall fw1 en Cerro Navia, se inicia con la recopilación de datos a través de Wireshark, como se muestra en la imagen.
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
La toma de datos se realizó durante un lapso de tiempo de 2,25hrs continuas, obteniendo 6.571.034 paquetes de datos. Se hizo un gráfico de análisis para entender el comportamiento de estos paquetes y su interacción entre fuente y destino, para posteriormente realizar un gráfico IO del INTERSITE, como se muestra a continuación.
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Este último gráfico muestra la cantidad de Bytes/tick y cada tick tiene un intervalo de 1 segundo, la escala que se escogió es logarítmica para poder apreciar todos los protocolos. De aquí se obtuvo información relevante, la cantidad de paquetes que envían las RTU’s que ocupan el protocolo 104apci, son casi despreciables a los de protocolo ESP. Así también se SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
realizó estadísticas por jerarquía de protocolos, como se muestra a continuación, arrojando valores concluyentes.
El 5.16% de los paquetes corresponden a envíos por protocolo TCP, dentro de este tenemos a los que corresponden a 140apci es decir a RDP y RTU’s que aportan el 0,58%de ltráfico, mientras que el 94.59% son paquetes de datos en ESP, que es un tipo de encriptación la que otorga confidencialidad de en la entrega del paquete de datos, que es el grueso de toda la información en el INTERSITE. Por lo que, no se obtuvo en primera instancia información alguna de que puerto ocupa, menos a que servicio o IP o LAN corresponden. 5.2. Firewall WatchGuard Dado que se obtuvo que la gran mayoría de los datos estaban encriptados, a continuación se realiza un análisis mayor en la configuración y entorno de WatchGuard. Para esto se abre WSM, seleccionamos el Firewall que analizaremos, en este caso fw1, y nos dirigimos a Policy Manager. Aquí encontraremos todos los enlaces con sus respectivos nombres, direccionalidad y puertos, como se muestra en la siguiente imagen.
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Para seguir entrando en la configuración general del Firewall, dentro de la ventana de Policy Manager nos dirigimos al siguiente icono.
Él que nos abrirá una ventana emergente de Gateways. Acá encontraremos todas las puertas de enlaces que tiene fw1.
Al hacer clic en editar, nos aparecerá otra ventana emergente donde podemos ver las puertas de enlace y su encriptación, tal como se muestra a continuación existe una encriptación para dicho enlace.
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Para saber qué estamos encriptando se hace clic en el siguiente icono:
Con esto se abrirá una ventana emergente con los IPSec Tunnels, donde observamos la presencia de 4, como se muestra a continuación.
Ahora se procede a inspeccionar que tráfico se está encriptando, para esto hacemos clic en editar y nos aparece las direcciones locales y remotas, como también la pestaña para poder ajustar el tipo de encriptación. A continuación se muestra el Tunnels de SCADA-BSCADA (bfw1).
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Como se pudo apreciar en todos y cada uno de los IPSec Tunnels, todos tiene como metodo de encriptación ESP-AES-SHA1. Ahora veremos como ver esta encriptación, para analizarla primero nos vamos a VPN en la barra de menú, y seleccionamos Phase2 Proposals…
A continuación, hacemos clic en editar, escogemos ESP-AES-SHA1 con el fin de ver que la compone.
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Podemos observar que nos dice el tipo de Proposal “ESP”, el tipo de autenticación “SHA1” y tipo de encriptación AES (256-bit).
Otra forma de ver que encriptación se está efectuando, podemos dirigirnos a WSM, en la pestaña Device Status, tendremos el árbol de la configuración que tiene los Firewall. Podemos apreciar que existe un Cluster con los dos Firewall de Cerro Navia, donde fw1 y fw2 presentan una configuración global de encriptación. Al extender el árbol hacemos clic en Branch Office VPN Tunnels, luego en Gateway: bw1 – 9 active tunnel(s), donde nos apareceran los 9 tuneles creados, con las LAN locales que encripta, tipo de encriptación y
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
cantidad de paquetes enviados totales. Como se muestra en la siguiente imagen de la que se extrajo la informaciรณn y se tabulo en Excel.
SISTEMA SCADA MONARCH - COMUNICACIร N INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
La información que se extrajo de la configuración se expresa en la siguiente tabla, se presenta a continuación tanto de fw1 como de bfw1, Cerro Navia y Alto Jahuel respectivamente. Se añadió en la tabulación de los datos, el nombre de las LAN correspondientes tanto a nivel local como remoto para poder hacer una comprensión macro del sistema SCADA.
5.3. Conclusiones Si bien, la mayoría del tráfico está encriptado de igual forma esta primera adquisición arrojó valores importantes, ya que se puede saber cuánto es el uso en porcentaje de todas las RTU, ya que OSI, con anterioridad dejó entrever que estas podían causar el colapso de INTERSITE, pero estas solo son 0,58% del tráfico, los que corresponden a envíos por protocolo TCP o 140apci. Dada la existencia de tráfico encriptado, es que se llega a las siguientes propuestas: 1. Realizar la desencriptación de los paquetes para su medición, lo que involucra realizar pruebas previas de encriptación de escritorios remotos con el fin de analizar la respuesta del INTERSITE. 2. Realizar mediciones de Firewall adentro, es decir desde las respectivas LAN o Switch que llegan a los WatchGuard. Dado que el nivel de riesgo del primero es alto, para un sistema que está en funcionamiento y de este depende el correcto desempeño del SCADA, es que se opta por la segunda propuesta.
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Segunda Adquisición de Datos Para esta etapa se debe prever el entorno donde se desarrollaran las mediciones. 6.1. Switch Cisco Ya que se tiene switch Cisco involucrados en la arquitectura, veremos que es necesario para poder realizar la medición con un Sniffer. Un switch es un dispositivo de capa 2 que opera mediante direcciones MAC. Cuando un switch recibe una trama Ethernet en uno de sus puertos y no conoce a que puerto está conectado el host con la MAC destino, este realiza un “flooding” de tráfico unicast, es decir, el switch transmite la trama a través de todas sus interfaces. Cuando el host para el que estaba dirigida la trama responde o envía tráfico, el switch guarda la información y el puerto asociado a esa dirección MAC. Una vez que el switch completa su tabla en memoria, el tráfico unicast ya no aparece en todos los puertos, en vez de eso, el switch envía el tráfico al puerto en el que sabe que está ubicada la dirección MAC destino. De esta manera el tráfico entre dos hosts no puede ser visualizado por un tercero, en este caso un Sniffer. A continuación se presenta la configuración a realizar para poder conectar el sniffer.
Afortunadamente los realizadores de Switch’s pensaron en esto y existe una tecnología que nos permite que un puerto reciba una copia de las tramas enviadas y recibidas en puertos seleccionados, permitiéndonos de esta manera escuchar las conversaciones entre otras computadoras. La característica anterior se conoce en Cisco como SPAN (Switched Port Analyzer) y de manera general se conoce como puertos espejo (port mirroring). A continuación, se muestra como el switch refleja la información enviada a B hacia el puerto donde está conectado el Sniffer. SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Para poder realizar la configuración, en el caso de cisco se necesita líneas de código las que corresponden a las siguientes: Switch (config) #monitor session 1 source interface fastethernet 0/1 - 23 both Switch (config) #monitor session 1 destination interface fastethernet 0/24 6.2. Wireshark En esta ocasión se realizó la toma de datos como se muestra en el siguiente esquema:
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Para la toma de datos en los respectivos switch de cada LAN, que de ahora en adelante nombraremos como SwA al Switch correspondiente a Sistema Productivo y DMZ remotas (LAN A), SwD al correspondiente al ICCP (LAN D) y SwE al Switch Corporativo (LAN E). Una vez obtenido los archivos, los cuales corresponden a 20 minutos de conexión a cada Switch, se procede a la extracción de información de estos.
Dado el tamaño de cada archivo que en promedio supera los GB, es que se procede a traspasar la información a Excel para un manejo más rápido, ya que para cada movimiento en Wireshark, este vuelve a cargar toda la base de datos, teniendo tiempos muertos en el proceso.
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
6.3. Tablas Dinámicas Excel se presenta como una opción viable a la hora de agilizar los procesos y el análisis de datos, determinando que la mejor forma de procesar la cantidad de datos no menor a 12 millones, es a través de tablas dinámicas, como se muestra a continuación:
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Dado que una de las virtudes de las tablas dinámicas es poder aplicar filtros, es que se procede a realizar los siguientes análisis: • • • • •
Tráfico en cada Switch. Tráfico hacia INTERSITE de cada switch. Qué destino tiene el tráfico que no se dirige a INTERSITE. Qué IP son las que más trafican en cada Switch. Qué Puerto TCP/UDP son relevantes.
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Tráfico por Switch Se realizará un análisis de cada archivo que contiene información del tráfico al switch correspondiente. Se desglosará en el tráfico que se dirige a INTERSITE como el tráfico local, tratando de exponer que dispositivos son de importancia, señalando puertos que trafican mayor información.
7.1. Aporte por Switch al Firewall Cada switch presenta un aporte en el flujo de información del Firewall WatchGuard, es por esto que es preciso identificar cuanto de este flujo corresponde a comunicación a nivel de INTERSITE y cuanto solo es a nivel local. Se destinó a cada Switch un color; Azul (SwA), Amarillo (SwD) y Verde (E).
Para esto se analizó la direccionalidad de los paquetes adquiridos por cada Switch, pudiendo así determinar si pertenecían o no a comunicaciones de INTERSITE. De esta manera se corroboró que el mayor flujo de información es a nivel local llegando a que el 86,25% tiene relación a comunicación entre LAN SCADA/FEP/PDS-ICCP-Corporativo y solo el 13,75% corresponde a INTERSITE.
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
7.2. Switch A (SCADA/FEP/PDS) Para realizar la adquisición de datos se configura el puerto 29 del Switch Catalyst 3750G con port mirroring, como se describe en las líneas de comando en el apartado anterior.
El archivo extraído desde Wireshark, para su mejor manipulación, se dividió en 7 partes ya que el archivo original tenía un peso superior a 3GB. Es por esto que se traspasó la base de datos a Excel, para poder aunarla. Una gráfica en el tiempo de los paquetes obtenidos se muestra a continuación, desde el archivo Swa1 y Swa2:
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Se debe tener en cuenta que, los archivos son la continuación lineal en el tiempo, es decir la gráfica provocada por Swa2 es inmediatamente después de la Swa1. Con el archivo con los datos del tráfico extraído se comienza con el análisis de este dispositivo y su comportamiento dentro de la arquitectura. Antes que todo, se realizará el análisis de cuanto tráfico del capturado corresponde a comunicaciones internas de la LAN respectiva o entre LAN que switch comunica, para posteriormente abarcar el tráfico hacia INTERSITE.
Dentro del SwA se observa un total de 5.753.464.477 de Bytes traficados, de los cuales se reconoce por las IP origen y destino que el 72,68% de los datos son comunicaciones entre LAN locales (Cerro Navia), un 27,31% de tráfico hacia INTERSITE y un 0,01% de tráfico que no se reconoce fuente o destino dentro de la arquitectura, dado que su porcentaje es bajo, casi despreciable, es que no se incurrirá en mayor análisis, pero se propone generar un levantamiento de que dispositivos presentan dichas IP, una vez determinado esto, analizar por qué del tráfico. De este análisis cabe destacar que el mayor flujo de información, Origen/Destino y viceversa, se presenta hacia LAN D, siendo está un 68,04% con 3.914.371.691 bytes de tráfico. Conclusiones Tráfico INTERSITE A continuación se realiza una gráfica de tendencia para saber que IP de origen son las que aporta de mayor manera al tráfico en INTERSITE desde el Switch A:
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Del tráfico que se presenta en el Switch con destino INTERSITE, podemos distinguir tres IP de origen que trafican el 91,81% de bytes del total del Switch, en los que se tiene tres tipos de conversación entre dispositivos, donde en su mayoría son tráfico IPv4 y TCP, con un 56,09% y 43,71% respectivamente.
7.2.1.1. IPv4 Profundizando un poco en el tipo de conversación entre los dispositivos, tenemos la siguiente gráfica la que expone que dirección IP como origen presenta mayor tráfico, para poder identificar quienes conversan dentro de la arquitectura.
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Donde se puede apreciar que la IP de origen que sobre salen son las 10.80.210.11/10.80.210.12 que entre ambas realizan el 92,56% del trรกfico en IPv4.
A continuaciรณn se muestra la tabla dinรกmica generada del trรกfico IPv4 de SwA:
SISTEMA SCADA MONARCH - COMUNICACIร N INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
De aquí se concluye que la mayor comunicación se efectúa desde el DAC CCP (Cerro Navia) hacia el DAC CCR (Alto Jahuel) a través de la IP 10.80.210.11, que trafica el 96,92% solo con la IP 10.80.216.11, con 550.892.643 Bytes de un total de 568.422.076 Bytes, generando la siguiente gráfica.
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Luego tenemos que la IP 10.80.210.12, es la segunda en la cantidad de tráfico, por lo que a través de la tabla dinámica sabemos cuál es su mayor receptor:
Resulta ser la misma dirección IP, de destino, anterior. Aquí equivale al 99,90% del tráfico total de la IP origen, con 247.217.745 Bytes de un total de 247.453.207 Bytes.
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Por tanto, el mayor flujo de información es desde DAC a DAC. También se puede concluir que la IP 10.80.216.11, es el destino más recurrente, como se muestra en la siguiente imagen, donde se ordenó la tabla dinámica por IP de destino:
Donde 10.80.210.11 trafica el 69,02% del total de bytes que se dirige a DAC del CCR, como se muestra en la siguiente gráfica.
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
La tercera IP que presenta flujo de informaciรณn considerable es la 10.80.210.16, con mรกs de 54.000.000 Bytes, como se muestra a continuaciรณn:
Este flujo tiene como destino la IP 10.80.216.15 entre otras, representando para ser exactos un 99,99901% de los Bytes traficados por la 10.80.210.16. Ahora si filtramos por la IP destino tenemos la siguiente tabla: SISTEMA SCADA MONARCH - COMUNICACIร N INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Tenemos que del trรกfico total que se dirige a la IP 10.80.216.15, el 99,26% proviene de la IP 10.80.210.16, es decir es una comunicaciรณn entre Servidores de Aplicaciรณn.
SISTEMA SCADA MONARCH - COMUNICACIร N INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
7.2.1.2. TCP De las conversaciones por TCP, se puede destacar que a mayor cantidad de informaciรณn se trafica desde el DAC de CCR con 612.696.374 Bytes de un total de 686.866.444 Bytes que fluye en TCP.
Dentro de estos destaca la IP 10.80.216.11 que del total representa el 89,2%, seguida por la 10.80.216.15, con mรกs de un 6%.
SISTEMA SCADA MONARCH - COMUNICACIร N INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Se realiza el filtro correspondiente en la tabla dinรกmica, con el fin de ahondar en el anรกlisis.
Cabe mencionar que este flujo tiene como destino dos puertos IP, que a su vez corresponden al DAC de CCP, es decir, a las IP 10.80.210.11 y 10.80.210.12.
SISTEMA SCADA MONARCH - COMUNICACIร N INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Para seguir profundizando en comunicaciรณn TCP, es conveniente precisar que puertos son los involucrados en este enlace, es por esto que dentro del archivo Excel SwA se procede a filtrar la informaciรณn, desplegรกndose la siguiente tabla:
El listado de puertos de origen anterior, corresponden a puertos tanto hacia 10.80.210.11 como hacia 10.80.210.12, para poder desarrollar de mejor manera separaremos el anรกlisis en IP y dentro de este, en puerto de Origen, finalizando con puerto de Destino. Primero, para el destino 10.80.210.11 se tiene:
SISTEMA SCADA MONARCH - COMUNICACIร N INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Para los puertos de Origen se tiene, que el mรกs del 89% lo trafica el puerto 34375, luego con un poco mรกs que el 9% el puerto 26111. En tanto los puertos de Destino, que corresponde a la segunda tabla anterior, se tiene que el puerto 8012 representa mรกs del 89% de trรกfico, lo prosigue el puerto 3614 con un 9,73%.
En segundo lugar tenemos la IP 10.80.210.12 como destino:
SISTEMA SCADA MONARCH - COMUNICACIร N INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
En este caso como presenta un único puerto de origen (10083) y destino (3614), se tiene que este es el puerto que corresponde al 24,03% de la conversación hacia 10.80.210.12. Continuando con el análisis de la segunda conversación TCP más relevante, es que llegamos a analizar la IP 10.80.216.15, en la cual realizaremos el mismo proceso anterior, por lo que realizaremos filtros para obtener los puertos que comunica.
Como se observa en la primera tabla, se tiene que dicha IP tiene como destino el Servidor de Aplicaciones del CCP, en ambas direcciones IP 10.80.210.15 como la 10.80.210.16. Al igual que el caso anterior dividiremos el análisis en dos, para abordar sus respectivos puertos TCP.
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Para la IP 10.80.210.15 tenemos:
Apreciamos que para la IP 10.80.210.15 se tiene solo un porte de origen (44782) y uno de destino (3617), lo que corresponde al 0,51% del trรกfico desde 10.80.216.15. Para la IP 10.80.210.16, se tiene lo siguiente:
SISTEMA SCADA MONARCH - COMUNICACIร N INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
En la primera tabla se aprecian los puertos de Origen, donde el puerto 35745 representa el 99,4% del tráfico por puerto. Mientras que en los puertos Destino se tiene que el 8012 representa el 99,48% del tráfico total, como se muestra en el siguiente par de gráficos.
Con el fin de reafirmar que las comunicaciones en su mayoría son entre 10.80.210.11 y 10.80.216.11 o viceversa, es que se buscó en el tiempo en este caso del archivo Swa2, uno de los peak en Bytes, por lo que debe tener en cuenta que el rango de tiempo debe ser 70.520s y 70.530s, la que presenta mayor tráfico de información en el INTERSITE, entre las IP antes señaladas.
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
7.2.1.3. UDP Del trรกfico UDP se tiene que el 97,56% del total de las IP origen, corresponde netamente a la IP DAC, siendo el que mรกs aporta al trรกfico UDP en el SwA.
SISTEMA SCADA MONARCH - COMUNICACIร N INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Este tráfico en su mayoría corresponde, como destino, Servidor de Seguridad CCR, Consolas de Operación CCR, DAC, HIS, Servidor ICCP, entre otros. Es por esto que analizaremos que IP y puertos involucra.
Donde las IP más relevantes, se representan en el siguiente gráfico de torta:
Ya que no es determinan, o de cierta forma, no da abismos de por dónde abarcar el tema, es que se intentó filtrar por Puerto de Origen, obteniendo una cantidad de 1.325 puertos SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
que entre ellos trafican 3.116.406 Bytes en total. Luego realizรณ el filtro por Puerto Destino y se obtuvo algo mรกs decidor, como se muestra a continuaciรณn.
Como se observa se tiene solo dos puertos de destino, los que son el 161 el que representa el 99,982% del total de Bytes y el puerto 123 representa el resto de Bytes. Por lo que ahora nos centraremos en las IP destinos que se llevan la mayor carga, dentro del Puerto Destino 161, este puerto corresponde a SNMP Simple Network Management Protocol. La IP 10.80.216.17 se tiene que el puerto Origen 52626 representa el 11,42% de todo el flujo en el puerto 161, luego lo siguen 69 puertos diferentes con el 0,92% y el resto se divide entre otros 120 puertos distintos. Se tiene una comunicaciรณn entre DAC CCP y Servidor de Seguridad CCR.
SISTEMA SCADA MONARCH - COMUNICACIร N INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Para la IP 10.80.216.53, se tienen que el 2,23% del flujo de información corresponde al puerto Origen 18316, repartiendo del resto del tráfico en 183 puertos distintos. Esta comunicación como sabemos proviene del DAC CCP, hacia una Consola de Operación.
Conclusiones Tráfico LOCAL 7.2.2.1. IPv4 Como se mencionó con anterioridad el mayor tráfico presente es con sentido LAN D, es por esto que merece, a pesar de no ser tráfico INTERSITE, análisis e identificar quienes comunican. Por este motivo realizamos los filtros correspondientes y se obtiene las IP de LAN A de importancia en la comunicación NO INTERSITE.
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Podemos observar que la IP 10.80.210.11 quien presenta el 99,997% del total de Bytes transmitidos entre las LAN en CCP. Esta se comunica en su mayoría con la 10.80.213.20, de la LAN D, correspondiendo al 91,48% del total de Bytes transmitidos. A continuación, se exponen los principales puertos de destino.
De esto se puede concluir que la mayor comunicación entre estas LAN es de DAC (origen) a ICCP (destino) con un tráfico en su mayoría de B hacia A, es decir, ICCP se comunica o hace mayor envío de Bytes que el DAC. 7.2.2.2. TCP Del mismo archivo Excel ahora se filtra por tráfico TCP para determinar que puertos son los que hacen mayor tráfico. Con el debido filtraje de direcciones origen y destino, se obtiene el listado de los puertos (1099 puerto distintos) origen que más tráfico presentan, el puerto Origen 57913 representa el 71,3% del total del tráfico entre LAN CCP. SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Al expandir observamos el puerto destino, ya tenemos los puertos pero necesitamos saber que dispositivos ocupan aquellos puertos por lo que realizamos modificaciones en la tabla dinรกmica, para obtener las IP origen y destino:
SISTEMA SCADA MONARCH - COMUNICACIร N INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Como se aprecia en la tabla ahora tenemos la IP origen, Port origen, Port destino e IP destino. La comunicación una vez más corresponde a 10.80.210.11 DAC, con 10.80.213.20 ICCP. Al efectuar el filtro desde el puerto de destino podemos observar quien es el que recibe mayor flujo de bytes. En este caso es el puerto 3522, con el 71,3% del total de datos traficados entre todos los puertos destino. También si analizamos por IP de origen encontramos que la IP 10.80.210.11 presenta el 78,26% y dentro de este el puerto destino que más recibe es 3522, del puerto origen 57913, siendo el 99,993%, y el resto se divide en los 103 puerto que se comunican con él (3522).
Como se puede concluir las comunicaciones TCP, corresponden en su mayoría y en amplio porcentaje, entre LAN SCADA y LAN ICCP, específicamente entre Servidor SCADA e ICCP.
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
También corroborando un poco la información acá expuesta, se tiene la siguiente imagen, extraída desde Wireshark. Donde se observa la gráfica en el tiempo del archivo Swa1, donde se analiza un peak y este nos marca en la ventana principal a que paquete o rango de paquetes se refiere. Por qué digo rango de paquetes, porque cada intervalo en la gráfica es de 0.001 segundo, pero la capacidad de adquisición es superior a ello, por lo tanto debemos considerar todos los paquetes que están entre 59.800s y 59.8100s, los que en su totalidad aportan casi 250.000 Bytes. Como se mencionó anteriormente su comunicación es desde ICCP hacia DAC o SCADA, es decir, desde 10.80.213.20 hacia 10.80.210.11 o viceversa.
En este caso no podemos buscar periodicidad en una misma gráfica, ya que los tiempos de cada archivo no superan los 200s y a modo general se apreciaba que estos ocurrían cada 300s como mínimo. Por lo que de sebe abrir el archivo siguiente y buscar su nueva ocurrencia. Por lo que al tener esta frecuencia, debería ser en 359s aproximadamente, pero el archivo Swa1 tiene 200s, entonces se debe buscar en el archivo Swa2 en el segundo 159, obteniendo: SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Que efectivamente existe una ocurrencia, pero también cada dos segundos y fracción.
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
7.2.2.3. UDP Con el mismo procedimiento anterior, filtrando la información de las tablas dinámicas, se obtiene que puertos IP de origen y destinos, son los que más aportan al tráfico de información.
Siendo la IP 10.80.210.11 la que presenta un 95,73% de presencia, la que se comunica con las IP 10.80.214.19, .213.20 y .213.21, con 32,6%, 32,59% y 34,79% respectivamente.
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Ahora expandiremos para ver que puertos de origen y destino están involucrados en dicha comunicación.
Como se puede extraer de la tabla anterior, el puerto UDP de origen que más prepondera es el 47735 con un 25,1% del total, luego están 21 puertos con el 1,79%, cabe mencionar que dentro de la comunicación entre estas dos IP existen 189 puerto de origen, pero puertos de destino son solo dos, de los cuales 188 son el puerto 161, el que presenta el 99,94% de carga, y el otro es el puerto 123.
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Prosiguiendo con el análisis, pasaremos a la siguiente IP destino con más flujo.
De la tabla anterior, el puerto UDP de origen que más prepondera es el 48512 con un 26,85% del total, luego están 19 puertos con el 1,67%, cabe mencionar que dentro de la comunicación entre estas dos IP existen 190 puerto de origen, pero puertos de destino son solo dos, de los cuales 189 son el puerto 161, el que presenta el 99,94% de carga, y el otro es el puerto 123.
Al proseguir con la siguiente IP destino con más flujo.
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
De la tabla anterior, el puerto UDP de origen que más prepondera es el 26533 con un 26,86% del total, luego están 18 puertos con el 1,67%, cabe mencionar que dentro de la comunicación entre estas dos IP existen 189 puerto de origen, pero puertos de destino son solo dos, de los cuales 188 son el puerto 161, el que presenta el 99,88% de carga, y el otro es el puerto 123.
De estos tres análisis se puede concluir que la IP 10.80.210.11 la cual es la que impone mayor presencia en el tráfico de Bytes, tiene comunicación con el Servidor Corporativo y con el Servidor ICCP en ambos puertos. Si se consideran las IPs como pertenecientes a LAN, la mayor comunicación se produce hacia LAN ICCP, con un 67,38% sobre la LAN Corporativa que solo queda en un 32,6%.
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
7.3. Switch D (ICCP) Para realizar la adquisición de datos se configuro el puerto 24 del Switch Catalyst 2960G con port mirroring, tal como en el apartado donde se toca el tema de configuración.
Con el archivo con los datos del tráfico extraído se comienza con el análisis de este dispositivo y su comportamiento dentro de la arquitectura. Antes que todo, se realizará el análisis de cuanto tráfico del capturado corresponde a comunicaciones internas de la LAN respectiva o entre LAN que switch comunica, para posteriormente abarcar el tráfico hacia INTERSITE.
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Dentro del SwD se observa un total de 5.796.681.785 de Bytes traficados, de los cuales se reconoce por las IP origen y destino que el 98,51% de los datos son comunicaciones entre LAN locales (Cerro Navia), un 1,49% de tráfico hacia INTERSITE y un 14,01% de tráfico que no se reconoce fuente o destino dentro de la arquitectura, dado que su porcentaje no despreciable, es que se recomienda realizar un levantamiento para identificarlas, una vez determinado esto, analizar por qué del tráfico. De este análisis cabe destacar que el mayor flujo de información, Origen/Destino y viceversa, se presenta hacia LAN A, siendo está un 84,5% con 4.898.206.210 bytes de tráfico. Conclusiones Tráfico INTERSITE A continuación se realiza una gráfica de tendencia para saber que IP de origen son las que aporta de mayor manera al tráfico en INTERSITE desde el Switch D:
Del tráfico que se presenta en el Switch con destino INTERSITE, podemos distinguir dos IP de origen que trafican el 99,68% de bytes del total del Switch, en los que se tiene tres tipos de conversación entre dispositivos, donde en su mayoría son tráfico IPv4 y TCP, con un valor muy cercano a 50% y 50% respectivamente.
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
7.3.1.1. IPv4 Profundizando un poco en el tipo de conversación entre los dispositivos, tenemos la siguiente gráfica la que expone que dirección IP como origen presenta mayor tráfico, para poder identificar quienes conversan dentro de la arquitectura.
Donde se puede apreciar que la IP que sobresale es la 10.80.213.20, que representa el 99,37% del contenido en comunicación IPv4.
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
A continuación, se muestra la tabla dinámica generada del tráfico IPv4 de SwD:
De aquí se puede concluir que la mayor comunicación se efectúa desde el Servidor ICCP CCP hasta el Servidor ICCP CCR que es casi el 100% del total de bytes traficados por 10.80.213.20. También se ordenó por IP de destino para analizar cuál es la que más tráfico recibe.
Con esto se puede concluir que la IP 10.80.218.19 es la IP de destino más recurrente, con más del 99,99% de lo traficado por IPv4. Por lo que se confirma que la comunicación principal que aporta en el INTERSITE el SwD es entre Servidores ICCPs, tanto de Cerro Navia y Alto Jahuel.
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
7.3.1.2. TCP De las conversaciones por TCP, se tiene solo una IP de origen que corresponder al Servidor ICCP CCP, que representa el 99,36% de este tipo de comunicación, como se muestra a continuación:
Para profundizar en TCP, se realiza la expansión para ver los puertos de origen involucrados:
Como se puede apreciar los puertos de origen más importantes para la comunicación entre 10.80.218.19 y 10.80.213.20, es el 34597 con el 99,25% del tráfico. Ahora se procederá a ver que puertos de destino son lo que llevan mayor carga:
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
El principal puerto de destino es el 8012 con un 98,74% del total traficado por TCP y el 99,37% de lo traficado por 10.80.213.20. También que IPv4, TCP presenta comunicación solo entre Servidores ICCP. 7.3.1.3. UDP Del tráfico UDP se tiene que dos terceras partes corresponden a IP 10.80.213.19, ahora si lo analizamos como dispositivo, tenemos que en su totalidad corresponde al Servidor ICCP.
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Para profundizar en UDP, se realiza el filtro que corresponde en la tabla dinámica, con el fin de ahondar en el análisis de los puertos en cuestión:
De esto se puede concluir que el puerto, tanto de origen como de destino, 123 tiene como 100% la comunicación en UDP. También es preciso mencionar que esta comunicación radica en la interacción entre Servidor ICCP CCP y el GPS Clock CCR. Conclusiones Tráfico LOCAL 7.3.2.1. IPv4 Como se mencionó con anterioridad el mayor tráfico presente es con sentido LAN A, es por esto que merece, a pesar de no ser tráfico INTERSITE, análisis e identificar quienes comunican. Por este motivo realizamos los filtros correspondientes y se obtiene las IP de LAN D de importancia en la comunicación NO INTERSITE.
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Podemos observar que la IP 10.80.213.20 es quien presenta mayor flujo de informaciรณn con un 96,54% del total de Bytes transmitidos a la LAN A. Esta IP se comunica principalmente con la 10.80.210.11 siendo el 99,999% del trรกfico total de la IP origen y el 96,54% del trรกfico IPv4.
SISTEMA SCADA MONARCH - COMUNICACIร N INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Sin tanto análisis a simple vista se puede ver como el Servidor ICCP, por ambos puertos IP, se comunica con Servidor SCADA, representando el 99,68% de estas comunicaciones. 7.3.2.2. TCP En la comunicación TCP, se tiene las siguiente IPs de origen:
La IP 10.80.210.11, siendo el 70,57% del tráfico tiene una comunicación con la 10.80.213.20 con un 97,23% del tráfico de origen. Luego la IP 10.80.213.20 se comunica con la 10.80.210.11 representando el 27,95% del flujo total en TCP. A continuación, se realizará el análisis de los puertos de origen y destino, para la comunicación entre las IP 10.80.210.11 y 10.80.213.20:
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
El puerto de origen que mayor trรกfico presenta es el puerto 57913 el cual se comunica con el puerto de destino 3522, representando el 97,43%. Luego, el segundo puerto que trafica mayor cantidad de informaciรณn es:
SISTEMA SCADA MONARCH - COMUNICACIร N INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Se puede extraer de la tabla y gráfico anterior, que el puerto 51817 es el que presenta el 92,91% del tráfico correspondiente a la comunicación entre 213.20 hacia 210.11. Para poder ver que puerto de destino es el que posee mayor tráfico, se aplicará el filtro correspondiente a la tabla dinámica:
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
El puerto 3522 como destino, reúne el 66,85% del tráfico, seguido por el puerto 3530 con un 27,95%. En ambos caso la comunicación es entre el Servidor SCADA y Servidor ICCP, ambos ubicados en Cerro Navia. 7.3.2.3. UDP Para la comunicación UDP que no se trafica a nivel de INTERSITE, se realiza el filtraje necesario para poder visualizar que IPs están involucradas en dichos tráficos.
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
De la tabla anterior se puede obtener que la IP que trafica mayor información a nivel UDP es la 10.80.210.11, la que significa el 94,21% de los datos traficados en total. Esta IP se comunica con la IP 10.80.213.19 y 10.80.213.20, entre otras, teniendo un tráfico de 49,95% y 49,46% del total, respectivamente. Para saber que puertos son los que se comunican debemos profundizar, para ello abordaremos primero la comunicación entre 210.11 con 213.19:
El puerto que aparece traficar más representa el 30,35%, que es el 50718, luego lo siguen 20 puertos distintos con un aporte de 1,62%, de un total de 185 puertos en esta comunicación. Para esta comunicación el puerto de destino son dos, el primero y el que se lleva casi el 100% del tráfico, es el puerto 161, como se muestra a continuación. SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Prosiguiendo con el análisis, ahora abordaremos la comunicación 210.11 con 213.20:
El puerto que aparece traficar más representa el 30,81%, que es el 13578, luego lo siguen 19 puertos distintos con un aporte de 1,64%, de un total de 186 puertos en esta comunicación. Para esta comunicación el puerto de destino son dos, el primero y el que se lleva casi el 100% del tráfico, es el puerto 161, como se muestra a continuación.
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
7.4. Switch E (Corporativo) Para realizar la adquisición de datos se configuro el puerto 48 del Switch Catalyst 2960G con port mirroring, tal como en el apartado donde se toca el tema de configuración.
El archivo extraído desde Wireshark, denominado Swe, se obtiene una gráfica en el tiempo de los paquetes como se muestra a continuación:
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
También se muestra su respectiva tabla de jerarquía y su tabla de conversaciones donde apreciamos que tipo preponderan en su mayoría:
Dado que los archivos obtenidos son de gran tamaño, es que se traspasa la base de datos a Excel para un mejor y para una ágil manipulación de estos. Con el archivo con los datos del tráfico extraído se comienza con el análisis de este dispositivo y su comportamiento dentro de la arquitectura. Antes que todo, se realizará el SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
análisis de cuanto tráfico del capturado corresponde a comunicaciones internas de la LAN respectiva o entre LAN que switch comunica, para posteriormente abarcar el tráfico hacia INTERSITE.
Dentro del SwE se observa un total de 534.751.511 de Bytes traficados, de los cuales se reconoce por las IP origen y destino que sobre el 99,999% de los datos son comunicaciones entre LAN locales (Cerro Navia), muy cercano al 0% de tráfico hacia INTERSITE y un 46,17% de tráfico que no se reconoce fuente o destino dentro de la arquitectura, dado que su porcentaje no despreciable, es que se recomienda realizar un levantamiento para identificarlas, una vez determinado esto, analizar por qué del tráfico. De este análisis cabe destacar que el mayor flujo de información, Origen/Destino y viceversa, se presenta hacia LAN A, siendo está un 53,83% con 287.834.365 bytes de tráfico. Conclusiones Tráfico INTERSITE A continuación se realiza una gráfica de tendencia para saber que IP de origen son las que aporta de mayor manera al tráfico en INTERSITE desde el Switch E:
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Dada la información obtenida, tenemos que el tráfico en este Switch corresponde, en igual magnitud, a IPv4 y UDP, ambos con 90 Bytes en total de tráfico. 7.4.1.1. IPv4 Profundizando un poco en el tipo de conversación entre los dispositivos, tenemos la siguiente gráfica la que expone que dirección IP como origen presenta mayor tráfico, para poder identificar quienes conversan dentro de la arquitectura.
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
De aquí podemos obtener que la IP 10.80.214.21 se comunica con la IP 10.80.216.228, con un tráfico total de 90 Bytes. Identificando los dispositivos tenemos que la comunicación es entre el Servidor Corporativo CCP y el GPS Clock CCR. 7.4.1.2. UDP Como ya sabemos el tráfico UDP, corresponde de igual forma que el caso anterior al 50% del total hacia INTERSITE, por lo que sabemos de antemano que son 90 Bytes de tráfico, ahora conoceremos que IP están involucradas en la comunicación:
Ya que las IP siguen siendo las mismas, ahora analizaremos que puertos de origen y destino comunica:
Como se muestra en la tabla, el puerto que comunica en ambos sentido es el puerto 123.
Conclusiones Tráfico LOCAL 7.4.2.1. IPv4 Como se mencionó con anterioridad el 53,83% del tráfico del Switch se dirige hacia LAN SCADA-FEP-PDS, ahora precisaremos que IP se comunican y cuál es su tráfico.
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
En base a la tabla anterior se puede ver que el 99,52% del tráfico es a través de 10.80.210.11, las IP que interactúan con ésta, nos encontramos con 10.80.214.21 y 10.80.214.253, con el 99,98% y el 0,02% del tráfico, respectivamente. Por lo que se puede concluir que la comunicación es netamente entre el Servidor SCADA y el Servidor Corporativo.
7.4.2.2. TCP Si bien no se presentaba comunicación TCP hacia INTERSITE, si se presenta a nivel interno de CCP, teniendo las siguiente IP que interactúan:
La IP 10.80.210.11 presenta un 86,42% del flujo total en TCP y esta se comunica con la 10.80.214.21, luego se nos presenta la misma comunicación pero en dirección contraria con un 13,11% del flujo. Para precisar más expondremos los puertos que están presentes.
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Como se muestra en las grรกficas anteriores el puerto de origen con mayor trรกfico es el 14828, con un 86,77% y que a su vez corresponde al 74,99% del trรกfico total TCP. Ahora si vemos que puerto de destino presentan y lo ordenamos por estos, tenemos:
SISTEMA SCADA MONARCH - COMUNICACIร N INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
El puerto 8003 es el puerto de destino con más tráfico, siendo el 98,32% del traficado por la 10.80.210.11 y el 84,97% del total TCP. A continuación con el fin de corroborar la información antes expuesta, se buscó dentro del archivo del Swe el peak mayor en el tiempo, encontrando uno de los paquetes de datos entre las IP 10.80.210.11 y 10.80.214.21, con comunicación TCP. También se aprecia en la imagen que los puertos de origen y destino son, 14828 y 8003 respectivamente.
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Al alejarse en la gráfica también podemos obtener que esto tiene una frecuencia de 5 minutos como se muestra en las siguientes imágenes:
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
7.4.2.3. UDP Filtrando la información de las tablas dinámicas, se obtiene que puertos IP de origen y destino, son los que más aportan al tráfico de bytes.
La IP 10.80.210.11 representa el 96,15% del tráfico total UDP, y esta se comunica en su mayoría con la 10.80.214.21 que significa el 99,49% del tráfico de la IP origen y el 95,67% del tráfico total UDP, por lo que analizaremos que puertos involucra dicha comunicación:
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
El puerto de origen principal es el 47735, representando tan solo el 28,39% del tráfico, seguido por 21 puertos distintos que representan cada uno el 1,73%, de un total de 197 puertos distintos. Ahora se filtrará con prioridad, por los puertos de destino.
Con esto tenemos que el puerto destino con más tráfico es el puerto 161, con el 99,94% del tráfico en dicha comunicación.
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Conclusiones Tráfico INTERSITE Si bien se analizó el flujo perteneciente a cada Switch y su direccionalidad de tráfico, abarcando el tipo de conversación, obteniendo que IP, que puerto TCP y UDP comunican, y su relativa importancia. Pero con el fin de darle una vuelta a modo general y poder dar una mirada más focalizada a INTERSITE, se expondrá una especie de resumen de los Switch en cuestión. Repasando un poco, se presentó con anterioridad el aporte realizado por cada Switch al tráfico del Firewall, también se recuerda por qué se tuvo que realizar de esta forma la medición ya que, a la salida del Firewall WatchGuard se tenía encriptado el tráfico, obteniendo la siguiente gráfica:
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Tomando como un todo el tráfico que efectivamente se realiza por medio de INTERSITE, se tiene que el Switch correspondiente a la LAN SCADA/FEP/PDS presenta un 94,79% del flujo total, seguido por la LAN de ICCP con un 5,21%. Como se profundizo en los apartados dedicados a cada Switch se tiene como resumen la siguiente tabla, donde se muestra el tráfico INTERSITE, con sus respectivas direcciones IP de origen de cada archivo de la adquisición de datos:
8.1. DAC Tal como se desentreñó el tipo de comunicación, que puertos estaban involucrados tanto en TCP y UDP, es que ahora expondremos a que dispositivos pertenecen las comunicaciones que presentan mayor tráfico en INTERSITE. IPv4 Dando un vistazo general en los apartados anteriores, podemos concluir que los puertos IP del DAC, en su mayoría, CCP como CCR, son los que mas tráfican, es que se precisa la siguiente gráfica, donde se muestra el tráfico total desde DAC, con sus respectivas direcciones IP destino, se realiza el cambio de color para no confundir con la información extraida desde los Switch:
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
De los gráficos anteriores se pueden extraer que el tráfico generado por la IP 10.80.210.11 corresponde al 40,23%, mientras que la IP 10.80.210.12 al 17,3% y finalmente la IP 10.80.216.11 al 42,47% del tráfico total del DAC. Si bién este último es el que más tráfica, es el que tiene menos interacción con el resto de dispositivos, tan solo con DAC CCP a través de sus dos IP. Por el contrario la IP 10.80.210.11 presenta comunicación con varios dispositivos y con las RTU del CCR, pero el 95,587% de su comunicación es netamente con DAC CCR. Ahora bien la IP 10.80.210.12 tiene comunicación con cuatro dispositivos como el Servidor de Seguridad CCR, GPS Clock CCR, una RTU CCR y con un 99,1% al DAC CCR. Las cargas se podrian estimar que se presentan de forma balanceada entre DAC, como se muestra en la siguiente tabla, que muestra el tráfico total por IP origen de DAC:
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
TCP Los puertos IP involucrados en la conversación TCP entre los DAC, se presentan en la siguiente tabla:
Siendo la IP de origen 10.80.216.11 la que mayor tráfico presenta, con un 98,22% del total, del cual un 75,97% corresponde a comunicación con la IP 10.80.210.11. A continuación, se analizará que puerto estan involucrados en dica conversación:
El puerto 34375 se lleva el 89,41% del tráfico, hacia el puerto 8012. Para tener un vista general de que puerto TCP son los principales en las comunicaciones de los servidores DAC, es que se presenta la lista de puertos Origen (izquierda) con mas tráfico y también los puerto Destino (derecha).
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
UDP Las IP de origen involucradas en las conversaciones UDP son:
La primera IP representa el 99,98% de la comunicaciรณn total, por lo que volcamos los anรกlisis en esta IP origen. Ahora veremos con que dispositivos se comunica.
SISTEMA SCADA MONARCH - COMUNICACIร N INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
La comunicación entablada con el Servidor de Seguridad es la que posee mayor tráfico de Bytes con un 23,65%, luego las Consolas de Operación las que en orden decreciente en tráfico presentan un 16,44%, 14,97% y un 14,75%, seguidos muy de cerca por el Servidor SCADA, con un 10,06%, ya con estas se suma mas del 79% del total. Precisaremos los puertos UDP de la comunicación con el Servidor de Seguridad CCR, con el que presenta 192 puertos diferentes de origen, de los cuales los que transfieren mas Bytes son los siguientes:
El primer puerto en cuestion posee solo un 11,42% del total, luego lo siguen 69 puertos con un 0,92%. SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Para tener un vista general de que puerto UDP son los principales en las comunicaciones de los servidores DAC, es que se presenta la lista de puertos Origen (izquierda) con mas tráfico y también los puerto Destino (derecha).
8.2. HIS Tal como se desentreñó el tipo de comunicación, que puertos estaban involucrados tanto en TCP y UDP, es que ahora expondremos a que dispositivos pertenecen las comunicaciones que presentan mayor tráfico en INTERSITE. IPv4 Dando un vistazo general en los apartados anteriores, podemos concluir que los puertos IP del HIS, en su mayoría, CCP como CCR, son los que mas tráfican, es que se precisa la siguiente gráfica, donde se muestra el tráfico total desde HIS, con sus respectivas direcciones IP destino, se mantendrá el cambio de color, como en el apartado anterior, para no confundir con la información extraida desde los Switch: SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Del gráfico anterior se puede extraer que el tráfico generado por la IP 10.80.210.13 corresponde al 5,17%, mientras que la IP 10.80.210.14 al 45,79% y finalmente la IP 10.80.216.13 al 49,04% del tráfico total del HIS. Si bién este último es el que más tráfica, es el que tiene menos interacción con el resto de dispositivos, tan solo con HIS CCP a través de sus dos IP. Por el contrario la IP 10.80.210.13 presenta comunicación con HIS, Servidor de Seguridad y GPS Clock todos del CCR, pero el 99,93% de su comunicación es netamente con HIS CCR. Ahora bien la IP 10.80.210.14 tiene comunicación con tres dispositivos como el Servidor de Seguridad CCR, GPS Clock CCR, y con un 99,98% al HIS CCR. Las cargas se podrian estimar que se presentan de forma balanceada entre HIS, como se muestra en la siguiente tabla, que muestra el tráfico total por IP origen de HIS, considerando ambas IP del CCP como un ente:
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
TCP Los puertos IP involucrados en la conversación TCP entre los HIS, se presentan en la siguiente tabla:
Siendo la IP de origen 10.80.216.13 la que mayor tráfico presenta, con un 99,33% del total, del cual un 92,53% corresponde a comunicación con la IP 10.80.210.14. A continuación, se analizará que puerto estan involucrados en dica conversación:
El puerto 44101 se lleva el 97,52% del tráfico, hacia el puerto 3615.
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Para tener un vista general de que puerto TCP son los principales en las comunicaciones de los servidores DAC, es que se presenta la lista de puertos Origen (izquierda) con mas tráfico y también los puerto Destino (derecha).
UDP Las IP de origen, involucradas en las conversaciones UDP son:
La primera IP representa el 60% de la comunicación total, por lo que volcamos los análisis en esta IP origen. Ahora veremos con que dispositivos se comunica.
La comunicación entablada con el GPS Clock es la que posee mayor tráfico de Bytes con un 66,67%, luego las con el Servidor de Seguridad que en tráfico presentan un 33,33% del total. SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Precisaremos los puertos UDP de la comunicación con el Servidor de Seguridad CCR, con el que presenta un puerto de origen que transfieren Bytes:
El primer puerto en cuestión y único posee la totalidad del tráfico, este es el puerto 123.
Cabe mencionar que en comunicaciones UDP, solo se presenta el puerto 123 tanto de origen como de destino.
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
IP Desconocidas Dentro del desarrollo del análisis del tráfico existente por cada switch, se presentaron puertos IP desconocidos, ante la arquitectura entregada, los cuales tienen un flujo no despreciable en su totalidad, como puertos de origen o destino, tanto así que en algunos casos estos puertos piden comunicarse con algunas IP, enviando paquetes de datos pero no teniendo respuesta. Se presentan 44 IP, que se plantea corroborar en conjunto con TECNET a que LAN pertenecen y una vez identificadas, analizar si es correcto que estás envíen o pidan datos. A continuación se enlistan las IPs desconocidas: IP Desconocidas 169.254.234.197 143.127.102.40 169.254.255.255 172.24.4.20 239.222.222.226 172.24.4.21 239.255.255.250 172.24.5.120 255.255.255.255 172.24.5.40 10.1.1.1 172.24.5.41 10.80.10.124 192.112.36.4 10.80.104.84 192.203.230.10 10.80.104.91 192.228.79.201 10.80.105.77 192.33.4.12 10.80.143.156 192.36.148.17 10.80.148.104 192.5.5.241 10.80.36.45 192.58.128.30 10.80.36.46 193.0.14.129 10.90.x.130 198.41.0.4 10.90.x.131 199.7.83.42 10.90.x.133 202.12.27.33 10.90.x.2 224.0.0.2 10.90.x.3 224.0.0.251 10.90.x.4 224.0.0.252 10.90.x.5 224.0.1.60 100.80.210.18 224.0.75.75 128.63.2.53 239.255.10.11 128.8.10.90
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
A medida que se desarrolló el tema, algunas de estas IP fueron identificadas o se prevé a que corresponden como los son todas las IP 10.90.X.X, ya que estas corresponden a RTU, las que tienen terminación .2, .3, .4 y .5, corresponden a RTU de la LAN ICCP de Cerro Navia, mientras que las terminadas en .130, .131 y .133, con RTU de la LAN ICCP de Alto Jahuel. También se logró identificar que algunas consolas de operadores de la LAN SCADA, se intentaban comunicar con la IP 143.127.102.40, con lo que se identificó que estas consolas hacen el llamado a la IP del Servidor del Antivirus que tienen instalado, y como el llamado llega al Firewall este lo rechaza, ya que no conoce dicha IP, lo que viene a corroborar la seguridad de este último, pero a su vez a cuestionar, el por qué no deshabilitar dicha opción del antivirus. Finalmente se estima que la IP 169.254.255.255 es un broadcast multidifusión y que la IP 255.255.255.255 es un limited broadcast.
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Conclusiones Generales del Trabajo Luego de haber efectuado las mediciones pertinentes y tener la base de datos que se esperaba, se pueden concluir varias cosas, de las cuales no muchas son positivas, en miras del cumplimiento del objetivo general. Una de las primeras las primeras cosas a concluir, es que dado que la comunicación INTERSITE era una caja negra, donde se desconocía que se traficaba, es que este trabajo logró dar luces y algunas bases firmes de que contenido es que el mayoritariamente ocupa dicho medio. En pocas palabras se logró abrir este mundo, entenderlo en un nivel micro, en cuanto al tráfico. Si bien, como se mencionaba al principio, no se logró el objetivo general y principal del trabajo, este quizás es el principio de una eventual futura investigación, ya que el entorno donde se mueve involucra no solo a TRANSELEC, sino también a TECNET y OSI, de los cuales con el hecho de aunar voluntades se puede llegar a obtener el ancho de banda deseado para cada aplicación. Una de los hechos que influyó en que no se llegará a buen puerto, fueron los tiempos y la dependencia en la movilidad del ejecutante. También, y en desmedro de obtener unas buenas y pertinentes conclusiones, el acto de realizar las mediciones en los distintos switch. Se hace referencia a esto, porque al realizar mediciones por cada switch, no de forma simultánea es imposible que estas mediciones sean concluyentes, ya que como se mencionó al principio del informe, se tiene por conocimiento no empírico, que el enlace se colapsa cada 15 o 20 min, por lo que el motivo de esto se vería seccionado en partes. A su vez, esta información no se puede proyectar una sobre otra, es decir, si hay datos traspasando de LAN A hacia la LAN C en la medición del SwA, y luego de veinte minutos se ve de LAN C hacia la LAN A, no se puede asumir que es el mismo paquete visto en el tiempo. Para haber logrado la proyección de datos de un switch a otro, se hubiese necesitado más herramientas, para la adquisición de datos, es decir, a lo menos tres computadores que de forma simultanea estuviesen capturando la información de las tres fuentes. Otra adversidad, fue que en la adquisición de datos, los archivos resultantes desde Wireshark sobrepasan el gigabyte de tamaño, por lo que al trabajar los datos, los computadores no eran capaz de abrir los archivos y colapsaban, por lo que se debió apenas se pudo, pasar la información a Excel, y trabajarlo en tablas dinámicas, pero esto coartó la posibilidad de generar gráficas y analizarlos en base al tiempo.
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla
Pero, a pesar de estas dificultades, se pueden exponer que IP, puerto TCP y UDP son de importancia en base a su flujo, en los que sobre salen, en su mayoría los DAC tanto de CCP como de CCR, como también los correspondientes a los HIS. Cabe mencionar que este trabajo, finalmente, vino a abrir una especie de camino, no pavimentado, para que a futuro se retome, quizás contando con más información por parte del software de OSI, en cuanto a puerto que utiliza y con qué fin.
SISTEMA SCADA MONARCH - COMUNICACIÓN INTERSITE CCP-CCR Informe OACT Esteban Hermosilla