Capítulo 11 — Redes y protocolos
Mapa de la lección
Lección 11 publicada. Mapa, ejemplo, EX022.
flowchart TD
N0["Resultados de aprendizaje y conexión"]
N1["11.1 Las capas y lo que prometen"]
N2["11.2 Protocolos industriales"]
N3["11.3 Latencia, fluctuación y sondeo"]
N4["11.4 Zonas, conductos y listas de permitidos"]
N5["11.6 Actividad práctica: Lab 5"]
N6["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX022"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje y conexión"]
N1["11.1 Las capas y lo que prometen"]
N2["11.2 Protocolos industriales"]
N3["11.3 Latencia, fluctuación y sondeo"]
N4["11.4 Zonas, conductos y listas de permitidos"]
N5["11.6 Actividad práctica: Lab 5"]
N6["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX022"]
[Resultados de aprendizaje y conexión]
|
v
[11.1 Las capas y lo que prometen]
|
v
[11.2 Protocolos industriales]
|
v
[11.3 Latencia, fluctuación y sondeo]
|
v
[11.4 Zonas, conductos y listas de permitidos]
|
v
[11.6 Actividad práctica: Lab 5]
|
v
[Síntesis del capítulo]
|
v
[Ejemplo resuelto] --> [Ejercicio EX022]
Resultados de aprendizaje y conexión
Al terminar este capítulo, usted podrá (1) explicar el modelo de capas y las funciones de Ethernet, IP, TCP, UDP y los protocolos de aplicación; (2) describir los protocolos industriales (Modbus/TCP, DNP3, IEC 60870-5-104, OPC UA) y qué propiedades de seguridad ofrece o no ofrece cada uno; (3) construir un presupuesto de latencia para la telemetría; y (4) expresar la segmentación como zonas y conductos y contrastar con ella los flujos observados. Se apoya en los capítulos 3 y 4 y prepara los capítulos 18 (arquitectura de seguridad) y 26 (alternativas de arquitectura).
11.1 Las capas y lo que prometen
Las redes se construyen en capas: física y de enlace (tramas Ethernet en un segmento), de red (paquetes IP encaminados entre segmentos), de transporte (TCP, flujos de bytes fiables y ordenados; UDP, datagramas sin garantía de entrega; TCP se especifica en RFC 9293) y de aplicación (el protocolo que transporta el significado). Cada capa promete algo limitado. TCP garantiza el orden y la retransmisión, no la autenticidad. IP encamina, pero en muchas redes las direcciones de origen pueden falsificarse. Las propiedades de seguridad deben añadirse de forma deliberada, normalmente con TLS (RFC 8446), IPsec o autenticación en la capa de aplicación.
11.2 Protocolos industriales
Los protocolos industriales clásicos se diseñaron para redes serie cerradas. Modbus/TCP (puerto 502) transporta códigos de función, como leer y escribir registros, sin ninguna autenticación; cualquiera que pueda alcanzar el puerto 502 puede emitir escrituras. DNP3 se usa ampliamente en agua y electricidad; su extensión Secure Authentication añade autenticación por desafío y respuesta de las órdenes críticas, pero no está desplegada de forma universal. IEC 60870-5-104 es común en los sistemas eléctricos europeos, con extensiones de seguridad definidas en IEC 62351. OPC UA se diseñó con modos de seguridad que ofrecen firma y cifrado, pero deben configurarse: «None» es una política válida. La lección es constante: la capacidad del protocolo no es su despliegue. Compruebe lo que está configurado.
11.3 Latencia, fluctuación y sondeo
La telemetría suele obtenerse por sondeo: el maestro SCADA pregunta a cada RTU por turno. La latencia de extremo a extremo, desde un evento físico hasta la pantalla de un operador, es la suma de la actualización del sensor, el barrido de la RTU, el viaje de ida y vuelta por el enlace, la espera de sondeo del maestro, el procesamiento y el refresco de la pantalla. La fluctuación (jitter) es la variación de la latencia. Escriba un presupuesto, mida cada elemento y compare el total con el requisito; el capítulo 36 añade las colas.
El presupuesto de LRWA en el Lab 5 suma el barrido de la RTU, el viaje de ida y vuelta por LTE, la espera de sondeo y el refresco de pantalla hasta llegar a un segundo frente a un requisito de 1,5 segundos, pero la espera de sondeo es el elemento que más varía, y el EX022 muestra cómo domina el peor caso.
11.4 Zonas, conductos y listas de permitidos
La segmentación divide una red en zonas con requisitos de seguridad similares y controla los conductos entre ellas. Este vocabulario procede de la serie ISA/IEC 62443. Una política de conducto es una lista de permitidos: zona de origen, zona de destino, protocolo y puerto concretos, y todo lo demás denegado. Verificar no es leer la configuración del cortafuegos; es contrastar los flujos observados con la política prevista, porque las configuraciones derivan y los caminos no documentados (el módem de acceso remoto de un proveedor, un portátil conectado a dos redes) eluden los cortafuegos.
La revisión de flujos de LRWA que sigue muestra por qué.
11.5 Ejemplo resuelto: revisión de flujos de LRWA (sintético)
LRWA define estas zonas: enterprise (corporativa), dmz, control (servidores SCADA), field (campo, las RTU) y eng (estaciones de ingeniería). Los conductos previstos se enumeran en el Lab 5. Una semana de registros de flujos muestra tres infracciones: un equipo corporativo que habla Modbus directamente con una RTU de campo (un script de informes olvidado que elude la DMZ), una estación de ingeniería que abre SSH directamente hacia una RTU en lugar de pasar por el servidor de salto de la zona de control, y un servidor SCADA que hace consultas DNS a un resolutor público. Cada una es un hallazgo con un responsable: eliminar el script y servir sus datos desde el historiador de la DMZ; encaminar el acceso de ingeniería a través del servidor de salto; apuntar el DNS del SCADA a un resolutor interno o a ninguno.
11.6 Actividad práctica: Lab 5
# Lab 5 - check observed flows against a zone-conduit allowlist (synthetic, offline)
RULES = [ # (src_zone, dst_zone, protocol, port)
("control", "field", "tcp", 502), ("control", "dmz", "tcp", 443), ("dmz", "enterprise", "tcp", 443),
("eng", "control", "tcp", 22), ("field", "control", "udp", 20000)]
ZONE = {"10.1.0.": "control", "10.2.0.": "field", "10.3.0.": "dmz", "10.4.0.": "enterprise", "10.5.0.": "eng"}
def zone(ip): return next((z for p, z in ZONE.items() if ip.startswith(p)), "unknown")
FLOWS = [("10.1.0.5", "10.2.0.31", "tcp", 502), ("10.4.0.77", "10.2.0.31", "tcp", 502),
("10.2.0.31", "10.1.0.5", "udp", 20000), ("10.3.0.9", "10.4.0.20", "tcp", 443),
("10.5.0.12", "10.2.0.33", "tcp", 22), ("10.1.0.5", "8.8.8.8", "udp", 53),
("10.1.0.6", "10.3.0.9", "tcp", 443)]
for s, d, p, port in FLOWS:
ok = (zone(s), zone(d), p, port) in RULES
print(f"{s:>10} {zone(s):>10} -> {d:<10} {zone(d):<10} {p}/{port:<5} {'allowed' if ok else 'VIOLATION'}")
budget = {"rtu_scan": 120, "lte_rtt": 180, "scada_poll_wait": 500, "operator_view": 200}
print("end-to-end latency budget ms:", sum(budget.values()), "vs requirement 1500")
Salida esperada:
10.1.0.5 control -> 10.2.0.31 field tcp/502 allowed
10.4.0.77 enterprise -> 10.2.0.31 field tcp/502 VIOLATION
10.2.0.31 field -> 10.1.0.5 control udp/20000 allowed
10.3.0.9 dmz -> 10.4.0.20 enterprise tcp/443 allowed
10.5.0.12 eng -> 10.2.0.33 field tcp/22 VIOLATION
10.1.0.5 control -> 8.8.8.8 unknown udp/53 VIOLATION
10.1.0.6 control -> 10.3.0.9 dmz tcp/443 allowed
end-to-end latency budget ms: 1000 vs requirement 1500
Tres de los siete flujos son infracciones, y cada una coincide con un hallazgo del ejemplo resuelto: el script corporativo de informes que habla Modbus con una RTU de campo, la estación de ingeniería que abre SSH directamente hacia una RTU en lugar de hacerlo a través del servidor de salto, y un servidor SCADA que consulta un resolutor DNS público. La línea del presupuesto de latencia muestra un total de un segundo frente al requisito de 1,5 segundos, pero esa cifra usa valores típicos, así que trátela como punto de partida para el análisis del peor caso del EX022 y no como evidencia de que R7 se cumple.
11.7 Errores comunes y límites
- Equiparar el cifrado en una capa con la protección de extremo a extremo.
- Suponer que la seguridad opcional de un protocolo industrial está habilitada.
- Verificar la segmentación solo leyendo configuraciones.
- Presupuestos de latencia con promedios en lugar de peores casos.
- Listas de permitidos por equipo en lugar de por función, que se vuelven imposibles de mantener.
La revisión de flujos de LRWA ilustra directamente el tercer error: la configuración del cortafuegos parecía correcta y, sin embargo, una semana de registros de flujos mostró tres infracciones. Leer las configuraciones no habría encontrado ninguna. Las listas de permitidos escritas por equipo también habrían necesitado modificaciones constantes a medida que se añadían RTU.
Ejercicios — capítulo 11
EX021 — Amplíe la comprobación de la política. Objetivo: encontrar infracciones por función. Entradas: Lab 5. Pasos: (1) añada un flujo de 10.2.0.31 a 10.4.0.77 por TCP/445; (2) añada una regla para que la estación de ingeniería pueda llegar a las RTU solo a través de un servidor de salto en la zona de control, y modele los dos saltos; (3) vuelva a ejecutar e informe. Evidencia esperada: cambios en el código y salida. Rúbrica: 3 = se detecta la nueva infracción, el modelo de dos saltos es correcto, ninguna regla debilita la protección del campo; 2 = un problema; 1 = no ejecutado; 0 = nada.
EX022 — Latencia frente al requisito. Objetivo: presupuestar la latencia del peor caso. Entradas: barrido de la RTU de 120 ms, viaje de ida y vuelta LTE de 180 ms típico / 900 ms en el percentil 99, espera de sondeo de hasta un ciclo completo de 1,3 s (Lab 13), refresco de la vista del operador de 200 ms; requisito: el 95 % de las alarmas en pantalla en menos de 1,5 s y todas en menos de 5 s. Pasos: calcule los totales típico y de peor caso; juzgue ambas cláusulas; proponga un cambio de diseño. Evidencia esperada: tabla. Rúbrica: 3 = sumas correctas, se reconoce que la espera de sondeo domina, se propone un cambio (informe por excepción o alarmas no solicitadas); 2 = una suma errónea; 1 = solo el caso típico; 0 = nada.
Síntesis del capítulo
Cada capa de red promete algo acotado; la autenticidad hay que añadirla. Los protocolos industriales varían en capacidad de seguridad, y la capacidad no es la configuración. Presupueste la latencia con peores casos. Exprese la segmentación como zonas y conductos con listas de permitidos, y verifíquela con los flujos observados y no con las configuraciones previstas.
Siga estudiando — capítulo 11 de 50
← Capítulo 10 · Índice de capítulos del curso · Capítulo 12 →
Continúe con la siguiente lección escrita.