Desconecten Internet
(computer.rip)- Tras grandes incidentes de seguridad como el de CrowdStrike, suele aparecer la reacción de que “nunca debieron haberlo conectado a Internet”, pero muchos sistemas de trabajo tienen como función central el intercambio de información, así que no se resuelve simplemente cortando la conexión
- Los sistemas que cruzan límites organizacionales y geográficos, como los de reservas y programación aérea, se parecen más a una infraestructura de comunicaciones que reemplazó al teléfono y al telégrafo; si se elimina la red, también desaparece su valor original
- “No estar conectado a Internet” puede abarcar desde un equipo aislado, un air gap estricto, data diodes, WAN privadas, túneles VPN, enrutamiento restringido, hasta una AWS private VPC, por lo que el modelo de amenazas cambia muchísimo
- En entornos offline o con conectividad restringida, desde las actualizaciones del SO, los gestores de paquetes, los repositorios internos, los almacenes de confianza TLS, las licencias en la nube, las actualizaciones de contenido y hasta el manejo de imágenes Docker hacen subir el tiempo y el costo
- Sí se puede aplicar políticas de red restrictivas a más sistemas y desarrollar software pensando en operación offline, pero el ecosistema de software actual sigue tomando la conexión a Internet como valor predeterminado
Los límites de decir “no lo conecten a Internet”
- Cada vez que un gran incidente de seguridad llega a las noticias, se repite la reacción de que “este tipo de sistemas no debería estar conectado a Internet”
- Esa idea tiene un atractivo intuitivo desde la perspectiva de la seguridad y la estabilidad, pero en la práctica no hay tantos entornos operando así
- El problema central es que decir “no está conectado a Internet” no alcanza para especificar bien el diseño real, el costo operativo ni el modelo de amenazas
Los sistemas de trabajo modernos se parecen más a dispositivos de comunicación
- En abstracto, una computadora puede generar valor mediante el cómputo, pero los sistemas industriales reales tienen un carácter más fuerte de tecnología de la información que de cálculo
- La tecnología de la información necesita recibir y emitir información, y volver al modelo antiguo donde un operador inserta cintas es más caro y más lento que la comunicación en tiempo real
- La mayoría de las computadoras modernas de uso empresarial funcionan, en esencia, como dispositivos de comunicación
- No son muchos los sistemas que generan valor sin conectarse con otros sistemas de trabajo
- A menudo esas conexiones cruzan fronteras organizacionales y geográficas
- Los sistemas de reservas y programación aérea surgieron como reemplazo de sistemas basados en teléfono y telégrafo, y la red forma parte de la función misma
El mantenimiento y la operación también necesitan red
- Incluso cuando la comunicación en tiempo real no es esencial para el objetivo del negocio, la conectividad de red tiene un gran valor operativo
- Sin conexión a Internet, de entrada surge el problema de cómo traer actualizaciones de software o cómo monitorear el sistema
- Aunque se decida que el sistema ya está “terminado” y no necesita actualizaciones ni monitoreo en tiempo real, los requisitos del negocio cambian con el tiempo
- La conectividad de red reduce de forma importante el costo de gestionar esos cambios
“No conectado a Internet” tiene varios niveles
- El estado de “no está conectado a Internet” no tiene un único significado, sino que agrupa muchas formas de implementación
- Las variantes posibles se distribuyen desde el aislamiento total hasta una conectividad muy restringida
- Un equipo aislado sin ninguna conexión de red
- Un air gap estricto sin conexiones más allá de una LAN privada, donde los datos no cruzan el perímetro de seguridad
- Un air gap donde los datos entran al perímetro de seguridad mediante DVD-R
- Una arquitectura que mueve datos desde una red de baja seguridad a una de alta seguridad con una cross-domain solution o data diode
- Una arquitectura que usa una cross-domain solution sin certificación de la NSA
- Las redes privadas de área amplia también tienen varios grados
- Una WAN privada con infraestructura física completamente independiente y medidas contra manipulación
- Un esquema que usa ductos compartidos, leased dark fiber o longitudes de onda sobre lit fiber
- Una virtual private ethernet basada en MPLS
- Una virtual private ethernet basada en túneles con cifrado y autenticación
- Incluso el tráfico privado sobre redes públicas de telecomunicaciones a veces se describe como “desconectado”
- Un esquema donde equipos de hardware establecen túneles cifrados y autenticados sobre una common-carrier network como Internet
- Un esquema que usa equipos sin certificación de la NSA
- Túneles de software validados que configuran el stack de red del sistema operativo a bajo nivel para evitar el bypass del túnel
- Túneles de software con menor nivel de validación
- Un esquema armado con WireGuard y scripts de iptables
- La conectividad limitada a Internet también se mete en la misma bolsa
- Una red privada que solo permite flujos de tráfico extremadamente acotados mediante enrutamiento basado en políticas
- Una arquitectura donde los flujos permitidos están registrados en tickets viejos de Jira y algunos fueron agregados “para que funcione”
- Un esquema basado en firewall donde la salida es relativamente permisiva y la entrada es estricta
- En la nube, el alcance también se vuelve difuso
- Una AWS private VPC sin enrutamiento externo
- Una VPC que se comunica con otras private VPC por medio de PrivateLink u otros mecanismos
- Una arquitectura donde algunas VPC conectadas sí tienen rutas hacia Internet
- Un esquema con NAT Gateway e Internet Gateway, pero con security groups estrictamente configurados en ambos sentidos
- Todos estos casos han sido descritos alguna vez como “no conectado a Internet”, pero la superficie de ataque y el riesgo son distintos en cada uno
- Cuando se dice que un sistema de reservas aéreas “no debería estar conectado a Internet”, si no se está hablando de una ausencia total de red, en realidad se está apuntando a alguno de esos estados intermedios, y cada uno tiene consideraciones prácticas distintas
Los entornos offline disparan costos y plazos
- Operar software en redes sin Internet o con conectividad fuertemente restringida hace crecer mucho las estimaciones de tiempo y costo
- En formas más débiles, como una AWS private VPC, se puede calcular algo así como entre 3 y 5 veces más
- En formas más fuertes, cercanas al aislamiento total, puede subir a 10 veces o mucho más
- Casi todo el ecosistema de software está diseñado bajo la premisa de la conexión a Internet
- Los sistemas operativos intentan traer actualizaciones desde servidores online
- Los proveedores de SO comerciales pueden ofrecer infraestructura de actualización dentro de redes privadas como una licencia paga aparte
- En SO gratuitos se puede resolver por cuenta propia, pero usar tecnologías modernas puede traer grandes molestias
- En desarrollo y despliegue se repiten los problemas con varios gestores de paquetes y repositorios internos
- El nivel de soporte para repositorios internos privados cambia según cada gestor de paquetes
- La complejidad crece al combinar múltiples gestores, distintas formas de invocación y diferentes entornos de ejecución
- Los certificados TLS de servicios internos también generan trabajo repetitivo
- Los servicios dentro de redes privadas muchas veces no usan certificados incluidos en los programas raíz de las CA públicas
- Hay componentes como el JRE que tienen su propio trust store, y en algunos stacks tecnológicos el comportamiento cambia según la librería
- Aunque exista un trust store del sistema operativo, si cada herramienta usa su propio almacén hay que ajustarlas por separado
- Las licencias en la nube y la verificación de entitlement también se vuelven obstáculos
- Algunos programas intentan conectarse al exterior para validar su licencia en la nube
- Las alternativas pueden ir desde sumar muchas excepciones al firewall hasta emitir esquemas de licenciamiento personalizados, y eso puede tomar tiempo
- Las actualizaciones de contenido offline pueden volverse complejas solo por el proceso del proveedor
- En un caso de software empresarial, hubo que pasar por un portal antiguo de soporte al cliente y además por un portal separado de entitlement
- Tomó más de 3 meses abrir cuentas y escalar el caso, y el portal final tenía un certificado TLS inválido
- El procedimiento documentado para aplicar la actualización ya no funcionaba, así que hizo falta un largo intercambio de correos con ingenieros
- Se pagó una suma de cinco cifras por una licencia de 1 año, pero casi se venció antes de quedar lista para usarse, y una demora en emitir la extensión de licencia terminó frenando el pipeline de CI
- La dificultad de operar offline no viene de que una tarea puntual sea imposible, sino de que todas las tareas se vuelven un poco más difíciles: una especie de death by a thousand cuts
- Los productos que no fueron pensados para entornos offline suelen resolverse con scripts improvisados y parches, y esa deuda técnica termina trasladándose al cliente que opera en ese entorno
- Red Hat responde relativamente bien en esta área, pero el tiempo que se ahorra se paga en efectivo
Estos entornos son raros y se concentran en ciertas industrias
- Las formas fuertes de entornos no conectados a Internet aparecen sobre todo en defensa y agencias de inteligencia
- Algunos bancos también mantienen prácticas fuertes de segmentación de red
- Defensa, inteligencia y banca también son industrias conocidas por sus altos costos y largos plazos, y eso no es ajeno a esta forma de operar
- Las formas más débiles de conectividad restringida aparecen sobre todo en industrias altamente reguladas como finanzas y salud
- A veces también hay empresas de software comunes que bloquean fuertemente la red porque priorizan muchísimo la seguridad
Qué respuesta práctica se puede dar hoy
- Que menos sistemas estén conectados a Internet no es, en sí mismo, una mala idea
- Pero la industria del software actual no está preparada para operar cómodamente en entornos sin Internet o con conectividad restringida
- La respuesta realista se acerca más a aumentar la conectividad limitada y la preparación para operar offline que a exigir aislamiento total
-
Restringir al máximo las políticas de red
- Hay que aplicar políticas de red restrictivas a la mayor cantidad posible de sistemas
- Los proveedores de nube hoy facilitan más este tipo de configuraciones que antes
- En AWS no es facilísimo operar un entorno práctico sin ruteo hacia Internet, pero tampoco es algo imposible de lograr
- Si uno se mantiene dentro del alcance de los AWS managed service, en general el dolor es menor, aunque tiene costo
-
Crear software pensando en entornos offline
- Las funciones que necesiten conectarse al exterior deberían poder desactivarse siempre que sea posible
- Si desactivarlas es difícil, el cliente al menos debería poder cambiar el endpoint usado
- Si el endpoint se puede cambiar, también hace falta una forma de que el cliente opere su propio endpoint
- Si solo se trata de archivos estáticos, puede ofrecerse fácilmente con algo como nginx y un directorio
- Si es una API, tal vez haya que distribuir la implementación interna al cliente, con la carga de mantenimiento que eso implica
-
Reducir supuestos sobre TLS y dependencias
- En entornos offline, pequeños supuestos sobre conectarse a otros servicios se vuelven complejos
- No se puede asumir que habrá acceso a Let’s Encrypt
- Los entornos offline casi siempre implican una autoridad certificadora interna
- Hay que usar el system trust store
- No se deberían traer requisitos ni dependencias en el momento del despliegue
- Docker tenía como ventaja volver autocontenidos los paquetes, pero hay contenedores que ni siquiera arrancan si no pueden acceder al repositorio de npm u otros similares
- A veces hay que modificar el TLS trust store dentro de cada contenedor Docker, así que en entornos offline Docker incluso puede volver más difícil la administración
La relación entre el incidente de CrowdStrike y la conexión a Internet
- En el incidente de CrowdStrike aparecieron varias veces reacciones del tipo “¿por qué estaba conectado a Internet?”, pero si lo estaba o no es casi ortogonal al problema que ocurrió en ese momento
- Las actualizaciones de contenido de CrowdStrike son, idealmente, del tipo que también debería poder entregarse rápido a entornos offline
- En la práctica, en entornos fuertemente offline el mirror interno de actualizaciones de CrowdStrike puede quedarse atrasado por días, semanas, meses o años
- Ese atraso puede hacer que se evite un problema, pero eso se parece más a una coincidencia causada por dos errores que a un diseño correcto
1 comentarios
Opiniones en Hacker News
Trabajo en seguridad/sistemas/operaciones, pero discrepo de fondo con esta premisa. Entiendo que el autor diga que “no es tan fácil”, y estoy totalmente de acuerdo, pero eso no significa que se esté haciendo bien el trabajo.
Lamentablemente, la mayoría no lo hace bien, y toda la industria está diseñada para poder aguantar aunque se hagan mal las cosas, mientras vuelve difícil hacerlas bien.
Si vas a desplegar señalización digital, el acceso a la red debería estar en una lista de permitidos limitada a la dirección IP de mi servidor, y solo debería aceptar conexiones establecidas con actualizaciones firmadas y fijación de certificados (certificate pinning).
Con eso, se vuelve casi imposible que un atacante remoto la toque. Si miras la industria de seguridad que creció con la expansión del Internet de las cosas (IoT), claramente hay señalización y otros equipos IoT/SCADA/de despliegue con puertos abiertos y contraseñas por defecto todavía presentes.
IoT no es más que una computadora, pero también es una computadora que queda aún más abandonada que los servidores o máquinas virtuales que ya se operan mal.
Hay lugares que lo hacen bien, pero son poquísimos, porque la estructura no recompensa hacerlo bien. Seguir “buenas prácticas” o las guías del proveedor no significa hacerlo bien; muchas veces solo significa haber hecho lo suficiente para que el proveedor te dé soporte, y en muchos casos implica acceso de red sin restricciones.
Todavía hay que preocuparse por bugs de red, vulnerabilidades criptográficas, errores de configuración y otros problemas que podrían permitir que un atacante remoto explote el sistema. Para sostener ese argumento, no basta con un ejemplo de algo más bloqueado; hace falta un ejemplo que literalmente no esté conectado a internet.
No me queda claro en qué difieres del autor del blog. ¿O quieres decir que, como la gente no tiene esa capacidad, mejorar la seguridad de los sistemas conectados a internet es fundamentalmente imposible?
En Suecia existe una red privada separada de internet llamada Sjunet, que usan los proveedores de salud. El objetivo es hacer que las computadoras sean dispositivos de comunicación valiosos, sin exponer la TI hospitalaria a todo internet.
Se espera que los miembros de Sjunet conozcan sus propias redes y controlen estrictamente su TI.
Sjunet también puede verse como un entorno con air gap a nivel de industria. Mejora la seguridad y, al mismo tiempo, creo que cuesta menos que si cada organización operara su propia red aislada con una enorme lista de permitidos.
Da una falsa sensación de seguridad y también sirve de excusa para malas políticas de seguridad. El ancho de banda es bajo y caro.
Es una red que conecta instituciones como oficinas de condado y municipalidades para darles acceso a una base de datos central donde se almacenan datos personales de los ciudadanos. Se usa para cosas como cambiar de domicilio, emitir nuevos documentos de identidad y registrar nacimientos o matrimonios.
Hasta donde sé, la aplicación “Źródło” se ejecuta en una computadora “aislada” separada, sin internet pero con acceso a la red interna, y se autentica mediante certificados criptográficos de cliente a través de una tarjeta inteligente.
¿Todas tienen los parches al día? ¿Saben que la gente no conecta cualquier dispositivo USB?
Algo parecido a Tor, pero sin las cosas sospechosas.
Como ingeniero de control, construí cientos de máquinas. Hay cables Ethernet para redes de bus de campo, pero nunca deben conectarse a Internet.
En cada taller de herramientas y matrices del parque industrial local hay máquinas CNC con puertos Ethernet que no deberían exponerse en Internet. Toda planta de manufactura con equipos a medida, líneas transportadoras, prensas, robots, CNC, estaciones de bombeo, etc., usa Ethernet, pero utiliza sistemas PLC y HMI que no son aptos para estar expuestos a Internet.
El artículo dice que las computadoras modernas de trabajo son casi principalmente dispositivos de comunicación, y que no hay muchos sistemas prácticos que creen valor sin conectarse con otros sistemas de trabajo, pero ignora a toda la industria manufacturera y a los dispositivos electrónicos que esa industria fabrica.
Millones de sistemas embebidos y PLC crean valor todo el día comprobando cada 1 milisegundo si cambió el estado de las entradas digitales físicas y lógicas, y si cambió, modificando el estado de las salidas digitales físicas y lógicas.
No hace falta ponerle un sistema de seguridad de 2024 a una soldadora por resistencia cuya pieza fundida se fabricó hace más de 100 años y cuya última actualización fue en 2003, cuando se le agregó un PLC para configurar recetas y una pantalla monocromática. Basta con ir con un portapapeles, ingresar los valores objetivo y fundir el acero correctamente.
Normalmente, para conectarte a estas máquinas tienes que llevar una laptop, tomar un cable patch Ethernet y caminar hasta la máquina. Si hace falta algo más que eso, se espera que el cliente la ponga en una red de tecnología operativa (OT) con firewall, o que conecte tecnología de la información (IT) y OT mediante equipos SCADA/VPN como Tosibox o Ixon.
Puede que lo que tú manejas no sea algo que alguien quiera explotar, pero como los PLC se encuentran a menudo en infraestructura crítica e instalaciones de manufactura avanzada, son objetivos atractivos para actores maliciosos. Podrían intentar explotar infraestructura crítica, o infectar algún dispositivo con poca seguridad al que algún día pueda conectarse directamente un endpoint de alto valor, como una laptop de ingeniería.
https://www.cisa.gov/news-events/cybersecurity-advisories/aa... - Infraestructura de agua
https://claroty.com/team82/research/evil-plc-attack-using-a-...
Sigo sin convencerme del argumento de que no se deberían aislar los sistemas con air gap porque eso impide usar prácticas de desarrollo centradas en Internet. Me parece un argumento absurdo.
Si un sistema necesita que le sellen el puerto Ethernet con epoxi, entonces desde el principio no debió haberse programado con prácticas de desarrollo centradas en Internet. ¿Una máquina de MRI que al arrancar trae dependencias JS desde NPM? Directo a la cárcel. No es una metáfora: literalmente.
Después de ver un video de alguien manipulando un kiosco de McDonald’s, empecé a intentar lo mismo con equipos que veía en distintos lugares.
En un patio de comidas había un kiosco con Windows y acceso completo a Internet. Alguien podría haber descargado malware y robado datos de tarjetas de crédito. Cada vez que lo usaba, lo apagaba o dejaba un mensaje en la pantalla, y al final empezaron a ponerlo en modo kiosco.
Otro era un kiosco de estacionamiento que no estaba reforzado en absoluto. Parece que los delincuentes todavía no se han dado cuenta.
El tercero era una pantalla interactiva de una marca de cerveza. No era algo capaz de causar grandes daños, pero estuvo bien abrir el Bloc de notas y dejar escrito “Drink water”. Al final la apagaron, y eso también cuenta como solución.
“No darle dinero a transeúntes al azar” debería estar bastante arriba en la lista de requisitos, pero en la práctica no fue así.
Me identifico mucho con esta parte. Estaba intentando hacer que el almacén de confianza JRE de IntelliJ entendiera que debía usar un nuevo certificado para zscaler; había dos o tres JDK seleccionables, puse el certificado nuevo en cada uno de sus almacenes de confianza, y aun así no funcionaba, sin poder entender por qué.
También existe hamnet. Sobre el bloque de IP 44Net, algunas partes son ruteables en Internet y otras no.
https://hamnetdb.net/map.cgi
Como usa bandas de radioaficionados, tiene restricciones interesantes. El uso comercial está completamente prohibido.
Ese es el contrato social de esas bandas de frecuencia: tienes acceso barato a muchas bandas, desde 136 kHz hasta 241 GHz, pero no puedes ganar dinero con ellas.
Solo está bastante extendido en Países Bajos y Alemania: https://hamnetdb.net/map.cgi . Aquí en España no puedo usarlo en ningún lugar cercano.
Parece bastante obvio que los sistemas de reservas de aerolíneas al menos tienen que estar conectados a una red, y no he oído a mucha gente decir que todo debería estar offline. Pero también escuché, por ejemplo, que máquinas de torno en talleres se detuvieron por este incidente.
Hay que pensar si realmente tenían que estar online. Claro que habrá razones, pero esas razones deben evaluarse frente al riesgo.
Además hay muchos ejemplos todavía más ridículos de cosas conectadas a Internet, como refrigeradores, hervidores y puertas de garaje. No sé si esas cosas se vieron afectadas por el incidente de CrowdStrike, pero aunque no haya sido así, la próxima vez es solo cuestión de tiempo.
Sobre la afirmación de que los sistemas no conectados son “muy, muy molestos”, según mi experiencia como usuario toda la seguridad es “muy, muy molesta”. Autenticación de dos factores, cambios obligatorios de contraseña, dispositivos bloqueados, escáneres de malware, sanitizadores de enlaces… algunas cosas son necesarias y otras son tonterías, pero no estoy en posición de distinguir cuál es cuál, y lo que sí es seguro es que todo genera fricción.
La gran conclusión que saqué no es “todos estos sistemas no deberían estar conectados a internet”, sino varias otras cosas.
Primero, estos sistemas no deberían permitir flujos de red salientes. Eso bloquearía todas las actualizaciones automáticas y luego podrían administrarse mediante canales de distribución internos.
Segundo, incluso si no se hace eso, muchos productos de software empresarial permiten desactivar las actualizaciones automáticas. Windows es el ejemplo típico, y lo mismo aplica para CrowdStrike. Escuché que entre los clientes de CS hubo quienes desactivaron las actualizaciones automáticas e hicieron despliegues manuales, evitando así el daño.
Tercero, además del punto 2, las actualizaciones deberían desplegarse de forma gradual después de pasar por algunas pruebas de humo. Por si acaso. También escuché que entre los clientes de CS hubo quienes hicieron despliegues graduales y lograron que solo algunos equipos se vieran afectados.
Es un texto que resume bastante bien la época en que entregábamos soluciones de IA de última generación a clientes militares. El 80% del esfuerzo se iba en hacer que herramientas que asumían internet funcionaran sin problemas en entornos air-gapped.