Primeros pasos con Omega2

Hace unos meses se anunció el proyecto de financiación de un nuevo ordenadorcito, el Omega2: $5 Linux Computer with Wi-Fi, Made for IoT. Tengo que decir que lo vi y no le presté atención, así que no participé en el proyecto. Mi hermano lo hizo y además encargó un par de cacharritos para darme uno.

Lo tengo en casa desde navidad pero hasta ahora no había tenido tiempo de escribir esta nota. En este caso lo probé y pude configurarlo con mucha rapidez. Desde el punto de vista de puesta en marcha el proyecto ha trabajado muy bien si nos olvidamos de un par de detalles que comentaremos luego: alimentamos la placa, esperamos a que arranque y crea un punto de acceso WiFi. La documentación es clara y se sigue bien. Desde cualquier otro ordenador podemos conectarnos a ese punto de acceso. Navegando desde esa red podremos conectarnos a la dirección del Omega y hacer la configuración inicial desde el navegador (o mediante ssh). Entre otras cosas le proporcionamos los datos de nuestra red WiFi y entonces se conecta. Personalmente me gusta más la configuración inicial del C.H.I.P. pero encuentro esta bastante cómoda y amigable (y mucho más que tener que buscar una pantalla a la que conectar el cacharrito, aunque sea la de la TV).

En cuanto a las pegas inciales dos, pero notables: la alimentación de la placa es a 3.3V (si compramos el ‘dock’ entonces podremos tener acceso a un puerto USB y alimentar el cacharrito desde allí, entre otras ventajas. Pero entonces hablamos de un ordenador de 20 dólares y no 5). La segunda pega es la separación de los pines: no es la estándar de una placa de prototipado así que no es posible pincharía allí y cablear, hay que poner los cables directamente a los pines (a lo mejor hay placas de prototipado con esa ditancia de pines, lo desconozco). La estoy alimentando gracias a que tenía una fuente de alimentación YwRobot.

Omega 2

Como decíamos arriba la documentación para ponerla en marcha y dar los primeros pasos está muy bien Onion Omega2 Documentation y ponerla en marcha es sencillo.

Una vez que conseguimos que arranque disponemos de un sistema funcionando que configuramos a nuestro gusto y podemos empezar a trabajar. Como punto positivo frente a otras placas nos ha parecido muy buena idea que genere su propia red y de manera simultánea pueda conectarse al router mediante interfaces virtuales. Así se pueden hacer proyectos (la documentación lo explica) para hacer un extensor de WiFi (llevar la WiFi a algún punto lejano, haciendo de repetidor), un punto de acceso, … Otro punto interesante es que utiliza LinuxWRT, con el inconveniente de tener que aprender a manejar otro gestor de paquetes, el opkg (aunque la documentación ayuda también en este aspecto).

Entramos por ssh:

El ssh en Omega 2

En cuanto al uso, tengo sentimientos enfrentados: es pequeñita, barata y sencilla de poner en marcha. Pero cuando empezamos a trabajar con el modelo básico, casi no podemos hacer nada (por falta de espacio): para empezar, hay que elegir entre tener Git o Python, porque no hay espacio libre suficiente para los dos. Podríamos aumentar el almacenamiento disponible (y hay instrucciones para ello) pero sería mejor teniendo un puerto USB para conectarlo.

Entre sus características

  • Procesador 580MHz MIPS CPU.
  • Memoria 64MB (el Omega 2+ tiene 128) y 16 Mb de almacenamiento (32 en el caso del Plus).
  • b/g/n Wi-Fi
  • Varios puertos para conectividad con diversos sistemas externos.

Tiene USB 2.0, pero sin el dock no tendremos el conector.

El tamaño es pequeñito, la mitad de lo que ocupa el C.H.I.P. aproximadamente y un poquito más que un NodeMCU.

Comparando tamaños: C.H.I.P., Omega2, NodeMCU, Arduino, Pine64, Raspberry Pi

Una cosa que me preocupaba de estos aparatitos son las prestaciones. Son bastante limitadas y he preparado una tabla para que se vea mejor. La comparación se hará con una Raspberry Pi (Model B), un C.H.I.P., una Pine 64 y también he hecho comparaciones con un PC de escritorio viejo (fecha alrededor de 2008), y mi portátil, que también tiene unos cuantos años (fecha alrededor de 2011):

Dispositivo microsegundos/iteración Nº de cores bogomips Procesador
Raspberry Pi 5.944 1 697,95 ARMv6-compatible processor rev 7 (v6l)
Omega 3 3.916 1 385,84 MIPS 24KEc V5.5
C.H.I.P. 1.125 1 1001,88 ARMv7 Processor rev 2 (v7l)
Pine 64 624 4 624 AArch64 Processor rev 4 (aarch64)
PC Escritorio 204 1 6800,56 Intel(R) Pentium(R) 4 CPU 3.40GHz
Portátil 69 2 5382,47 Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz

La conclusión para mi fue que estos cacharritos pueden cumplir un papel en muchos momentos (y lo cumplen) pero no debemos olvidar las limitaciones en cuanto a potencia, que no permitirían (aún) pensar en ellos como sustitutos de un computador de sobremesa (salvo que tengamos requisitos muy austeros).

El sistema utilizado para medir las ‘prestaciones’ es muy básico, utilicé el código que proporcionaban en Performance Comparison - C++ / Java / Python / Ruby/ Jython / JRuby / Groovy.

En esta serie hemos publicado hasta ahora:

Sobre la Raspberry no hice un primeros pasos.

Divulgación de vulnerabilidades en la industria del automóvil

Un coche Los fabricantes de automóviles han permanecido muchos años de espaldas a la informatización. Ahora empiezan a utilizarlo como argumento de ventas (esencialmente a través de sistemas de comunicación y entretenimiento) pero en medio la informatización de la instrumentación de los coches ha sido más o menos inevitable. Y la aparicion de fallos también, claro (ver Coches y ataques). La reacción de los fabricantes era, hasta hace no mucho, atacar a los investigadores pensando que así evitarían que se divulgase su conocimiento.

Por eso traemos aquí GM embraces white-hat hackers with public vulnerability disclosure program donde se decía cómo el conocido fabricante había decidido no perseguir a los investigadores que informaran sobre fallos de seguridad, mediante un programa de divulgación responsable de vulnerabilidades:

“We very highly value third-party security research,” Massimilla said. He explained that under the program, those third parties can reveal vulnerabilities they find with the guarantee that GM will work with them and not take legal action—as long as they follow the fairly straightforward guidelines posted on the program’s portal.

Almacenamiento seguro de contraseñas

Sistemas de almacenamiento Primero, que quede clara una cosa: las contraseñas no se almacenan, se almacena una transformación unidireccional que permita comprobar que la persona que la utiliza la conoce, pero que impide (en la medida de lo posible) que el que nos pudiera robar los datos los utilice de manera directa.

En Storing Passwords in a Highly Parallelized World hablan de un tema al que se le está prestando mucha atención en los últimos años: no se trata sólo de almacenar las contraseñas de manera que sean ilegibles, sino que hay que tener en cuenta los ataques que pueden sufrir si alguien consigue acceder a la información y atacarla en condiciones favorables. En ese sentido, se favorecen métodos que añaden coste computacional (cuando se trata de una sola contraseña, con la clave correcta, es un coste asumible; si se trata de hacer pruebas empieza a ser interesante desde el punto de vista defensivo):

bcrypt is a password hash. The difference to cryptographic hashes like SHA-1 is that it adds a computational cost to password hashing. In other words: it’s intentionally slow. The reasoning is that if someone steals the hashes of the passwords of your customers, it’s going to be much more expensive to compute the passwords (which are probably also the passwords to their e-mail accounts) to those hashes.

Luego habla de una competición para generar nuevos métodos de hash criptográficos y del ganador, haciendo algunas pruebas de demostración en Python:

Argon2 is a secure, memory hard password hash. It comes in two variants but for password hashing only the side-channel hardened Argon2i is relevant. On 2015-11-05, an IETF draft has been submitted in order to make it an official Internet standard ASAP.

Números aleatorios seguros en Javascript

Aleatorio Otra nota sobre números aleatorios seguros. En este caso nos avisaban en V8 Javascript Fixes (Horrible!) Random Number Generator sobre un error en la forma de generar números aleatorios en Javascript que tiene el interés de proporcionar una explicación general bastante buena, como alguien encontró el fallo al encontrar una colisión en un identificador de sesión (tan sólo un mes después de empezar) y cómo los programadores eligieron la versión incorrecta de un método que no estaba mal.

En TIFU by using Math.random() cuentan los detalles sobre la historia en primera persona. Sin olvidar que estaban utilizando un generador de números aleatorios que no era criptográfico.

De paso, podemos probar el generador de nuestro navegador en este generador de imágenes aleatorias.

Obsolescencia de algoritmos criptográficos vs realidad

 Algunos trucos para esconder programas maliciosos En SHA-1 Deprecation: No Browser Left Behind nos hablan sobre la obsolescencia del algoritmo de hash criptográfico SHA1 con algunos datos como lo que costaría hoy en día generar colisiones (recordemos que en un algoritmo de hash el poder genera un mensaje diferente que tenga el mismo ‘resumen’, esto es, encontrar colisiones es uno de los principales problemas de seguridad):

Computers keep getting faster and now SHA-1 is increasingly vulnerable to potential collision attacks. The estimate today is that it would likely cost around USD$700,000 to generate a SHA-1 collision. By 2021, the price is forecast to fall to just USD$43,000.

También hacen algunos cálculos de cuánto se utiliza su sucesor, [SHA2]/(https://en.wikipedia.org/wiki/SHA-2):

To understand the impact, we spent the last few weeks testing browser connections to CloudFlare’s network for SHA-2 support. We see approximately 1 trillion page views for more than 2.2 billion unique visitors every month, which gives us a pretty representative sample of global traffic.

Y la conclusión es que podrían utilizar este algoritmo un 98.1% de los navegadores observados por ellos que puede parecer mucho pero, en sus cuentas, deja fuera a un nada despreciable número de más de 37 millones de personas. En Estados Unidos la cosa sería un poco mejor:

The United States has 99.26% SHA-2 support, making it the 15th most modern browser market (out of more than 190 countries we saw traffic from during our test). In fact, SHA-2 support in Western Europe and North America is universally over 99%.

pero, desde luego, no el mejor de los sitios con acceso a esta tecnología (15 puesto en el ranking de navegadores más modernos).

Lamentablemente, en la cola de esta lista están algunos de los países que probablemente necesitarían tener mejores sistemas de seguridad.

Unfortunately, this list largely overlaps with lists of the poorest, most repressive, and most war torn countries in the world. In other words, after December 31st most of the encrypted web will be cut off from the most vulnerable populations of Internet users who need encryption the most.

Y, claro, esto tiene como consecuencia que sitios como Alibaba o Facebook que quieren tener clientes en esas zonas menos protegidas admitan utilizar los algorimtmos menos seguros (lo que puede afectar a todo el mundo).

For instance, Alibaba, the Chinese Internet commerce giant, supports SHA-1 fallback across many of its sites. That’s not surprising given more than 6% of their Chinese customers could not securely buy from their online store if they only supported SHA-2.

Facebook also supports SHA-1 fallback across many of their sites.

Interesante.

Condiciones de carrera

Carrera Un texto introductorio sobre las condiciones de carrera: cuando varios procesos acceden a un recurso compartido de forma que se pueden producir resultados diferentes según la temporización con que se ejecute el código. Lo cuentan en Practical Race Condition Vulnerabilities in Web Applications y me pareció un texto que valía la pena guardar por las explicaciones, ejemplos y métodos de resolución para evitar el problema.

Compartir la WiFi sin precauciones

WiFi Hace bastante tiempo solía tener mi WiFi casera abierta: pensaba que algún paseante que pudiera necesitarla le vendría bien poder conectarse un rato. La cerré por varios motivos: siempre había alguien que abusaba y se ponía a descargar utilizando mi ancho de banda y provocando molestias. El otro era una cuestión de seguridad: cuando va habiendo más dispositivos conectados en mi red, es más delicado vigilar que todo va bien y que un atacante casual (intencionado o troyanizado) no provoque un desastre.

Hace mucho menos bromeaba sobre cuánto tiempo es ‘prudente’ esperar cuando uno lllega a una casa ajena para pedir la contraseña de la WiFi sin parecer descortés.

Como visitantes, también deberíamos ser cuidadosos a la hora de conectarnos a redes extrañas, que nunca sabemos lo que puede haber entre internet y nosotros.

Por los motivos señalados arriba, me sentí muy reforzdo por No, you can’t join my wifi network Troy Hunt nos explica que no deja utilizar su WiFi a los invitados y sus motivos para ello.

La primera es que, aunque confíes en tus invitados (como personas, se entiende), no puedes confiar en que sus dispositivos sean seguros y que se comportarán adecuadamente.

That might mean as a result of introducing an infected machine into the network or picking up something unsavoury while they’re browsing around behind the confines of your firewall.

También habla de la variedad de dispositivos que tenemos hoy en día conectados a nuestra red y la información que un atacante podría obtener:

Think about what’s discoverable on your own network once a device joins it: all the devices and open ports just for a start. Your NAS, your media server, your security cameras and all manner of IoT things with nothing more than software to protect them. Just as with a corporate environment, you have to work on the assumption that any machine introduced to the network is malicious and frankly, I want to minimise that risk as far as possible.

Además nos recuerda que para visitantes casuales las conexiones móviles han evolucionado mucho y lo normal es tener buena velocidad y una tarifa con suficiente cantidad de datos para no tener que pedir prestado.

En caso de que queramos compartir la WiFi (y también es un consejo que suelo dar para pequeños negocios y sitios donde compartir la WiFi es algo que se espera), deberíamos una red para invitados en la que no haya nada que nos pueda preocupar desde el punto de vista de nuestros datos:

Of course you could always just defer to your wireless access point’s guest network (if you have that capability — and many do not), that’s what it’s designed for, right? The basic premise is that a guest network is a logically isolated network for exactly what the name suggests – giving guests access. This keeps them separated from your primary network which is a good thing, except the implementation can be kind of sucky.

Los empleados y las contraseñas

Encuestas En Half of U.S. Enterprise Employees Reuse Work-Related Passwords nos recuerdan uno de los problemas más importantes en la seguridad de las empresas: la falta de preocupación por parte de la gente que trabaja en ellas.

Se basa en una encuesta entre más de 1000 empleados de empresas en EEUU de los que casi la mitad afirmaban que re-utilizaban las contraseñas para cuentas relacionadas con el trabajo. La noticia no es negativa del todo porque en el caso de las contraseñas personales la re-utilización sube a las 2/3 partes.

A recent Ping Identity survey of more than 1,000 enterprise employees in the U.S. has found that almost half of respondents admit that they’re likely to reuse passwords for work-related accounts, and almost two-thirds reuse passwords for personal accounts.

Un 66% afirman que no las darían a cambio de nada, pero hay alrededor de un 20% que las cambiarían por dinero para la hipoteca, préstamos de estudios y otras necesidades.

And while 66 percent of respondents said they wouldn’t trade their personal email login credentials for anything, 20 percent said they would trade them for a paid mortgage or rent for one year, and 19 percent would trade them to pay off student loans or higher education tuition.

Hace algún tiempo hablábamos de encuestas similares donde la preocupación de los empleados no es suficiente cuando se trata de las contraseñas utilizadas en el trabajo (y las personales, según este estudio, todavía peor).

El juramento del programador

Teclados En Uncle Bob Proposes an Oath to Programmers justamente eso. Robert C. Martin, conocido como Uncle Bob (tío Bob) propone (traducción aproximada):

  1. No produciré código dañino
  2. El código que produzca será siempre el mejor posible. No entregaré a sabiendsas código defectuoso en su comportamiento o en su estructura.
  3. Realizaré en cada entrega una comprobación segura y repetible de que cada elemento del código hace lo que debería.
  4. Haré entregas pequeñas y frecuentes, para no obstaculizar el trabajo de otras personas.
  5. Mejoraré el código sin temor y sin descanso cada vez que sea posible. Nunca empeoraré el código.
  6. Haré todo lo posible para mantener mi productividad y la de otras personas tan alta como sea posible. No haré nada que reduzca esa productividad.
  7. Me aseguraré de forma continua que otros pueden cubrir mi trabajo y que yo puedo cubrir el suyo.
  8. Produciré estimaciones que son honestas tanto en magnitud como en precisión. No haré promesas sin certidumbre.
  9. Nunca dejaré de aprender ni de mejorar mis habilidades.

El original del juramento se puede leer en The Programmer’s Oath.

En la entrada se añden algunos comentarios recibidos en su momento en Twitter después de la publicación del juramento y se recuerda el manifiesto del software robusto The rugged manifesto sobre el que comentamos en su momento en Manifiesto del software robusto.