Reflexiones y Conversación sobre Trustzone y hipervsor.

Hola amigos, resulta que como consecuencia de haber redefinido mi infraestructura informática de mi taller he descubierto para mi el tema de hypervisors y trustzone con foco a su adaptación en sistemas embebidos. me voy a meter de forma "real y física" con el tema de hipervisores del tipo 1, también llamados "bare metall" en el servidor. Publico aquí la imagen de la estructura muy burda, es la primera edición:

29895094226_5a3f6de915_z.jpg


Tanto en mi PC, donde actualmente uso un i7 620, como con el Xenion X5550 a 2,67 GHz, uso procesadores con funcionalidad para operar hipervisor del tipo 1. Me compré 2 Xenion X5550 por solo 26,70 Euros incluyendo el costo del flete con LGA1366.

El hombrecito a la derecha abajo, yo y mi ordenador principalmente usa Windows 10, pero tengo un segundo disco duro con Ubuntu 16.04 TLS! Esto lo dejaré por ahora al menos, tal cual está. Ya estoy armándome el servidor con una placa madre ASUS P&t WS Professional a la cual le pondré unos de los procesadores Xenion 5550. Alí me voy a dedicar al reto de instalar el hipervisor tipo 1. Aún estoy investigando de que proveedor. Sobre el hipervisor pondré un entorno virtual con Windows 10 Pro y otra entorno virtual con Ubuntu 16.04 TLS.

Alguno de Ustedes ya tiene experiencias con hipervisores?

Por WiFi en el centro del gráfico ven las placas Raspi conectadas de forma inalámbrica con el servidor.

Aquí el enlace a un artículo muy interesante para mis objetivos y es que en controladores del tipo ARM Cortex basadas en la versión V8 la empresa ARM ha portado lo que llama Trustzone. Es funcionalidad de apoyo para la funcionalidad de hipervisor.

Voy a empezar a investigar cual proveedor ya es activo en este sector. las chances son muy buenas investigar en el entorno de los productos provenientes de Freescale en NXP. Esta es la parte del uso de la virtualización y el encapsulamiento lograble aislando partes de los programas en entornos virtuales proporcionados por estas funcionalidades.

Aquí un segundo artículo que consta de la "parte uno" y "la parte dos".

Esta serie de artículos a la que quiero sumar tales de la empresa "Mentor Graphics" se discute el tema de hipervisores como método de protección en sistemas embebidos con ejemplo a los entornos de sistemas embebidos en carros en general y de ciculación autónoma. Allí también cuentan que por ejemplo la industria de aviación ve en esta metodología una forma mas avanzada de proteger sus sistemas. Pero también las informaciones de la funcionalidad de hipervisores en sistemas embebidos, deep embedded, donde los tiempos de reacción de tiempo real parece exigir funcionalidad mas desarrollada aún para pasar la funcionalidad de hipervisor de la software a la hardware.

También me parece muy interesante las informaciones sobre la vulnerabilidad con foco en sistemas embebidos. Un ejemplo para esto que quiero presentar es el peligro que representa el poder acceder el sistema final por JTAG por ejemplo! Trustzone y mentor Graphics artículos hablan de la necesidad de implementar la funcionalidad de autorización a nivel de la hardware con instrucciones especiales que entonces son responsables cuando una funcionalidad de la software requiere comunicarse con software en la zona segura, Trustzone! Evidente me parece el ejemplo que dan cuando un evento exterior, que pudiera venir de un atacante, ejecuta una interrupción de alta prioridad. Entonces la hardware del controlador tiene que resetar el contenido de registros de la trustzone para impedir así el ingresar del atacante. Una vez que la ejecución vuelve al código ejecutado en la zona de seguridad, entonces la hardware tiene que poner los valores originales en los registros reseteados!

El IoT, IIoT o Industria 4.0 en conjunto con los múltiples núcleos en controladores modernos y que estos sistemas están conectados a redes y por lo tanto susceptibles a ataques. Pero también las interacciones de programas actuando en paralelo en diferentes núcleos hacen el tema de la seguridad y la programación adecuada algo supremamente mas complejo!

Quiero publicando esta contribución compartir estas informaciones. Pero también ojala encontrar foristas que también tienen conocimientos sobre el tema! El hilo creo que está bién aquí, pues las placas Raspis, en especial la RaspBerry Pi 3B que tiene un controlador ARM con las instrucciones de la versión V8. Veo que la implementación de la estructura informática de mi taller me da la posibilidad de meterme en esta materia para luego ver y analizar si la placas Raspi 3B en su SoC ya apoya tales funcionalidades! Con seguridad el tema, que parece estar en auge desde algún tiempo bastante reciente, será apoyado por modernas placas Raspi, siendo la 3B la primera que debiera tenerla! Como la sofisticación del tema impactará las implementaciones futuras, vale empezar a familiarizarse con el tema hoy, si fuera de interés.
 
Hola amigos. Investigando por que ruta avanzar en esto de materia de hipervisor me he encontrado una página que me está pareciendo apropiada para meterme en esto.

500px-Xen_Arch_Diagram.png


Un buen gráfico para mi representa un posible recurso de aprendizaje. este gráfico me parece demostrar de buena forma lo que es un "hipervisor tipo 1" y le da el nombre, "XEN", que el entorno de programación del hipervisor tiene. Aparentemente tanto Windows 10 como Ubuntu 16.04 TLS ya tienen la funcionalidad incluida para la cooperación con el hipervisor!

Si no mal recuerdo en mi contribución anterior el foco estaba en la temática del hipervisor de forma independiente de cual se podría usar. No digo que este camino me lleve a la meta, pero tal es cuando uno se mete en esto! Mi objetivo inicial es usar uno de los discos duros de mi ordenador de 160 GBytes como alternativa de donde arrancar el entorno.

El primer objetivo será ver como es que XEN es puesto en el disco duro y el ordenador arranque desde ese disco con XEN!

Primero quiero indicar los 2 entornos presentes.

El uno llamado "Dom0" es el entorno privilegiado. Recuerden que en mi primera contribución mencioné la interacción controlada por el hipervisor tipo 1. Esta consiste en hardware disponible en el procesador que resulta en un entorno privilegiado y instrucciones reservadas para este entorno y de una software, el hipervisor, que uso este entorno privilegiado para la administración del entorno de virtualización!

El otro llamado "DomoU" es el medio de comunicación entre los entornos virtuales, por ejemplo "Windows 10" y "Ubuntu" como sistemas operacionales huesped, aquí "Guest OS". usando instrucciones especiales disponibles como parte de la ampliación de procesadores para tales entornos virtuales para requerir algun servicio del entorno privilegiado.

Como pueden ver en el gráfico, en color "verde" esta lo que sería la placa madre, en mi entorno de aprendizaje sera la placa madre de mi ordenador. "XEN" entonces representa el hipervisor administrando la hardware de tal forma que los so's huesped, ahora en adelante lo llamaré "GuestOS" con sus "kernel", núcleos del os. La columna a la izquierda representa el hipervisor usando XEN para administrar la hardware y su "Dom0 Kernel" es el software privilegiado que representa la adminstración de los recursos de la hardware.

Allí, desde la consola las herramientas del hipervisor están disponibles para administrar el hipervisor.esto debe ser mi primer objetivo de llegar a este punto!
 
Hola amigos, como habrán notado el tema de entender el como reducir la vulnerabilidad de sistemas embebidos ha sido un tema de gran interés para mí por haber sufrido ataques que rindieron mi PC inoperable usando las cosas que activé durante mis primeros experimentos con la placa Raspi! Ahora encontré un artículo muy interesante en específicamente la vulnerabilidad en sistemas embebidos. Este artículo, doy el enlace de donde poder descargarlo como pdf, pone en contexto los temas de vulnerabilidad.

Como el artículo es en Inglés y como el tratar de presentar el mensaje de este artículo en Español es buen ejercicio para profundizar mi entendimiento de su contenido, trataré de presentar aquí el tema. Claro, un artículo con referencia a otro nunca alcanza la calidad del original, este intento tiene como propósito adicional el presentar un tema a aquellos no tan fluidos en el idioma Inglés, que ganará en importancia en un cercano futuro.

El artículo original tiene el título:

Securing modern-day devices with Embedded Virtualization and ARM Trustzone Technology

El primer paso del artículo quiere definir en que relación equipos IoT están referente a su vulnerabilidad y para ello da 3 ejemplos. La razón para presentar el tema del artículo empezando por presentar 3 tipos de equipos IoT y así presentar que clase de vulnerabilidad sistemas IoT tienen. También pone en relación el costo de tales productos IoT y de los mecanismos de protección. Si un equipo IoT cuesta 2 Euros invertir 10 Euros para reducir su vulnerabilidad no tiene sentido. Mecanismos de reducción de vulnerabilidad por lo tanto también tienen que estar en una sana relación al costo del equipo y al monto disponible para reducción de su vulnerabilidad.

Uso el término de vulnerabilidad como término que presenta que potencial de ser víctima de una ataque un equipo tiene. Existen varios conceptos que ayudan el recopilar los objetivos de una reducción de vulnerabilidad. 2 de estos presento ahora:

1. CIA

Aquí doy el enlace a un glosario en Español y si van a los puntos bajo "C" encuentran el tema CIA presentado en Español.

CIA
Véase: CID. Acrónimo inglés de confidentiality, integrity y availability, las dimensiones básicas de la seguridad de la información.

C = confidencialidad

Confidencialidad
(Inglés: Confidentiality). Propiedad de la información de no ponerse a disposición o ser revelada a individuos, entidades o procesos no autorizados.

I = integridad

Integridad
(Inglés: Integrity). Propiedad de la información relativa a su exactitud y completitud.

A = disponibilidad (availabilty)

Disponibilidad
(Inglés: Availability). Propiedad de la información de estar accesible y utilizable cuando lo requiera una entidad autorizada.

Estas definiciones no me gustan del todo pues creo que no presentan la explicación de ejemplos relacionados a cada punto. Pero es la forma usada por recursos oficiales. Quiero dar el enlace a un curso gratuito sobre criptología de la Universidad de Stanford
 
Última edición:
Estas definiciones no me gustan del todo pues creo que no presentan la explicación de ejemplos relacionados a cada punto. Pero es la forma usada por recursos oficiales. Quiero dar el enlace a un curso gratuito sobre criptología de la Universidad de Stanford
Esas "definiciones" que mencionás son los pilares estándar para la implementación de la Seguridad Informática en una instalación, y su significado es muy simple y conciso:

  • Confidencialidad: nadie debe acceder a lo que no le corresponde acceder.
  • Integridad: La información debe mantenerse completa y "precisa" --> Debe estar bajo control según el punto anterior.
  • Disponibilidad: La información debe estar disponible donde y para quien la necesite, sujeto a las restricciones anteriores.
Y esas "definiciones" abarcan absolutamente todo lo que se refiere a la protección de la información. Lo que sucede con ellas es que son definiciones de alto nivel, y para bajarlas a la tierra hay que definir lo que se llama "Políticas de Seguridad Informática" que básicamente son conjuntos de documentos que definen lineamientos sobre temas específicos de seguridad, como por ejemplo "Política de Usuarios, Contraseñas y Perfiles de Operación" que está relacionado con la Confidencialidad y la Integridad, o "Política de Backup de Información", que está relacionada con la Disponibilidad.

Y así en adelante...

PD: Estuve cuatro años a cargo de la seguridad informática de un gran centro de cómputos de un organismo gubernamental en Argentina, así que esta historia de "los pilares" la conozco bastante bien.
 
A la pucha Hellmut... primera vez que veo esto de hiper-visores para sistemas embebidos.

Tu laboratorio dentro de poco se va a convertir en una atracción futurista para los electrónicos más básicos como yo :LOL:
Estaré más que interesado en ver como vas progresando con tu setup (y)

Aja... mover el hypervisor de software (cortex A) a hardware de micros... acá estoy mirando las primeras páginas de este pdf para revisar algun concepto.

Ok... el tema es interesante, pero creo que el campo de aplicación es algo mucho más grande que lo normal: vehículos autónomos, automatización de fábricas/almacenes conectados a la red, sistemas de comunicaciones de banda ancha, organizaciones que precisen preservar muy bien secretos comerciales/info de usuarios/información crítica.

¿Parecería un poco alejado de lo que vería un electrónico común y corriente?, ¿o (muy probablemente) me equivoco y es algo que se empezara a ver más en hogares y empresas pequeñas?
Solo escribo las preguntas que pasan por mi cabeza, cualquiera que haya leído 5 minutos más que yo (un gran total de media hora :D) va a poder ponerme en mi lugar bien rápido...

Paso al 2do mensaje Hellmutiano :unsure:
Estoy pensando en cual es tu objetivo... diría que automatizar el laboratorio de forma super-segura para que Don Hellmut pueda minar bitcoins a raudales :rolleyes:
Pero viendo arduinos y puntos de acceso inalámbricos sería para automatizar el laboratorio lo más que se pueda de forma segura o algo así.

Tercer mensaje...
Aaaaahhhh... te atacaron via internet?, la PC que tenías conectada a la raspy. Bueno, ahí ya hay una fuerte motivación para no sufrir más daños.
¿Pero fue algo normalmente evitable? no me quiero meter donde no corresponde, pero quizás si es la misma máquina para trabajar que para usar el facebook que para tenerla de servidor... bueno, dividirse la red en zona segura y DMZ, ¿jugar con la arquitectura de red doméstica?
Solo quería plantear eso último, no esta bien meterme a especular con la privacidad de cada uno.

Es decir, al final ya se ve clara mi cuestión, ¿no es demasiado hardware para un taller de electrónica?
 
@Dr. Zoidberg: Quien sabe y está familiarizado con el tema, las explicaciones de los términos son completas y correctas. El punto es que yo, y quizá algún otro lector de este hilo, por ejemplo Ardogan, no familiares con el tema, necesitan ejemplos mas plásticos para captar el alcance de estos términos! Pero el énfasis que yo tengo en la materia es en el uso de estos mecanismos en sistemas embebidos. En el campo de centros de cómputo y de servidores estas técnicas se aplican y se desarrollan en grandes pasos! Ssistemas altamente embebidos, donde el hardware ofrece recursos mucho mas limitados, y esto es aplicable a dispositivos "IoT". Las experiencias recientes, la cada vez mas alta calidad de los atacantes y los miles de millones de equipos IoT, hay quien habla de "trillones", millones de millones de dispositivos IoT e IIoT, las cada vez mayores capacidades de los controladores usados, requieren de reducir al máximo la vulnerabilidad de sistemas embebidos. Al momento solo tengo noción de los controladores i.mx6, que tienen implementadas funciones de apoyo de la virtualización en hardware, lo que reduce la complejidad de la software. Hay quien escribe que solo el apoyo masivo de la virtualización, del aislamiento, en la hardware de un controlador permite reducir los riesgos de vulnerabilidad de los equipos IoT! es mas, como estoy seguro bien sabes, recientemente los estados unidos sufrieron graves daños debido a un atacante que uso millones de dispositivos embebidos para su ataque!

El proliferar de dispositivos IoT, dispositivos accesibles desde la nube a millones de millones de dispositivos y las cada vez mayores capacidades y recursos de los controladores en estos dispositivos hace que este tema, que fuera tema de pocos en oficios como el que tu tenías, alcance la realidad profesional de muchísimos. Viendo las dificultades que me he encontrado al investigar el tema de la virtualización y del aislamiento como método de protección de equipos embebidos, opino que este medio es un buen camino para hacer conscientes del tema a nuestros compañeros de habla hispana! Tus conocimientos y tus experiencias con seguridad pueden enriquecernos a todos aquellos con voluntad de dedicarse al tema. Yo voy a usar la feria "electronica 2016" aquí en Munich a mitad de noviembre para informarme sobre el tema y encontrar recursos adicionales. lo que mas quisiera encontrar es una placa similar a la raspi con un controlador que tenga el apoyo en hardware lo mas sofisticado posible!

@Ardogan: Ojalá note he ofendido poniéndote a ti y a mi persona como individuos no experimentados del tema y quienes se benefician de ejemplo concretos. pero quiero responderte a tu referencia a que objetivos tengo!

La temática de la protección de sistemas embebidos requerirá el hacer tales sistemas parte del IoT y por lo tanto la inmensa mayoría de sistemas en un futuro muy próximo tendrá que contener el apoyo de la virtualización y aislamiento.

Como ya no puedo trabajar en la industria por razones de salud y por los daños que sufrí debido a varios paros cardíacos, el estudiar, investigar y aplicar en experimentos tiene la función de mantener y recuperar mis capacidades mentales, de llenar mi vida con objetivos que me fascinen y así mantener un estilo de vida organizado. Típico alemán, según dicen!

Empecé con el modelismo naval y allí con la construcción y diseño del modelo de un velero. Después de varios años, en los cuales aprendí y desarrollé mis capacidades de modelismo físico, el querer realizar un sistema de control de escotas que permita operar el control de escotas y por lo tanto la posición de las velas. esto fue el punto inicial, después de aprender a realizar mis propios circuitos electrónicos, de reactivar mis capacidades de programación y de estudiar por ejemplo la funcionalidad de un motor de paso en detalle, me embarqué en la materia de modelación de partes de mi sistema de control de escotas, lo que después de varios cominos me llevo a decidirme por la software de Wolfram Software, Mathematica y SystemModeler. Mathematica me da una herramienta muy poderosa matemática que se requiere para desarrollar los algoritmos y del SystemModeler que permite modelar un sistema de multiples dominios, mecánico, eléctrico, etcétera usando el lenguaje de modelación "Modelica. Como el modelar exige el verificar la funcionalidad del modelo en comparación a la realidad física, me encontré con las técnicas de HiL y SiL, Hardware-in-the-Loop y Software-in-the-Loop"! Como estos temas aún eran muy rudimentariamente apoyados por las funcionalidades de Mathematica y SystemModeler, me decidí por usar la plataforma que mejor apoyaban estas herramientas entonces, las placas Raspi!

Así me encontré con la necesidad de aprender e investigar el como usar estas placas en combinación con un PC como sistema de desarrollo. Así empecé a inestigar y experimentar este entorno, muy pronto siendo capaz de manejar las placas Raspi desde mi PC y hacerlas accesibles desde el Internet. De lo que me descuidé, por creer estar seguro debido a que mi PC con Windows siempre era en la versión mas actual y utilizando herramientas de protección. resulta que de pronto mi PC con Windows se llenaba de aplicaciones de una utilidad de Windows al punto que dejaba de ser posible el solo escribir un texto en un editor, debido a que los caracteres aparecían después de casi un minuto. Tratando de usar los caminos disponibles para reparar esto no tuve éxito. Por esta razón me decidí de actualizar mi Windows 7 Ultimate a Windows 10 Pro. esto me recuperó mi PC.

Así me decidí por estudiar Linux, el os de Raspi y de las técnicas de protección. Me metí en algo para mi nuevo y como siempre me acabó fascinando y despertando mi apetito por nuevos conocimientos! Así en algún momento me encontré con la temática de hipervisores al tratar de aprender de forma metódica el como el programar y experimentar en entornos virtuales. Cosa que descubría muchos programadores hacen para no poner en peligro la funcionalidad de su PC! Estudiando el tema de hipervisores muy pronto encontré que el procesador de mi PC efectivamente ya tenía en hardware apoyo para la virtualización. Muy pronto me encontré con que la virtualización con hipervisores y contenedores como el método establecido por centrales de cómputo, donde los clientes no reciben su servidor físico individual, sino que reciben entornos virtuales no diferenciales de sistemas físicos. Es mas, estos entornos pueden ser transferidos a otro servidor físico aún cuando tales entornos virtuales están activos.
Leyendo sobre los mecanismos de apoyo que la empresa ARM desarrolla para sus productos ofertados y leyendo en mayor detalle en que consisten los elementos de apoyo en Hardware para la virtualización, pude ver que estas funcionalidades desarrolladas por ARM bajo el concepto de "TrustedZone", solo son opcionales para aquellos que toman licencia de los núcleos de ARM. Entre otros, los núcleos en la nueva placa Raspi 3B, son apoyados por ARM para la implementación de funciones de apoyo de la virtualización. Pero con excepción de los controladores i.mx6 la documentación de ningún proveedor de controladores contiene referencia a estas funcionalidades. Así el articulo reverenciado al principio de esta contribución que combina TrustedZone y sistemas embebidos resaltó al punto que me decidí por publicar esto.

Creo que el tema de la reducción de la vulnerabilidad de sistemas embebidos en el ámbito del IoT usando virtualización y aislamiento es tan reciente, que todavía no existe un amplio apoyo. Pero la necesidad de volver sistemas IoT mas seguros, menos vulnerables, no permitirá sistemas IoT sin tales mecanismos. Yo creo que el futuro de sistemas embebidos en la inmensa mayoría de los casos deberán ser sistemas IoT y por lo tanto tendrán que usar estos mecanismos de protección!
 
Última edición:
A ver....
La idea de los hypervisors tipo 1 es buena, pero no para proteger, sino para poder separar los dominios de un problema cuando se lo resuelve con uno o más programas. Esta separación "ayudaría" a que si un subsistema es vulnerado esa vulnerabilidad (o el ataque) no se propague a otros subsistemas (hardware + software).
Por supuesto que esto no es automático ni mucho menos, por que si consideramos un sistema embebido que soporte virtualización e hypervisors aún nos queda hacer los programas que permitan que el sistema embebido cumpla con las función para la que fué creado, y eso corre en las manos de los diseñadores de software y los programadores.... y ese es precisamente punto débil del asunto: personas con mucha formación en las ciencias electrónicas pero no-muy-buenas para programar o tipos con formación en ciencias de la computación pero con fallas importantes al tiempo de interactuar con el hardware.... en general. A eso hay que sumarle la escasa experiencia en programación concurrente, que si bien no es exactamente el caso de los hypervisors es terriblemente parecido cuando se pretende intercomunicar los diferentes programas entre sí. Ni hablar si dos programas "independientes" (en diferentes VM) entre sí necesitan acceder al mismo componente de hardware... que el hypervisor debe haber virtualizado, o bien cuando necesitan intercambiar información. Estas cosas mas o menos se solucionan si se dispone de un hypervisor o un sistema operativo avanzado (+hardware) que soporte los mecanismos de virtualización, pero este tipo de cosas no es muy común en sistemas embebidos.

Digo.... la virtualización puede ayudar a "contener" (no proteger) los ataques, pero eso exige una política de desarrollo de software y capacitación bastante sofisticada que no cualquiera puede afrontar
 
@Dr. Zoidberg: Quiero darte el enlace a una serie de artículos sobre el tema de seguridad aquí!

Este artículo y subsiguientes de la misma serie sobre el tema trata muy a fondo el tema de los "threats" en diferentes puntos de un sistema. Como seguro bien sabes, los peligros que impactan la vulnerabilidad de sistemas está intensamente relacionada a diferentes estados del sistema a analizar. Empieza con el acceso a una parte usando los métodos del "debug" y sigue hasta los aspectos relacionados con la comunicación, pasnado por diversos estados operativos de un sistema.

Por un lado el reto de sistemas IoT, que por definición están conectados a la red, son los limitados recursos, los medios económicos muy reducidos por unidad debido al bajo precio de los sistemas que limitan que tipo de protección tiene sentido.

Pero también el aspecto que mencionas que un tal sistema embebido tiene que cumplir sus funciones y eso dentro del entorno de tiempo real que frecuentemente tiene lugar en tales sistemas. El asunto se vuelve hasta mas complejo cuando se analiza la situación en Socs como aquel en el Raspi que tienen por ejemplo hasta 4 núcleos, o de controladores como aquellos de NXP, heredado de Freescale, los i.mx6 a 8. que al igual de otros controladores tienen núcleos diferentes, como ARM A7, 4 cores en el i.mx8, 2 ARM Cortex M4F mas GPUs. El pdf de Mentor Graphics al que doy el enlace al principio de mis contribuciones de hoy, pero también otra parte de los artículos de la revista "Semiconductor Engineering", trata el tema de los threats y del aislamiento al tiempo de analizar los áreas adicionales abiertos a ataques que resultan de como se organiza la software en tales sistemas embebidos.

Mucho me gusta la comparación de las imagenes 7 y 8 de la página 7 del pdf. Allí se compara y se analiza la vulnerabilidad de IoT de múltiples núcleos. En la imagen 7 se presentan las barreras que debe tener tal sistema en su hardware y consiguiente en lo que llama "Monitor!. En la imagen 7 cada sistema de un núcleo contiene tanto la funcionalidad del entorno seguro, "Secure World" y de "Normal World". Muy bien describe que requerimientos debe cumplir la software del entorno seguro y que es altamente deseable de mantener la cantidad de código lo mas limitado posible, para así poder lograr la verificación de la seguridad de la software que por definición debe estar libre de errores y de limitar al máximo los áreas de ataque. El Monitor es lo equivalente a un hipervisor del tipo 1m pero que maneja de forma separada el flujo de datos y de instruciones, L1 D y L1 I. Los 3 bloques debajo de la imagen del bus interno, Snoop Control Unit, presenta que es hardware la que monitorea si quien accede tiene el derecho a ello. El bloque "Integrated Interrupt Controller y Distributor" tiene la función de evitar el ataque usando el estado de servicio de interrupciones.

Dentro del artículo se escribe que en sistemas IoT seguridad solo es posible si esta es realizada en Hardware. vale la pena lleer en detalle de como aplicaciones en el entorno "Normal" pueden comunicarse con el entorno protegido. Y que toda software que acceda al entorno protegido a su vez tiene que ser "segura! Esto viene muy unido al concepto de privilegiada ejecución requerido en sistemas que se aproximen a lo que ARM denomina "Trustedzone". Todos conocemos de un sistema Linux por ejemplo el núcleo o Kernel de Linux se ejecuta en un nivel privilegiado y los programas normales en un entorno de menos privilegio. En sistemas que apoyan la virtualización y el aislamiento algo que llamemos "hipervisor" es ejecutado a un nivel mas privilegiado que aquel en el cual opera el Kernel de Linux! Así un programa el el entorno normal está ejecutando las instrucciones de su código que exclusivamente relacionadas al entorno normal. Servicios especiales que usan instrucciones especiales privilegiadas se comunican con el programa en el entorno normal y de allí pueden pasar datos al entorno super privilegiado del hypervisor. Solo usando estas instrucciones especiales reservadas por el servicio es posible comunicarse con el hipervisor ejecutado en el nivel de super privilegio.
Tienes toda la razón cuando escribes que los entornos virtualizados aislan código ejecutado en ellos y hasta los controladores ARM Cortex Mx usan la hardware de la MMU, "Memory Management Unit", para restringir el acceso de un entorno fuera del área de la memoria asignada a el y así logran un aislamiento. Pero cuando controladores como actualmente solo conozco de las especificaciones del controlador i.mx8 de antes Freescale, ahora NXP y pronto Qualcomm, implementan un repertorio mucho mas amplio de protección.
Creo que resulta excesivo si trato con medio conocer, para exagerer, tratar de presentar todos los aspectos que los artículos mencionados presentan. Pero los artículos de "Semiconductor Engineering" tratan el tema extensivamente analizando y presentando todas las áreas de ataque y los métodos de ataque relacionados a cada área de ataque.
Creo, eso sí, poder contradecirte, si lo he entendido bien, sobre estimas el role de la software. Si aceptamos lo escrito en los artículos reverenciados por sendos enlaces en mis contribuciones, una protección total es imposible en cualquier sistema en contacto con el Internet. Lo único que se puede lograr es reducir la probabilidad de éxito de ataques o de hacerlos tan "caros", refiriéndose a los recursos de computación, por ejemplo que se requieren, que el atacar con éxito no es justificable para el atacante en la mayoría de los casos.
Igualmente creo que concordamos que el punto de defensa mas debil de todo sistema esta en el ser humano que tiene acceso al sistema!
Así se expresa en los artículos, que el lograr un nivel de seguridad necesario para equipos del IoT requiere y exige que la hardware ofrezca los servicios mas extensos posibles para reducir la vulnerabilidad.
Creo que hay una gran diferencia entre la situación de vulnerabilidad y de los métodos requeridos para su reducción a un nivel tolerable para un mundo con miles o millones de millones de equipos IoT, comparado con la ya casi madura situación en centros de cómputo, donde los recursos económicos para establecer una baja vulnerabilidad son casi infinitos y la posibilidades de sub-sistemas de protección pueden costar miles de Euros por unidad!
 
Última edición:
Es que, a fin de cuentas, es como todo lo que nos rodea: la famosa relación costo/beneficio.
La seguridad absoluta no existe, independientemente de la cantidad de hardware que se agregue en el camino. Por ejemplo, como ya comentamos, la virtualización me permite "reducir el área de impacto" de una vulnerabilidad por que me permite aislar tareas entre sí creando una máquina virtual para cada una de ellas, sin embargo, la exposición de vulnerabilidades por código mal diseñado sigue presente. La "Trusted Zone" permite partir la ejecución en, por así decirlo, procesos de confianza y procesos sin-confianza, dando privilegios a los primeros y quitándoselos a los segundos. Sin embargo, la necesidad de comunicación entre ambos es otra fuente real de potenciales vulnerabilidades. La gente de ARM parece que viene trabajando mucho en esto, así que habrá que analizar hasta donde ha llegado.
Como comenté antes, esto no "protege" al dispositivo IoT sino que atenúa (en mas o en menos por que depende del diseño del software) los efectos de una vulnerabilidad explotada en un ataque, lo que NO ES POCA COSA!!!, pero las viejas herramientas de detección y prevención de ataques (NDIS, firewalls, etc) siguen siendo válidas... al menos por ahora, para proteger de forma efectiva una instalación de estos aparatitos. Por ejemplo, un firewall stateful completamente convencional e incluido en el propio kernel Linux (el famoso iptables) basta para evitar ataques desde Internet... o de la red local, da lo mismo, sin quitar la posibilidad de acceso.
Lo otro que hace falta es una plataforma y estructura de red de datos donde estos bichitos puedan vivir sin estar expuestos a los "depredadores".... por ejemplo, si mi heladera tiene la posibilidad de hacer pedidos al supermercado para reponer comestibles y "bebestibles", no tiene caso exponerla mediante un enlace IoT tipo 4G (por decir algo) sin protección y con IP públicas cuando puedo protegerla detras de un router wifi con firewall.

Opino que todas estas cosas están muy buenas (es un terrible avance tecnológico para los sistemas embebidos), pero me parece que la gente de marketing le está agregando demasiado humo a la venta.
 
...y esto es aplicable a dispositivos "IoT". Las experiencias recientes, la cada vez mas alta calidad de los atacantes y los miles de millones de equipos IoT, hay quien habla de "trillones", millones de millones de dispositivos IoT e IIoT, las cada vez mayores capacidades de los controladores usados, requieren de reducir al máximo la vulnerabilidad de sistemas embebidos. Al momento solo tengo noción de los controladores i.mx6, que tienen implementadas funciones de apoyo de la virtualización en hardware, lo que reduce la complejidad de la software. Hay quien escribe que solo el apoyo masivo de la virtualización, del aislamiento, en la hardware de un controlador permite reducir los riesgos de vulnerabilidad de los equipos IoT! es mas, como estoy seguro bien sabes, recientemente los estados unidos sufrieron graves daños debido a un atacante que uso millones de dispositivos embebidos para su ataque!

Sí... esta fresco el caso del ataque usando cámaras de video que, por sus propias necesidades (transmitir video en tiempo real), son capaces de usar ancho de banda mucho mayor que cualquier otro dispositivo en red.

Pero el rango de aplicaciones IoT es enorme, desde un termómetro remoto (un paquete cada una hora) en comparación a la cámara de seguridad.
Uno funciona con pila botón, la electrónica propia palidece frente a lo que habría que poner para tener una comunicación inalámbrica segura, y el costo se multiplicaría decenas de veces solo por conectarlo en forma segura. Quizás en el caso del termómetro ni siquiera importa que alguien pueda espiar el dato, no es información crítica.

En cambio el caso de cámara de seguridad: quiero altísima confiabilidad, buen ancho de banda, tiempo real, redundancia para que no se cuelgue nunca, no quiero que alguien desde fuera del banco pueda ver las imágenes, etc. Ahí si estoy dispuesto a invertir más para cumplir con mis requisitos.

Quiero decir, que no hay una solución que sirva para tanta diversidad de aplicaciones. Algunos serán dispositivos super-seguros, otros priorizarán poder funcionar con una pila botón, otros ni siquiera se molestan en que terceros puedan ver fácilmente la información que están enviando...

@Ardogan: Ojalá note he ofendido poniéndote a ti y a mi persona como individuos no experimentados del tema y quienes se benefician de ejemplo concretos. pero quiero responderte a tu referencia a que objetivos tengo!

Estimadísimo Hellmut, para nada!!! no logro ver de qué manera habrías podido ofenderme, faltaba más mi amigo.
Por supuesto que no tengo ninguna experiencia en estos sistemas complejos, es tan claro como el agua :D, y en verdad es la primera vez que escucho de estos esquemas super-seguros en micros ARM.

Y si digo alguna tontera estoy más que feliz de que me corrijan, qué mejor favor me podrían hacer que invertir tiempo en rectificarme u orientarme. Más que agradecido :).

Y recuerdo tu situación de otros temas que has iniciado en el foro, de allí que dije que querías ver de poner un laboratorio electrónico en casa de primera línea.

La temática de la protección de sistemas embebidos requerirá el hacer tales sistemas parte del IoT y por lo tanto la inmensa mayoría de sistemas en un futuro muy próximo tendrá que contener el apoyo de la virtualización y aislamiento.

Como ya no puedo trabajar en la industria por razones de salud y por los daños que sufrí debido a varios paros cardíacos, el estudiar, investigar y aplicar en experimentos tiene la función de mantener y recuperar mis capacidades mentales, de llenar mi vida con objetivos que me fascinen y así mantener un estilo de vida organizado. Típico alemán, según dicen!

He trabajado con alemanes alguna vez, NUNCA aprendí tanta disciplina de trabajo como entonces, filosofía de: no excusas, sin vueltas (ya viste como somos los rioplatenses), hay que aprovechar el tiempo de trabajo, buen uso de herramientas, no sacar una tuerca de 1/2" con una llave de 13mm.
¿Cometiste un error?, nadie te va a echar del trabajo por eso, somos humanos, pero tu responsabilidad profesional es aprender del error, y ver la forma de que no vuelva a pasar. Y de vuelta, sin excusas, no hay tiempo para eso ni nos interesa hacer cacería de brujas (y)

Al principio yo mismo tuve el impulso de buscar justificaciones si no lograba hacer algo de forma correcta o lo hacía fuera de tiempo, lamentablemente eso es algo que muchos latinoamericanos hacemos desde niños y casi como que es una marca cultural.
Luego decidí exponer los problemas de forma plana y simple y... una maravilla, nadie se puso a "retarme" ni nada de eso, si hay un alemán del otro lado estoy tranquilo de que traen la mentalidad de resolver problemas como una marca genética, mientras tanto aquí tenemos la cultura de la excusa (a veces justificada, pero a veces no).

Empecé con el modelismo naval y allí con la construcción y diseño del modelo de un velero. Después de varios años, en los cuales aprendí y desarrollé mis capacidades de modelismo físico, el querer realizar un sistema de control de escotas que permita operar el control de escotas y por lo tanto la posición de las velas. esto fue el punto inicial, después de aprender a realizar mis propios circuitos electrónicos, de reactivar mis capacidades de programación y de estudiar por ejemplo la funcionalidad de un motor de paso en detalle, me embarqué en la materia de modelación de partes de mi sistema de control de escotas, lo que después de varios cominos me llevo a decidirme por la software de Wolfram Software, Mathematica y SystemModeler. Mathematica me da una herramienta muy poderosa matemática que se requiere para desarrollar los algoritmos y del SystemModeler que permite modelar un sistema de multiples dominios, mecánico, eléctrico, etcétera usando el lenguaje de modelación "Modelica. Como el modelar exige el verificar la funcionalidad del modelo en comparación a la realidad física, me encontré con las técnicas de HiL y SiL, Hardware-in-the-Loop y Software-in-the-Loop"! Como estos temas aún eran muy rudimentariamente apoyados por las funcionalidades de Mathematica y SystemModeler, me decidí por usar la plataforma que mejor apoyaban estas herramientas entonces, las placas Raspi!

Sí señor, vengo siguiendo tus intereses de modelado hace un tiempo largo, y tu entusiasmo inspira a probar cosas nuevas y no quedarse con lo poco que uno sabe (o al menos cree saber).


Así me encontré con la necesidad de aprender e investigar el como usar estas placas en combinación con un PC como sistema de desarrollo. Así empecé a inestigar y experimentar este entorno, muy pronto siendo capaz de manejar las placas Raspi desde mi PC y hacerlas accesibles desde el Internet. De lo que me descuidé, por creer estar seguro debido a que mi PC con Windows siempre era en la versión mas actual y utilizando herramientas de protección. resulta que de pronto mi PC con Windows se llenaba de aplicaciones de una utilidad de Windows al punto que dejaba de ser posible el solo escribir un texto en un editor, debido a que los caracteres aparecían después de casi un minuto. Tratando de usar los caminos disponibles para reparar esto no tuve éxito. Por esta razón me decidí de actualizar mi Windows 7 Ultimate a Windows 10 Pro. esto me recuperó mi PC.

Sí, me ha pasado. En gran parte por eso ya desde 2009 nunca más utilice Windows en mis máquinas.
Y agrego más, últimamente Ubuntu me está dando demasiados dolores de cabeza, tengo que determinar aún si el problema es el usuario (yo) o el sistema, pero antes no me pasaba.

Así me decidí por estudiar Linux, el os de Raspi y de las técnicas de protección. Me metí en algo para mi nuevo y como siempre me acabó fascinando y despertando mi apetito por nuevos conocimientos! Así en algún momento me encontré con la temática de hipervisores al tratar de aprender de forma metódica el como el programar y experimentar en entornos virtuales. Cosa que descubría muchos programadores hacen para no poner en peligro la funcionalidad de su PC!

Sí, y también para poder emular distintos sistemas sobre una misma máquina. Ejemplo: programar en una máquina con Windows para el sistema iOS de Apple, o para un servidor Linux...
Pero aquí me estoy refiriendo solo a máquinas virtuales (VM) que se ejecutan arriba del sistema operativo. De hecho es normal que alguien se encargue de configurar todo el entorno de desarrollo (IDE, sistema operativo, compilador, librerías, configuración de hardware) en una unidad de disco virtual y luego trabajar todos sobre la misma máquina virtual.

Estudiando el tema de hipervisores muy pronto encontré que el procesador de mi PC efectivamente ya tenía en hardware apoyo para la virtualización. Muy pronto me encontré con que la virtualización con hipervisores y contenedores como el método establecido por centrales de cómputo, donde los clientes no reciben su servidor físico individual, sino que reciben entornos virtuales no diferenciales de sistemas físicos. Es mas, estos entornos pueden ser transferidos a otro servidor físico aún cuando tales entornos virtuales están activos.

¿No estaremos hablando de lo mismo?.
Recuerdo haber escuchado que los procesadores tenían modo supervisor y modo usuario desde los '90 (cuando yo iba a la secundaria :)). Si mal no recuerdo la idea era que había recursos (interrupciones de hardware, espacios de memoria, código de drivers) que solo queremos que los use el sistema operativo (modo supervisor) y no las aplicaciones que corren encima del sistema operativo (modo usuario).

Esto de ARM me parece que apunta a otro objetivo distinto: agregar una capa abajo del sistema operativo, ejecutar a la par todo aquello que precise respuesta en tiempo real (bare metal como con un micro pequeño), y que el sistema operativo no esté como intermediario entre el código de tiempo real y el hardware.

Y por supuesto, agregar seguridad para que una aplicación que usa el sistema operativo no pueda acceder a los recursos que usa el código de tiempo real.

Leyendo sobre los mecanismos de apoyo que la empresa ARM desarrolla para sus productos ofertados y leyendo en mayor detalle en que consisten los elementos de apoyo en Hardware para la virtualización, pude ver que estas funcionalidades desarrolladas por ARM bajo el concepto de "TrustedZone", solo son opcionales para aquellos que toman licencia de los núcleos de ARM. Entre otros, los núcleos en la nueva placa Raspi 3B, son apoyados por ARM para la implementación de funciones de apoyo de la virtualización. Pero con excepción de los controladores i.mx6 la documentación de ningún proveedor de controladores contiene referencia a estas funcionalidades. Así el articulo reverenciado al principio de esta contribución que combina TrustedZone y sistemas embebidos resaltó al punto que me decidí por publicar esto.
Creo que el tema de la reducción de la vulnerabilidad de sistemas embebidos en el ámbito del IoT usando virtualización y aislamiento es tan reciente, que todavía no existe un amplio apoyo. Pero la necesidad de volver sistemas IoT mas seguros, menos vulnerables, no permitirá sistemas IoT sin tales mecanismos. Yo creo que el futuro de sistemas embebidos en la inmensa mayoría de los casos deberán ser sistemas IoT y por lo tanto tendrán que usar estos mecanismos de protección!

Bueno, aquí es donde yo veo que tenemos opiniones distintas.
No pienso que esto sea para cualquier aplicación IoT, en los 2 casos extremos que mencioné arriba, sí puede servir para la cámara de seguridad, pero no creo que se use para un termómetro remoto barato y que funcione a pilas.

Hago una comparación burda. Una cosa es querer proteger tu Mercedes Benz ultimo modelo en Argentina y otra distinta es querer proteger la bicicleta.
Para el automóvil voy a contratar una cochera segura, poner un rastreador GPS en caso de robo, contratar auxilio mecánico en todo el país, y hacer todos los servicios de mantenimiento preventivo tal cual dice el manual.
Para la bicicleta... durante el día bien podría dejarla encadenada a un árbol a la vista de mi amigo del kiosco, y a la noche la puedo entrar a mi pequeño departamento para dejarla en la cocina poco antes de ir a dormir. Y si me la roban... no es una gran pérdida.

Las medidas de seguridad a tomar están en directa relación con el valor de la cosa protegida, y en IoT a veces hablan como si todo fuera lo mismo: no es lo mismo el control de luces que el sistema de seguridad hogareño, o el portero eléctrico, o el control climático, o incluso el control de apertura de puerta de entrada de la casa (con una smartcard o algo así).
Hay una relación costo-beneficio distinta para cada cosa, y esa es una de las dificultades a superar, porque el hardware/protocolo de comunicaciones/calidad de servicio/etc varía mucho para todo lo que se propone conectar a la red.

Bueno, me disculpo por la longitud de la respuesta, pero siempre me gusta participar cuando Hellmut escribe algo :D.

Un abrazo.
 
Hola amigos. La visita a la feria fue nuy interesante y para mi productiva. Mi pregunta inicial al contactar personas en los puestos de la feria fue:
"Que puedes contarme sobre como tu empresa ofrece servicios para reducir la vulnerabilidad de sistemas usando sus controladores en sistemas embebidos?"
Realmente, con muy pocas excepciones, las personas no tenían idea alguna de que demonios estaba hablando! Así lograba que me pusieran en contacto con la persona mas calificada, presente en la feria, para atenderme. Pero esas personas con las que fui puesto en contacto, o me respondían que no tenían nada para ese tema, cosa que es expresión de las capacidades de tal persona de lo mas elogiables, pues evita el malgastar tiempo! De las pocas empresas que si tenían noción del tema en suma funcionalidades para la visualización y seguridad, esto se veía como algo disponibles en productos de la categoría "Premium"!

Vale referenciar la informaciones disponibles en el Internet sobre los 2 nuevos productos recién publicados: ARM Cortex M23 y M33. Si miran no solo en el sitio de Internet de ARM, sino también a presentaciones de ARM sobre estos 2 nuevos miembros de sus diseños en YouTube. el "23" es un producto especializado en ofrecer un diseño lo mas pequeño posible y con el menor consumo de energía posible. Por ejemplo habla de aplicaciones sin batería, que toman la energía requerida del medio ambiente en el cual están! En inglés se habla de "Energy Harvesting". Es importante resaltar aquí que los ingenieros de ARM realizaron las funcionalidades de virtualización y protección con el foco en que estas funcionalidades requieran una ínfima cantidad del silicio. Hablan en el vídeo de que esta protección de ja de ser un "lujo" opcional, a volverse un requerimiento indispensable para sistemas conectados a la red!
El ARM Cortex M33 está dirigido a aplicaciones equivalentes a aquellas para las cuales hoy se usan ARM Cortex M3 y M4. Su implementación de los dispositivos de seguridad es mas extensa. El dicho que usan y que muy bien refleja el tema es: El elemento mas débil de una cadena define su vulnerabilidad. Vulnerabilidad y seguridad tienen que influenciar un diseño desde el primer paso! El tercer dicho es que no existe seguridad absoluta, pero que el objetivo es hacer la penetración de un atacante lo mas "cara" posible para así limitar los recursos de atacantes. Finalmente el objetivo es evitar que un sistema que ha sido penetrado exitósamente pueda servir como punto inicial de un ataque!
El "33"
Una empresa en la que me encontré con una persona muy bien informada, fue la empresa "Renesas" y aquí en especial los controladores de la familia "S7" serán objeto que permanecerán en la pantalla de mi "radar"! Los controladores son ARM Cortex M4 y las funcionalidades relevantes para reducir la vulnerabilidad están subsumadas bajo los títulos "Safety" < "Security & Encription"! La lectura sobre los mecanismos de protección son muy valiosas si se tienen ciertas informaciones generales sobre vulnerabilidades! Se habla de reducir el "área" expuesto a atacantes al mínimo posible. El documento al que me refiero con enlace en una contribución anterior me sirvió para poder adquirir una visión mas amplia que creo me capacita entender el porque de los mecanismos de protección.
Texas Instruments, Ti, me recomendó ir a cierto sitio de su sitio de Internet, cosa que haré en un futuro cercano!
Finalmente está el nuevo producto de Freescale, i.MX8. Este producto, ya primeras versiones han sido entregadas a 5 clientes escogidos, implementa las funcionalidades de protección de ARM y referencias a este producto también aparecen en el sitio de Internet del hipervisor "XEN" y el sub proyectos para sistemas embebidos tomando como ejemplo inicial su aplicación en el sector automotriz! Esta componente será hecha disponible en 2017 y recién entonces habrá acceso general a documentaciones mas específicas! Pude identificar una ex colega de "Motorola Semiconductores" que es responsable y el contacto para preguntas referentes a esta nueva familia de controladores. ARM en relación a su vídeo sobre los Cortex M23 y M33 también presenta la nueva IDE que apoya las funcionalidades específicas y habla que existe la implementación de los Cortex M23 y M33 en una placa con un FPGA y que permite estudiar y experimentar y diseñar software para estos productos.

El resultado de estas investigaciones al momento es que probablemente el controlador i.MX8 de Qualcomm, NXP, Freescale será el primer producto disponible y que Freescale lo proyecta para aplicaciones en el automóvil. Hay quien dice, que el automóvil será la aplicación móvil mas importante del mercado, mas que teléfonos y tabletas! Así iré investigando como ir preparándome para los controladores i.MX8. Por un lado me compré recién un libro sobre XEN y su uso en PCs. Allí hablan de una "Live CD" que permite experimentar con XEN sin tener que implementarlo. El libro es de 2007 y como esta area de investigación avanza a pasos agigantados en especial en sistemas embebidos, aún no he encontrado lugar de donde descargar una "Live CD" para la versión actual estable de Xen, 4.7.1. Quier empezar a "jugar" con "Xen 4.7.1" en mi PC. Por otro lado veré cuanto puedo acceder herramientas de i.MX7, pues estas tendrán cierta similitud con aquellas para i.MX8.
Finalmente voy a investigar si es posible económicamente para mi adquirir una placa con el i.MX8 cuando aparezca. La IDE de "ARM-Keil" para los controladores M23 y M33 es otro de los entornos a estudiar.
Creo que el montón de informaciones que tengo que estudiar, el montón de conceptos que tengo que conocer y la lentitud de mis estudios por mis problemas de salud le quitan la urgencia a acceder a silicio y documentación del i.MX8 antes que sea generalmente disponible!

Aquí el enlace a información sobre Xen para el sector embebido!

un enlace a un vídeo de ARM que presenta de forma muy estructurada la familia de productos ARM. Es excepcionalmente informativo y completo!
 
Última edición:
Hola amigos. Mientras lo que he estado presentando en este hilo se refiere al uso de la virtualización para crear entornos mas seguros en sistemas embebidos, ahora les quiero empezar a introducir el tema de la containerización.

Estos contenedores son una estructura informática, en la cual se mete una aplicación junto con todo el entorno requerido para su ejecución. A diferencia del concepto de la virtualización, donde se activan entornos virtuales que contienen el sistema operativo completo, los contenedores, que a primera orden se han desarrollado para los sistemas a base de Linux, solo incluyen lo requerido adicionalmente al sistema operacional padre, Linux. Eso tiene varias ventajas para el concepto de los contenedores versus el concepto de la virtualización! El uno es, que el los contenedores requieren de menos recursos físicos del sistema y el otro es que su ejecución tiene lugar con la misma eficiencia que aplicaciones ejecutadas en el sistema operacional. También resulta de gran valor, que conteniendo todo el entorno específico que la aplicación requiere, facilita el ejecutar programas en múltiples sistemas como lo hay en corporaciones. Pero muy recientemente esta estabilidad de la ejecución de aplicaciones dentro de un contenedor en los mas diversos entornos físicos, esto también esta siendo hecho disponible para los Raspis. Aquí el enlace a una página interesante en este respecto!

La aplicación, respectivamente el entorno dominante en esta área, es Docker. En su reciente versión 1.12 finalmente ha sido desarrollado su uso en entornos con controladores ARM, los x86 de 64 bits!

No quiero entrar en detalles aún, pues estoy dando una lectura intensa del primer libro de los 5 que me compré dedicados a Docker, que introduce el sistema "Docker"! Pero quiero presentar una comparación de sistemas virtuales versus contenerization:

Sistemas virtuales aíslan el entorno virtual logrando un mínimo de vulnerabilidad al precio de requerir mas recursos del sistema físico.
Sistemas de Containers son vulnerables, pero requiriendo una cantidad mucho menor de los recursos del sistema físico y su ejecución permite la realización de sistemas de tiempo real.

Como era de esperar actualmente se está trabajando en el desarrollo de sistemas híbridos para combinar las ventajas de ambos sistemas y minimizar sus desventajas! Creo que siendo disponible Docker para el Raspi con la versión Jessie se está documentando que el entorno de los Raspis juega un papel importante en el desarrollo y la experimentación de sistemas IoT!

Cuando tenga un entendimiento suficiente de si existe y si existe como implementar esto en mi placa Raspi, logrando mi objetivo de reducir la vulnerabilidad del entorno de mi laboratorio para reiniciar mis experimentos con las placas Raspi! Seguiré reportando. He descubierto un gran número de interesantes recursos alrededor de este tema que haré disponible, una vez que haya desarrollado una visión, definido mi próximos objetivos!
 
Estoy avanzando en materia de contenedores y Docker. Docker es un programa que implementa las funcionalidades de la containerización y que es aplicado en el entorno de los os Linux. El libro de la editorial packtpub.com, "Learning Docker", por lo tanto presenta exclusivamente Docker y su entorno en el os Linux. Recientemente Docker también existe para Windows 10 Pro y Enterprise, no para las otras versiones de Windows 10. Es el tremendo impacto que la containerización está teniendo en la informática que ha hecho que Microsoft haga disponible Docker para estas versiones de Windows 10! Parece que ya hay versiones de Docker para las otras versiones de Windows 10, pero aún beta!

Aquí el enlace para instalar Docker en Windows 10.
Aquí el enlace a un foro sobre Docker en Windows 10.
Aquí el enlace para instalar un contenedor en Windows 10 con la versión mas actual del lenguaje "Python. A la fecha de hoy, enero 12 del 2017 es la versión 3.6.0

Teniendo la versión actual de Docker en mi PC con Windows 10 Pro seguí el ejemplo demostrado aquí pudiendo verificar que efectivamente se crea un contenedor con Python en mi PC con Windows 10 Pro y que se ejecuta el entorno Python 3.6.0..

Así en mis estudios del libro Learning Docker iré usando Docker en mi PC para seguir los ejemplos y practicarlos. Me he decidido de imprimir para mi el libro Learning Docker, pues así me es posible estudiar y practicar mas efectivamente!

El enlace aquí parece indicar la disponibilidad de Docker dentro de un entorno virtual! Esto me suena como una implementación de lo que se denomina como objetivo hibrido, la combinación de las tecnologías de virtualización y de containerización! A ver!

Aquí otro interesante enlace para informarse sobre la tecnología de contenedores en el contexto de Docker!
 
Última edición:
En Youtube hay un tutorial muy interesante para informarse sobre la tecnología de la containerización en general y específico para Docker como entorno. De allí saqué esta imagen:

32149804371_a7fb967783_z.jpg


Me gusta como este gráfico de forma muy convincente muestra la comparación de los contenedores como se crean con la hoy dominante aplicación llamada Docker y la virtualización!

Claro esta que aquí se muestra un hipervisor bajo un os, también existe la posibilidad de ejecutar el hipervisor sin un OS, creando un entorno virtual llamado Domain0, por ejemplo aquí sería el bloque verde a la izquierda. Este os Domain0 tiene la función de manejar y configurar el hipervisor y crear entornos virtuales adicionales. Sin embargo este gráfico muestra que en el caso de la virtualización el os forma parte de cada entorno virtual que se crea, requiriendo recursos de sistema físico. En el entorno de los containers vemos que los os no forman parte del entorno que representa un contenedor como vemos en la imagen a la derecha. Lo que ocurre es que los contenedores solo incluyen aquellas funcionalidades del os y del entorno de la aplicación requeridas para poder ser ejecutado junto con la aplicación Docker! Como Docker existe en diferentes versiones de Linux y recientemente también del Mac y de Windows, ver mi contribución anterior, los contenedores así pueden ser ejecutados en cualquier entorno donde exista Docker sin requerir funcionalidades específicas. De allí resulta el beneficio que contenedores funcionan en cualquier entorno apoyado.

Otra ventaja es que las aplicaciones en contenedores son ejecutadas directamente en el sistema físico de forma equivalente a como serían ejecutados programas dentro del entorno de os, aquí caja gris! Eso significa óptimo de ejecución y la posibilidad de ejecutar programas de tiempo real.

En el entorno virtual el hipervisor crea drivers virtuales para los recursos físicos del computador, logrando así que cada entorno tenga la impresión de ser ejecutado como unico entorno del computador físico. Este requerimiento de crear entornos virtuales para el acceso a recursos físicos del computador para cada entorno virtual cuesta potencia y tiempo de reacción dificultando la ejecución de aplicaciones de tiempo real!

La ventaja del sistema de virtualización es el aislamiento total de cada entorno virtual, evitando así que atacantes puedan afectar algún recurso externo al entorno virtual correspondiente. Así por definición la virtualización ofrece la posibilidad de evitar que atacantes puedan afectar algo fuera del sistema virtual correspondiente.

En los sistemas, los llamare "docker" en minúscula de aquí en adelante, tal protección no existe. Así a primera vista el entorno virtual ofrece un máximo de invulnerabilidad posible, el entorno docker mayor potencia por ejecutar aplicaciones de forma nativa y permitir ejecución en tiempo real!

he mencionado en mi contribución anterior el tema del desarrollo de soluciones híbridas para combinar las ventajas de cada sistema y minimizar las desventajas! El reto al cual estoy expuesto resulta de mi objetivo de tener una visión completa que me permita entender y definir el como beneficiarme de estas tecnologías para lograr un máximo posible de seguridad y un mínimo posible de vulnerabilidad en mis experimentos con las placas Raspi. Resulta que el paso con el cual estas tecnologías se están desarrollando, por ejemplo que la aplicación Docker ahora es disponible en Windows 10 pro y Enterprise y que los avances en desarrollar soluciones para lograr combinar las ventajas del uso de docker con aquellas de la virtualización lo hacen muy difícil tener una visión de como operar en mis experimentos. Así por ejemplo resulta que, como describí en mi aportación anterior, Docker en Windows 10 parece ser ejecutado en un entorno virtual!

El método que persigo para poder avanzar en adquirir un entendimiento apropiado de la materia es trabajar por adquirir una visión general del impacto, las posibilidades y deficiencias de las materias que voy estudiando. Solo experimento de forma muy rudimentaria, creo tipos de "hola mundo" para verificar que entendí de que se trata!

Obviamente el tema de la seguridad, del minimizar el área de ataque al que estaría expuesto en mis experimentos esto funciona como compás en mis investigaciones! Siendo el como lograr seguridad, reducción del área expuesto usando la tecnología docker!

vídeo en Youtube me parece crucial para mi objetivo!

El mensaje de este vídeo básicamente consiste en lo siguiente:

Cada docker (container) solo contiene un proceso de la aplicación a escribir.
Cada docker solo recibe estrictamente los derechos que requiere para ejecutar su función. Esto incluye prioridad de su ejecución, limitación con cuales otros docker pueda comunicarse, definir estrictamente que tipo de datos y cuales tales comunicaciones están permitidas, a cuales recursos tiene el derecho de acceder, por ejemplo áreas de la memoria, funcionalidades periféricas, donde posible solo el derecho de leer, pero no de escribir, etcétera! El título para ello del vídeo de Youtube al que he dado el enlace lo expresa:
"Least-privilige Microservices"
El vídeo extensamente presenta los detalles para ello!

Esto significa que un objetivo de alta prioridad que me he puesto es a aprender como, donde y cuales son los privilegios asignados a un docker! Creo que con ello muy pronto podré empezar a aplicar lo que voy aprendiendo!
El otro objetivo actual que tengo es captar como es eso de combinar la virtualización con la containerización que pudiera ser ya existe en la implementación de Docker para Windows 10 Pro!
Suena de bastante alta probabilidad, pues cuando ejecuto el contenedor en Docker en Windows con Python, también se nombra la versión del Kernel de Linux. Me puedo imaginar que Docker en Windows pone las funcionalidades del núcleo de Linux usadas por Docker dentro del contenedor o en las funcionalidades del programa Docker, permitiendo así que un contenedor también pueda ser ejecutado con Docker en Windows 10!
La otra cosa que no se aún es como todo esto es en relación al entorno que basa en controladores del tipo ARM! Como he escrito anteriormente también existe Docker para el entorno Linux de controladores del tipo ARM y que esto también existe para las placas Raspi, siendo el Raspi 3B el entorno preferido!
Pero paso por paso! Primero desarrollaré mi visión de como programar usando el entorno de Docker en Windows 10, cosa que ya he verificado con la ejecución de Python dentro de un contenedor. Luego trataré de definir que tipo de procesos requiero para ejecutar programas en el entorno del Raspi para controlar por ejemplo LEDs RGB por las GPIO del raspi y desarrollar los contenedores apropiados! Que suerte que tengo de poder dedicarme a esto mientras que afuera azota el invierno con nieve, hielo, lluvias heladas y vientos huracanados!
 
Estoy tratando de adquirir una visión de como es Docker en Windows y en que se diferencia de Docker en Linux. Aquí el enlace a una búsqueda de Docker for Windows en YouTube.

El vídeo de Docker en Windows compara Docker en Windows Server 2016 con su implementación en Windows 10 Pro. De esta comparación resulta la información que las implementaciones de Docker en estos 2 entornos de Microsoft, el uno en un os der servidor y el otro en la que se denomina "cliente" son diferentes a razón de las diferencias de estos entornos.

Docker for Windows, y no pretendo que sea totalmente diferente a Docker en Linux o Mac OS, pero lo que escribo es válido para los entornos de Microsoft que soportan Docker. Docker comparte el núcleo del os sobre el cual es ejecutado en todos los contenedores, una funcionalidad que os de servidor por definición hace posible. Tal no puede ser idéntico en Windows 10 por ser su núcleo no aquel de un servidor.

Lo que aún no he captado realmente es el papel que juega la virtualización dentro del entorno de Docker en Windows.

En cierto sentido mi objetivo parece ser una hardware, probablemente un "RaspBerry Pi" versión 4, aún no existente, que implemente en hardware las funcionalidades de ARM sobre TrustZone. Allí directamente sobre la hardware ejecutaría un hipervisor sobre este un Linux como Domain0, que administraría el hipervisor. Es un Linux lo mas pequeño posible y probablemente limitado a uno de los 4 núcleos del SoC del Raspi. En los otros núcleos se ejecutarían contenedores. Estos entonces no contendrían mas que el entorno requerido para su ejecución!

Como siempre los problemas están en los detalles, por lo que sigo estudiando las materias. Como Windows 10 Pro será mi entorno para desarrollar programas/contenedores tengo que captar en detalle Docker en Windows 10 Pro, o es que debiera cambiar a Ubuntu y ejecutar Windows 10 en un contenedor?
 
Quiero darles el enlace a un artículo que habla de la librería que ARM hará públicamente disponible hacia fines de Marzo del 2017.

"Analog-EETimes" as una revista gratuita disponible "online y descargable como archivo pdf. La razón por decidirme publicarlo aquí es lo inter-dependentes que tecnologías que impactan lox sistemas conectados, "connected devices" de los diversos llamémoslo dialectos del Internet del las cosas, IoT, IIoT, vehículos autónomos.

Esta librería presentada por primera vez en la reciente feria de comunicación en Barcelona y que como escribí sera disponible de forma gratuita hacia fin de mes representa una biblioteca, como un sistema "Lego" de funcionalidades para la ejecución de la función del "aprendizaje de máquinas". Qualcomm es una de las empresas que por ejemplo aprovecha sus nuevos SoC, donde la industria de los "smartphones" busca nuevas funcionalidades para motivar al mercado continuar comprando smartphones para poder aprovechar tales funcionalidades. El mercado de los smartphones en Barcelona mostró que actualmente no hay grandes e importantes innovaciones en el mundo de estos smartphones.

Una empresa China por ejemplo presentó una aplicación ejecutable en el smartphone que puede, tomando la toma de un plato, calcular la cantidad de calorías que tal comida da al usuario. Lo que hace es aislar de la toma fotográfica del plato los diversos alimentos presentes en el plato, calcular su volumen y tomando como referencia una tabla que asocia calorías al volumen de un alimento en combinación con el volumen calculado.

Como ARM dice que su librería es ejecutable en sus núcleos usados en controladores y procesadores ARMv7 y v8 y que combina la capacidad de cálculo de la GPU en el SoC, la probabilidad de que universidades implementen esto en Raspis es muy alta.

Vale mencionar que como ya tengo ejemplar de todas las variantes de los Raspi de del A+, B+, del 2 y el 3 estoy esperando nuevas versiones de las placas Raspi que integren los mas modernos núcleos. Vale mencionar aquí que una nueva revisión del Raspi Zero ahora ya incluye WLAN y Bluetooth.

Que importante es el aspecto de diseños hechos desde un principio para implementar un mínimo área de ataque muestran las últimas revelaciones de "Wikileak"! Como ya he escrito en otra parte aquí en el foro, las leyes de Gran Bretaña ya en los años 90, exigían la disponibilidad y su revelación a sus servicios de inteligencia de puertas de "entrada" en cualquier producto producido en Gran Bretaña criptólogo. Yo aprendí esto, cuando como ingeniero de ventas para la Siemens Nixdorf desde mi puesto de trabajo en Motorola Semiconductores, administré y acompañe el proceso que se hacía para reemplazar las cartas de acceso al nuevo aeropuerto de Munich. Motorola entonces aún era líder para el diseño y producción de controladores criptólogos. También tuve el mismo honor al acompañar a personas de Siemens para la testificación de seguridad de aplicaciones. Fue muy interesante participar en reuniones en el centro de diseño de estos controladores en Ginebra. Vaya uno a conocer que formas existen para atacar física e informáticamente un controlador responsable de encriptar. Imagínense cuanto se ha avanzado en estas últimas 2 décadas!
 
Pasado mañana, si mi salud lo permite iré a la feria "Embedded World 2017" en Nurenberg. Releyendo lo escrito en este hilo vale mencionar lo siguiente:

Como escribí en Noviembre del 2016 me encontré que con la excepción de 3 empresas no tenían ni idea de que estaba hablando cuando preguntaba por TrustedZone y seguridad en las aplicaciones embebidas! En prepaación a la feria de Nurenberg este año me encuentro con que este tema ahora está full de moda! Cantidad de artículos, cantidad de literatura y publicaciones sobre el tema y en la feria se dice que tomará un muy importante papel!

No lo niego que me enorgullece de haber reconocido, antes de la mayoría de personas, la importancia de este tema! Así esta vez estoy realmente planeando las visitas que haré en la feria, asisto a un curso de las 10:00 AM por una hora sobre el tema y volveré a coleccionar buen número de placas de los diversos expositores de la feria!

Pero sigo muy intrigado de como poner las técnicas que e identificado para proteger un sistema embebido conectado al Internet y como proteger la comunicación entre tales placas y mi PC, tanto durante mis experimentos, como también desarrollando! Es lo que creo ya haber mencionado antes el tal "workflow"! Últimamente en uno de los artículos que trata de como hacer el acceso externo de "servicio" a sistemas industriales, Industry 4.0 y mantener la vulnerabilidad mínima posible! Fue otro trocito de las múltiples informaciones que voy coleccionando. Básicamente la metodología consiste en subdividir el entorno industrial en "células" para así lograr tanto el reducir el área afectado a una célula individual creando células aisladas. Adicionalmente el limitar la comunicación de algún ente individual a una dirección IP para origen y destino de cada comunicación limitando los derechos de tal ente que sea autorizado a estrictamente al acceso y a los derechos de "leer, escribir y modificar" a lo que estrictamente sea requerido para la función específica. También la comunicación de acceso a un entorno industrial ejecutando por VPN y aprovechando las posibilidades de la autorización! Finalmente crear en paralelo al entorno de ejecución del sitio industrial un "entorno de servicio" y aplicando la misma metodología a este como aquella que describí previamente.

Así el número de piezas que voy identificando y basado en el cual tendré que definir mi "flujo de trabajo" va en aumento y yo tratando de adquirir una vista completa que me permita definir mi workflow! Lo molesto es, que mi no conocimiento abaraca tanto aspectos que tienen que ver con las "piezas" relacionada a lograr un mínimo de vulnerabilidad, como a mi avanzado desconocimiento de algunos de los campos que expertos considerarían base y pre requerimiento!

Así mi plan es adquirir para mi una visión completa e ir avanzando por pasitos de lo conocido a lo nuevo! Estructura en mi proceder, eso es mi primera ambición!
 
Hola amigos. Mi endemoniada salud evitó que fuera a la "Embedded World 2017". Pero mi espectativa se ve mas que confirmada. El tema seguridad en los sistemas embebidos y conectados a la red fue el gran tema del evento.

Hoy quiero compartir con Ustedes mi proceso de implementación de mecanismos de seguridad para el entorno de mi laboratorio electrónico.

29895094226_5a3f6de915_z.jpg


Este gráfico muestra la estructura física del entorno de mi laboratorio y para los experimentos que pienso hacer para la electrónica del modelo de mi velero. La experiencia que ataques desde el Internet hicieron que mi PC se pondría inoperable es la razón por querer asegurarme que mi experimentos tendrán lugar del modo lo mas protegido posible y a la vez desarrollar la infraestructura informática que combinará el usar las posibilidades de los desarrollos mas actuales y la seguridad!

33729468036_0c4c84282c_z.jpg


Este gráfico representa mis objetivos a lograr para implementar la estructura de seguridad al entorno representado en el primer gráfico. Empiezo por el bloque celeste a la derecha:

Aquí se trata de lo que intentaré de ver si mi concepto es realizable y de empezar a usarlo como parte de mi aprendizaje!

Tengo un PC con un procesador Intel(R) Core(TM) i7 920 2.8 GHz L3 8 MB Cores=4
Windows 10 Pro con la funcionalidad de virtualización activada
18 GB de RAM
VirtualBox 5.1.18
Docker Community Edition 17.03.1-ce-win5(10743) y Powershell
PyCharm IDE 2017.1
Pyhon 3.6

La idea es crear en mi PC un entorno virtual, llamado "virtual machine". Instalar en ese entorno virtual Ubuntu y en ese Ubuntu Docker. Crear un contenedor Docker y dentro de el instalar la IDE PyCharm. Es muy posible que lo que acabo de escribir sea erróneo, pero de ese modo ir aprendiendo sobre esas herramientas y entornos creados para ver que es posible y como! También tengo la intención de instalar en ese primer contenedor Python 3.6. Si estos primeros pasos resultan la confirmación sería un "hola mundo" script en Python y ver el texto en mi pantalla!

Luego viene algo que aún me parece bastante complejo y donde me falten informaciones a aprender y es el configurar el contenedor, en entorno virtual y sus respectivos "file sistem). Se de las lecturas de mis libros sobre Docker que existe la implementación de un "filesystem" local dentro del contenedor y el de definir el "file system" de mi entorno virtual y los derechos de acceso y la limitación de las funcionalidades del programa dentro del contenedor al file system del entorno virtual. Allí vale recalcar el limitar la comunicación exclusivamente a entidades definidas por su dirección IP. O sea en un principio el que de un programita escrito en Python 3.6 y ejecutado dentro del contenedor estudiar y entender los parámetros respectivos que listan mis libros sobre Docker. Se suma a esto, que desde la versión actual de la IDE PyCharm contiene un "plugin" para Docker y toca estudiar este para poder realizar mis objetivos. Es muy oportuno, que PyCharm acabe de implementar el apoyo de Docker y el de acceder a interpretadores Python, desde el contenedor a uno externo. Espero que esto haga posible lograr mi objetivo final de conectarlo a un interpretador Python en mi placa RaspBerry Pi 3B que se encontrará en un contenedor creado con Docker en el Raspi que a su vez se encuentre en un entorno del os Raspian Jessie que es ejecutado como un "guest OS", una máquina virtual ejecutada sobre el hypervisor XON, tipo 1, ejecutado en la placa Raspi. También en el entorno de la placa Raspi 3B debe estarse ejecutando los diversos entornos bajo valores de los mismos parámetros como en mi PC para hacer efectivo tanto la autorización y las limitaciones que exclusivamente harán posible la comunicación con el ente dentro de mi PC!

La comunicación entre el PC y la placa Raspi 3B será inalámbrica (WLAN), tendra lugar dentro de un canal VPN y con el protocolo "ssh" que también efectua el control de autorización, de definición de quienes están autorizados a efectuar la comunicación y las limitaciones de funcionalidades mas estricta posible!

Como pueden ver el proceso de implementar pasito a pasito los diversos entornos, el establecer las comunicaciones y/o accesos bajo el estricto control por parámetros definidos de la forma mas estricta que me sea posible será una labor ardua, extensa y estoy seguro que muy interesante para mi! Estoy convencido, que una vez haber implementado todo, su uso repetitivo solo requerirá de un esfuerzo mínimo. es la diferencia entre aprender y usar!

Claro, resaltando que un posible atacante no va a encontrar nada de valor si hace el esfuerzo y logra penetrar, lo único que realmente justifica la labor es mi curiosidad y mi intención de realmente comprender y usar todos los recursos para hacer mis experimentos en un entorno seguro! Se, que falta el incluir el Firewall, tanto del lado del PC, como del lado del Raspi!

Pero me fascina que veo que tanto los proveedores de las herramientas de software, como aquellos del hardware están empezando a publicar y hacer disponible las funcionalidades que aspiro usar! Pero es que realmente la razón que muchos sistemas conectados a la red son fáciles de penetrar por mal uso, mal configuración de los sistemas y del valor de los parámetros usados. Realmente es así que el comprender y dominar las funcionalidades y sus respectivos parámetros es asunto complejo y fuera del alcance de un usuario normal. Frecuentemente el valor de los parámetros quedan tal cual definidos por el proveedor y demasiado fácil y obvios de adivinar. No mas hay que ver que el dialogo por emails y sistemas sociales no usan las posibilidades de encriptar! es mas, actualmente los servicios de seguridad del reino unido están exigiendo una puerta de entradas para poder "ller" comunicaciones encriptadas por "Whatsap"!
 
Actualmente estoy tratando de investigar porqué creando una máquina virtual con VirtualBox solo me ofrece esta para instalar os de 32 bits! Quiero hacer que sea Ubuntu con 64 bits. Leo que mi os, Windows 10 Pro permite los 64 bits, pero que exige tener la virtualización activada como servicio del Windows, cosa que tengo activada. Igualmente tengo activada la virtualización en el BIOS, razón por la cual los servicios de virtualización en el Windows 10 Pro mio están activadas! No quiero dejar nada por el camino sin comprenderlo en un 100% y activado.

33008704863_0e44b25d79_o.png


Leo sin embargo que mi proveedor de IDEs, Jetbrains en sus últimas 2 versiones de PyCharm, CLion e IntelliJIDEA está avanzando con prioridad el madurar su apoyo de Docker y sus contenedores. Desafortunadamente hoy mis problemas de salud han impactado fuertemente mi capacidad de estudio por lo que no he sido capaz de estudiar el material relativo al apoyo de Docker y sus contenedores como interpretadores y/o compiladores externos. Fue una de las razones por la cual adquirí la IDE PyCharm, pues permite asociar el programa que se escribe en Python ser ejecutado en un interpretador de Python externo, en mi caso disponible en Raspian en la placa Raspi, y desarrollar como si fuera local, significa en el PC.

También he notado que tengo que seguir estudiando mis libros sobre Docker para saber las funcionalidades mas avanzadas y relevantes en lo que estoy haciendo. Ayer había empezado el camino paralelo al estudio de los libros sobre Docker y su ecosistema. Quiero desarrollar mi "workflow", "flujo de trabajo" escribiendo un reporte en mi editor de LibreOffice, la alternativa gratuita a Office de Microsoft. Mi endemoniada falta de paciencia! Recién estoy empezando algo que con seguridad me tomará lo restante del año. Me refiero al entorno que presenté como gráfico en mi contribución anterior!
 
Última edición:
Todo eso esta esta muy bien pero te falta la primera y más elemental protección... crear un usuario en Win 10 sin derechos de administrador ... claro antes de ello configurar win10 para quitarle todos los espias que microsoft instala en Win10 y tienen demaciados de ellos con tremendos hollos de seguridad. Luego Renombrar la cuenta del administrador y cambiarle el password. Aunque dificil de creer este último paso mucha gente olvida hacerlo y deja abierto el camino para que un extraño trabaje con tu red como si fuera su casa.
Asi se aprovecha la elemental protección que el Windows te da. El negar accseso a los usuarios no autorizados ... te pueden tratar de hackear tu pc, pero tendran que saber tu password de administrador y tu nombre de administrador.
Luego virtual machines .... a mi me gusta la de Oracle, es gratis y transparente para todos los i/o...
Linux es muy buen sistema operativo, pero win10 ha mejorado mucho con respecto a seguridad.

Yo tengo mi red con dos niveles de protección:

Un servidor de red con Win7 en una pc no muy viejita (Dual core con 240G de ssd y 8G de RAM)
claro un modem rapido (10G) y Routers de 10GB

y un servidor de archivos con windows-NT_server (en mi viejita pentimII con 6 ssd de 540G para un total de 3T de almacenamiento) que aun con todos los hollos de seguridad que tiene, me trabaja muy bien como servidor de archivos con 4 tarjetas de red(10G), para conexión directa con mis otras computadoras y la red interna inalambrica.

Asi que si alguien penetra mi primer servidor tendra que saber las claves del segundo ...cosa casi imposible, y de alli la clave de la computadora (incluyendo las tablillas de desarroyo arduino, Rasberry Pi3 y Pics) antes de poder tener acceso a ellas.
 
Atrás
Arriba