Siempre que hablamos de seguridad en informática tenemos que recordar que algunas herramientas las terminan usando niños y que, con ellos, todavía debemos ser más cuidadosos con la gestión de datos y otros detalles.

Una opción es la táctica del avestruz: prohíbimos y nos quedamos tranquilos. Suponiendo que nos creamos que esa prohibición tiene algún efecto. Mi opinión siempre ha sido que deberíamos facilitar que los niños utilicen las aplicaciones (Siempre que tenga sentido, claro) y que sea fácil para sus padres poder controlar qué sucede con ese uso.

En todo caso, en Tech Toys And The Child Protection In The Age Of The IoT nos recuerda cómo se les ha ido la cabeza a algunos fabricantes y ponen características potencialmente peligrosas en los juguetes sin prestar mucha más atención. Y los padres las compran.

Let’s face it. Even the most powerful governments in the world are far from immune to hackers. Tell me now that you still believe that some cheap products like the internet-connected dolls and baby cams are better protected? Think again.

Hablan de la ‘internet of toys’, esto es la internet de los juguetes y los riesgos que se están asumiendo por puras estrategias que sólo se preocupan de la parte comercial.

No decimos que no haya que conectar los juguetes, o darles características que se consideran interesantes (si no, el juguete elegido será otro y ya está) pero con los niños hay que tener todavía más cuidado.

Moreover, for that alone, when dealing with children in an IoT context, their security and privacy must be your priority. In a tech toys context, the child protection must be paramount to you. You, the parent. You, the IoT maker. Right from day one.

Continúa dando algunos consejos intersantes: cifrar, compartimentalizar, proteger, no almacenar datos, actualizar, …

¡Atención!

De vez en cuando alguien se anima a preparar un resumen. A los que ya saben del tema les sirve para recordar algún aspecto en el que se habían despistado y a los que no, puede ser una buena forma de introducirlos y motivarlos.

En esta ocasión se trata de Martin Fowler y su The Basics of Web Application Security.

Interesante

Hacía tiempo que no traíamos el tema de la aleatoriedad. en Random number generator seed mistakes hablan justamente de los errores más frecuentes en este tema, aunque no desde el punto de vista de la seguridad. Más bien les preocupan los aspectos de simulación.

Una primera solución (no muy buena desde el punto de vista de la seguridad, por su predecibilidad y/o posibilidad de control externo) es usar como semilla la hora. Desde luego, no es una buena idea pedir la semilla al usuario (sin, al menos, darle unas instrucciones razonables).

Pero la cosa se complica cuando trabajamos con hilos en paralelo:

A more subtle problem I’ve seen with random number generator seeding is spawning multiple processes that each generate random numbers. In a well-intentioned attempt to give each process a unique seed, the developers ended up virtually assuring that many of the processes would have exactly the same seed.

No es una buena idea utilizar un generador aleatorio para generar las semillas, fundamentalmente porque no sería raro que se produzcan repeticiones:

Suppose you seed each process with an unsigned 16-bit integer. That means there are 65,536 possible seeds. Now suppose you launch 1,000 processes. With 65 times as many possible seeds as processes, surely every process should get its own seed, right? Not at all.

Casi siempre, lo que parece simple no lo es tanto.

El direccionamiento de un montón de cacharros siempre ha sido la ‘amenaza’ que permitía justificar el paso el ipv4 a ipv6 (aunque las necesidades venían también del uso ‘normal’ de las direcciones, que ya llevan una temporada escaseando). Sin embargo, cuandos e habla de los temas de IoT (Internet of Things) no es algo que preocupe (o parezca preocupar) demasiado a nadie: típicamente nos encontramos en redes locales, que no tienen por qué ser públicas (y casi mejor que no lo sean, visto lo visto).

En The Challenges of IoT Addressing echan un vistazo al tema, donde no hay estándares claros:

Unlike with many other IT issues, administrators don’t have clear standards or an industry-recommended approach laid out for them where device addressing is concerned.

Como decíamos arriba, no parece necesario que cada aparato tenga su dirección única, sino que debería preocuparnos más su gestión:

He does believe that “every unique thing will need its own address,” whether that’s accomplished via IPv4 or IPv6, but he said that doesn’t mean it’s an unmanageable issue.

Para no perder de vista.

Seguimos dándole vueltas al tema de la dirección IP de los dispositivos. En ¿Quién está en mi red? abordábamos el problema desde el punto de vista del escaneo de la red.

Otra posibilidad es, claro, mirar el router y mirar los dispositivos conectados.

Sin embargo, para los dispositivos que tenemos controlados (y que nos interesan más) una posibilidad puede ser establecer un registro: cuando se conectan informan de que se han conectado, su IP, y los datos que consideremos relevantes.

Seguro que hay alguna forma canónica de hacer esto (o no, porque igual lo suyo sería tener un router que nos proporcione esta información de manera conveniente -pista: que no haga falta un navegador-) pero me pareció un buen ejercicio. Descubrí Google Spreadsheets and Python y me pareció una buena forma de intentarlo: los dispositivos podrían registrar en una hoja de cálculo los datos que nos interesen. Para la instalación y configuración básica se puede seguir ese documento. Después, tenemos que hacer un programita que recabe los datos y los almacene. El mío se basa en el ejemplo que puede verse allí.

En nuestro caso, obtendremos la IP con:

def getIp():
    return([l for l in ([ip for ip in socket.gethostbyname_ex(socket.gethostname())[2] if not ip.startswith("127.")][:1], [[(s.connect(('8.8.8.8', 53)), s.getsockname()[0], s.close()) for s in [socket.socket(socket.AF_INET, socket.SOCK_DGRAM)]][0][1]]) if l][0][0])

En este caso seguimos lo que indicaban en Finding local IP addresses using Python’s stdlib, no comentaremos más.

Además guardamos el nombre de la máquina, que nos servirá para dar nombre a la pestaña de la hoja donde almacenaremos los datos:

    hostname = socket.gethostname()

Finalmente, ya sólo nos queda escribir en la hoja de cálculo:

    sheet_name = 'Registro IPs'

A continuación accedemos a la hoja de cálculo (cuidado con la gestión de credenciales, nosotros hemos almacenado en la variable client_secret el nombre del fichero donde están los datos necesarios:

    scope = ['https://spreadsheets.google.com/feeds']
    creds = ServiceAccountCredentials.from_json_keyfile_name(client_secret, scope)
    client = gspread.authorize(creds)
    
    sheet = client.open(sheet_name)

A continuación registramos la máquina. Si ya es una máquina conocida, simplemente accedemos a la pestaña correspondiente; si no, la creamos:

    try:
        worksheet = sheet.worksheet(hostname)
    except gspread.exceptions.WorksheetNotFound:
        worksheet = sheet.add_worksheet(hostname, 5, 5)

Finalmente, escribimos en la hoja, insertando una fila antes de la segunda (la idea es que la información más reciente estará arriba, más cerca para verla). Al añadir una fila tendremos un registro de conexiones.

El código (en su versión actual) se puede ver en scripts/registerIp.py.

En

podemos ver cómo se crea la pestaña y se rellenan los datos al invocar el programa.

Para mantener este registro podemos poner en /etc/rc.local una invocación al programa de manera que cuando se arranquen los distintos sistemas registren su presencia.