Capítulo 7 — Redes y protocolos | Grado Seguridad de infraestructuras críticas y sectores

Aprendizaje gratuito y abierto para quienes desean proteger a las personas y la tecnología. No se necesita una cuenta para estudiar ni consultar las respuestas.

Mapa de la lección

Lección 07 publicada. Mapa, ejemplo, EX013.

flowchart TD
  N0["Resultados de aprendizaje y conexión"]
  N1["7.1 Capas, direcciones y puertos"]
  N2["7.2 Los protocolos industriales y sus supuestos"]
  N3["7.3 Zonas, conductos y listas de permitidos"]
  N4["7.5 Actividad práctica"]
  N5["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Ejemplo resuelto"]
  EX --> Q["Ejercicio EX013"]

Dibujo lógico

flowchart LR
  N0["Resultados de aprendizaje y conexión"]
  N1["7.1 Capas, direcciones y puertos"]
  N2["7.2 Los protocolos industriales y sus supuestos"]
  N3["7.3 Zonas, conductos y listas de permitidos"]
  N4["7.5 Actividad práctica"]
  N5["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX013"]

[Resultados de aprendizaje y conexión]
    |
    v
[7.1 Capas, direcciones y puertos]
    |
    v
[7.2 Los protocolos industriales y sus supuestos]
    |
    v
[7.3 Zonas, conductos y listas de permitidos]
    |
    v
[7.5 Actividad práctica]
    |
    v
[Síntesis del capítulo]
    |
    v
[Ejemplo resuelto] --> [Ejercicio EX013]

Resultados de aprendizaje y conexión

Después de este capítulo usted podrá (1) explicar las capas, el direccionamiento, los puertos y la diferencia entre el cliente y el servidor de una conexión; (2) describir en qué se diferencian los supuestos de seguridad de protocolos industriales como Modbus de los de los protocolos modernos de internet; (3) expresar una política de segmentación de red como zonas, conductos y una lista de permitidos; y (4) contrastar los flujos observados con esa política e interpretar las infracciones. Se apoya en los capítulos 3 y 6 y prepara el capítulo 16 (arquitectura) y el capítulo 24 (controles).

7.1 Capas, direcciones y puertos

Las redes se construyen por capas. La capa de enlace mueve tramas entre dispositivos vecinos (Ethernet, Wi-Fi). La capa de internet mueve paquetes entre redes mediante direcciones IP. La capa de transporte proporciona un flujo de bytes fiable (TCP; véase RFC 9293) o datagramas individuales (UDP), y usa números de puerto para identificar el servicio en un equipo. La capa de aplicación transporta el significado: HTTPS para la web, Modbus/TCP en el puerto 502 para el sondeo industrial, OPC UA habitualmente en el puerto 4840. En una conexión TCP, el cliente abre la conexión hacia el puerto de escucha del servidor; la respuesta usa la misma conexión. Quién inicia es relevante para la seguridad: un controlador de campo que de repente abre conexiones hacia la sala de control se comporta de forma distinta a uno que solo responde.

7.2 Los protocolos industriales y sus supuestos

Muchos protocolos industriales se diseñaron para enlaces serie cerrados entre los años setenta y noventa. Modbus, por ejemplo, define códigos de función para leer y escribir registros y bobinas, y su forma clásica no tiene autenticación: cualquier dispositivo que pueda enviar a un controlador una petición bien formada puede pedirle que escriba (especificación de Modbus). No es un error de una implementación; es el supuesto de diseño de que solo los dispositivos de confianza pueden llegar al cable. Cuando estos protocolos funcionan sobre redes IP, ese supuesto debe imponerlo la red: segmentación, listas de permitidos y supervisión. Los protocolos modernos añaden seguridad (TLS 1.3 proporciona canales autenticados y cifrados; RFC 8446), pero actualizar miles de dispositivos de campo lleva décadas.

7.3 Zonas, conductos y listas de permitidos

Una zona es un grupo de activos con requisitos de seguridad similares; un conducto es la vía de comunicación controlada entre zonas. La serie ISA/IEC 62443 usa estos términos para los sistemas industriales (presentación de ISA/IEC 62443). Una empresa de servicios típica tiene una zona corporativa, una zona desmilitarizada (DMZ) en la que se intercambian datos, una zona de control (servidores SCADA, HMI de los operadores) y una zona de campo (controladores, RTU). Una política de lista de permitidos nombra los flujos permitidos (zona de origen, zona de destino, puerto, propósito) y deniega todo lo demás. La política es solo la mitad del control; la otra mitad es comprobar que el tráfico observado se ajusta a ella.

7.4 Ejemplo resuelto y Lab 4: comprobación de los flujos de CW (sintético)

Este caso es sintético. Calder Water permite tres conductos: los usuarios corporativos consultan el historiador de la DMZ por HTTPS; un recolector de la DMZ lee de la zona de control por OPC UA; el servidor SCADA sondea los controladores de campo por Modbus/TCP. Se contrasta con la política un resumen de los flujos de una hora.

# Lab 4 - check observed flows against a zone-and-conduit allowlist (synthetic, offline)
ALLOW = {  # (source zone, destination zone, destination port): purpose
    ("corporate", "dmz", 443): "historian web view",
    ("dmz", "control", 4840): "OPC UA read from historian replica collector",
    ("control", "field", 502): "Modbus/TCP polling of field controllers",
}
ZONE = {"10.1.": "corporate", "10.5.": "dmz", "10.20.": "control", "10.30.": "field"}
def zone(ip):
    return next((z for p, z in ZONE.items() if ip.startswith(p)), "unknown")
FLOWS = [  # src, dst, dport  (synthetic NetFlow-style summary)
    ("10.1.4.22", "10.5.0.10", 443), ("10.5.0.11", "10.20.0.5", 4840),
    ("10.20.0.5", "10.30.1.7", 502), ("10.1.4.80", "10.20.0.5", 3389),
    ("10.20.0.9", "198.51.100.23", 443), ("10.30.1.7", "10.20.0.5", 502),
]
for s, d, p in FLOWS:
    key = (zone(s), zone(d), p)
    verdict = ALLOW.get(key)
    print(f"{s:>13} -> {d:<14} :{p:<5} {key[0]:>9}->{key[1]:<8} {'ALLOW ' + verdict if verdict else 'VIOLATION'}")

Salida esperada:

    10.1.4.22 -> 10.5.0.10      :443   corporate->dmz      ALLOW historian web view
    10.5.0.11 -> 10.20.0.5      :4840        dmz->control  ALLOW OPC UA read from historian replica collector
    10.20.0.5 -> 10.30.1.7      :502     control->field    ALLOW Modbus/TCP polling of field controllers
    10.1.4.80 -> 10.20.0.5      :3389  corporate->control  VIOLATION
    10.20.0.9 -> 198.51.100.23  :443     control->unknown  VIOLATION
    10.30.1.7 -> 10.20.0.5      :502       field->control  VIOLATION

Tres infracciones, tres significados distintos. Una conexión de escritorio remoto (puerto 3389) desde la zona corporativa directamente a la zona de control evita la DMZ: quizá un atajo de un ingeniero, quizá un intruso. Un equipo de la zona de control que llega a una dirección de internet (198.51.100.23 es una dirección de documentación que sustituye a una real) puede ser la comprobación de actualizaciones de un fabricante o datos que salen. Un dispositivo de campo que inicia Modbus hacia el servidor SCADA invierte la dirección normal. Ninguna prueba un ataque; cada una necesita un responsable que la explique, y la explicación se convierte en evidencia (capítulo 15).

7.5 Actividad práctica

En un computador de su propiedad, enumere sus propias conexiones activas (por ejemplo, con netstat o ss) y clasifique cinco como cliente o servidor, local o remota, y esperada o inesperada. No escanee ningún otro sistema. Use la columna de estado de ss o de netstat: una dirección local con un puerto en escucha es un servidor; una conexión a un puerto remoto 443 es un cliente. Marque todo lo que no pueda explicar y encuentre el programa que hay detrás con las herramientas de su sistema operativo, en su propia máquina.

7.6 Errores comunes y límites

Escribir listas de permitidos solo por puerto, ignorando las zonas de origen y destino.
Suponer que «interno» significa «de confianza».
Confundir el tráfico de respuesta con las conexiones iniciadas al leer los registros de flujos.
Tratar una infracción como prueba de compromiso en lugar de como una pregunta.

El Lab 4 muestra por qué: una regla solo por puerto que permitiera el 502 habría dejado pasar al dispositivo de campo que inició Modbus hacia el servidor SCADA, una inversión de la dirección normal. La conexión RDP corporativa hacia el control es «interna» y aun así es una infracción. En los registros de flujos, las respuestas de los controladores de campo desde el puerto 502 hacia el servidor SCADA no son conexiones nuevas y no deben leerse como tales. Y cada una de las tres infracciones llega primero a un responsable como pregunta.

Ejercicios — capítulo 7

EX013 — Explicar las infracciones. Objetivo: razonar desde los flujos hasta las hipótesis. Entradas: la salida del Lab 4. Pasos: para cada infracción, dé una explicación benigna y una maliciosa, y la evidencia que permitiría distinguirlas. Evidencia esperada: una tabla de tres filas. Rúbrica: 3 = pares plausibles y evidencia distintiva concreta (solicitudes de cambio, inicios de sesión de usuarios, titularidad del destino, configuración del dispositivo); 2 = evidencia genérica; 1 = solo explicaciones; 0 = nada.

EX014 — Flujo mínimo. Objetivo: endurecer una política. Entradas: la tabla ALLOW. Pasos: proponga dos refinamientos que estrechen la política sin romper sus propósitos (por ejemplo, reglas por equipo en lugar de por zona, códigos de función de solo lectura) y diga cómo se impondría y se comprobaría cada uno. Evidencia esperada: dos refinamientos con su imposición y su comprobación. Rúbrica: 3 = ambos más estrechos, imponibles y comprobables; 2 = uno; 1 = vagos; 0 = nada.

Síntesis del capítulo

Las redes llevan consigo los supuestos de sus protocolos. Los protocolos industriales clásicos confían en cualquiera que pueda alcanzarlos, por lo que los servicios críticos imponen la confianza con zonas, conductos y listas de permitidos, y después contrastan los flujos observados con la política. Una infracción es una pregunta para un responsable, no un veredicto.