Detección de paso con el sensor de distancia

Después del parón del verano volvemos con un proyecto pequeñito. Después de añadir movimiento (Añadiendo movimiento: servos) descubrimos que podemos orientar la cámara en una habitación (Una cámara móvil), pero casi nunca vemos nada interesante (es difícil encontrar el momento adecuado).

Sentía curiosidad por ver cómo funcionaría un sensor de movimiento y decidí comprar un par de HC-SR04, que funcionan con ultrasonidos.

Ojos que no ven

A post shared by Fernando Tricas García (@ftricas) on

El objetivo es disparar una fotografía cuando alguien pase por delante de la cámara: para ello medimos la distancia al obstáculo que haya enfrente del sensor y cuando cambie tenemos que suponer que hay alguien o algo en la trayectoria.

Tras unas primeras pruebas con la Raspi el resultado no era satisfactorio: se obtienen medidas aproximadas (y relativamente sencillas de filtrar, eliminando los valores desvidados) pero que no resultaban apropiados para lo que teníamos pensado.
Se puede ver, por ejemplo, un tutorial en HC-SR04 Ultrasonic Range Sensor on the Raspberry Pi.

La conexión del sensor a nuestra raspi.

Probando el sensor de distancia #raspi

A post shared by Fernando Tricas García (@ftricas) on

Parece que el problema de precisión tiene que ver con la medición del tiempo (que es lo que se usa para medir la distancia con este tipo de sensores: el tiempo que tarda en ir y volver hasta el obstáculo un frente de ondas sonoras), que no es muy preciso en la Raspberry con su GNU/Linux.

Afortunamdamente, teníamos a mano un Arduino y decidimos probar si era más adecuado. Esto nos permitiría:

– Medir distancias de manera más precisa.
– Aprender a comunicar la Raspberry y el Arduino.

Y, seguramente, abrir la puerta a nuevos proyectos.

El arduino conectado al sensor:

Probando el sensor de distancia #arduino #raspi

A post shared by Fernando Tricas García (@ftricas) on

Siguiendo las pistas de HC-SR04 Ultrasonic Sensor fue fácil preparar el programita (sketch) de arduino y hacer las conexiones (se puede ver en sketch.ino en su versión actual, puede haber cambios después).

Efectivamente, la medición era mucho más precisa: de vez en cuando, manteniendo fijo el sistema hay una variación de un centímetro o dos. Pero eso no es un problema cuando tratamos de detectar la presencia de un objeto más o menos grande (como una persona) en la trayectoria porque debería haber una modificación de más de 20 cm.

Ahora había que comunicar el arduino con la Raspberry (para reaprovechar código existente y no tener que empezar de cero en el nuevo aparatito).
Parece que hay varias formas de comunicarlos: mediante un puerto serie sobre USB (Connect Raspberry Pi and Arduino with Serial USB Cable), mediante I2C (Raspberry Pi and Arduino Connected Using I2C) y mediante GPIO (Raspberry Pi and Arduino Connected Over Serial GPIO).
Elegí la primera porque me pareció la más sencilla de poner en funcionamiento (aunque no descarto probar las otras).

Lo que envía el arduino se puede leer fácilmente en la Raspberry como una entrada de texto y sólo tenemos que procesar adecuadamente:

distAnt=0
...

while 1:
	distAnt = dist
	dist = int(ser.readline().strip().strip())
	
	if abs(distAnt-dist)>10:
		print "Alert!!"

Esto es: conservamos la medición anterior (distAnt), obtenemos una nueva (dist = …) y si la diferencia es mayor que diez, lanzamos una alerta.

Como lo que queríamos hacer era una fotografía justo en ese momento, hemos reutilizado código de Una cámara en la Raspberry Pi y, siguiendo viejas costumbres, la envíamos por correo (Enviar una imagen por correo en Python).

El código puede verse en serialPicture.py.

Por la forma de enviar el mensaje esto dejaba el sistema inutilizado mucho tiempo: no podemos evitar el tiempo que consume la cámara (que no es despreciable tampoco) porque no queremos poner más de una; pero sí que podemos evitar la espera de la conexión al servidor de correo, y el envío de la imagen.
Esto lo conseguimos mediante la creación de un subproceso (ver multiprocessing) que se ocupa del envío.

camera(name,cam)
p = Process(target=mail, args=(name,who))
p.start()

Esto es, tomamos la foto y lanzamos un proceso hijo que se ocupa del envío.
No tenía experiencia con esta parte de Python y no estoy seguro de si hace falta terminar el proceso de alguna forma, pero como no hay que hacer sincronizaciones ni esperar a que termine para hacer otras cosas, parece que funciona razonablemente.

Para terminar: ninguno de los procesos es muy rápido; que nadie espere poder utilizar esto como ‘trampa’ para capturar el paso de un ave volando (o incluso un niño corriendo).

¿Qué podemos hacer ahora?
Podríamos embarcar el sensor de distancia en uno de nuestros motores (como en Una cámara móvil) y con ello hacer un ‘mapa’ de la habitación: se me ocurre que serviría para detectar cambios de otra forma diferente.
Otra cosa que se me ocurre es que, una vez que alguien o algo ha cruzado la ‘barrera’ podríamos hacer un barrido con la cámara móvil y tomar varias imágenes (o incluso grabar un vídeo; me está dando pereza, pero es algo que hay que probar).
Y, por supuesto, escuchar ideas de quien lea esto o buscarlas por ahí.
Todavía hay otro problema y es que el sensor funciona aunque no haya luz; tal vez podríamos añadir un sensor de luminosidad para evitar el disparo cuando sabemos que no se va a poder tomar una imagen (o, tal vez, iluminar la escena de alguna forma).

Anuncios

Observando ataques de fuerza bruta en SSH

Este tipo de artículos son de los que más me gustan: normalmente llevan bastante trabajo y no son suficientemente genéricos pero nos dan algunas pistas. En este caso, además, hablan del SSH que es un protocolo que si uno tiene una máquina conectada a internet es relativamenet fácil observar los intentos de bots aleatoriamente sin mucha dificultad.

En Observations from two weeks of SSH brute force attacks hablan justamente de eso.

Intentos sencillotes:

As expected, the vast majority of password-guessing attempts are quite dull, and fall into one of two categories. Firstly there are attempts with a large number of ‘poor’ passwords (e.g. “password”, “1234″, etc…) against a small number of accounts which are very likely to exist (almost always “root”, but sometimes others such as “bin”).

Algunos más sofisticados:

Secondly, there were attempts on a large number of accounts which might plausibly exist (e.g. common first names and software packages such as ‘oracle’).

Y, finalmente, otros más interesantes:

here were, however, some more interesting attempts. One category was passwords far too complicated to be in a standard password dictionary, or even found through offline-brute-force attacks on a hashed password database (e.g. “TiganilAFloriNTeleormaN”, “Fum4tulP0@t3Uc1d3R4uD3T0t!@#$%^%^&*?”, and “kx028897chebeuname+a”). The best guess is that these passwords were collected from an unhashed password database, or from a trojaned SSH server or client.

Muy interesante.

Juguetes de vigilancia

Hace algún tiempo hablábamos de Los electrodomésticos y la seguridad. Toda parte tiene su contraparte y allí veíamos como algunas cámaras y elementos de comunicación podían jugar en nuestra contra. En Toy robots can guard your home nos cuentan de un proyecto que utiliza esos juguetes para que nos sirvan como elementos de vigilancia: Robodance es la web donde se describe el proyecto.

Sensores en aplicaciones: detección de problemas y respuestas

El tema de los sensores en un mundo de datos me resulta muy interesante. Por ese motivo me interesó mucho el proyecto OWASP AppSensor Project – Detect and Respond to Attacks from Within the Application que tiene que ver con la vigilancia y aditoría. Estamos acostumbrados a que estas cosas se hacen después del desastre o, como mucho, cuando las cosas ya han pasado. Una aproximación básica sería la utilización de registros (‘logs’) para anotar cosas relevantes pero lo que parece que propone este proyecto es algún tipo de guías y referencias para incluir controles en las aplicaciones relativos a la seguridad:

The AppSensor project defines a conceptual framework and methodology that offers prescriptive guidance to implement intrusion detection and automated response into an existing application. Current efforts are underway to create the AppSensor tool which can be utilized by any existing application interested in adding detection and response capabilities.

Para leer sobre el proyecto se puede ver la AppSensor Developer Guide y [PDF] OWASP AppSensor, que es una descripción de más alto nivel.
También hay, claro, código para utilizar en nuestros propios proyectos.

Habrá que seguirles la pista.

Vigilancia en el Tibet

Ya hace un año hablábamos en Puedes estar vigilado de un presunto caso de espionaje por parte del gobierno chino a la oficina del Dalai Lama utilizando ingeniería social, troyanos y la poca preparación frente a esas cosas de los tibetanos. con una aproximación más bien técnica.

Ahora se publica (o yo me entero) una versión más ‘burocrática’ del tema en Shadows in the Cloud: Investigating Cyber Espionage 2.0 que, si no estoy equivocado, se refiere más o menos a los mismos hechos, pero no referencia al anterior. De hecho, me ha costado un poco encontrar sitios donde los relacionen como en Espionagem internacional China vs Tibet (GhostNet) e outros países.

Puedes estar vigilado

Me ha gustado mucho el artículo de Shishir Nagaraja y Ross Anderson sobre The snooping dragon: social-malware surveillance of the Tibetan movement (pdf) donde se analiza un presunto caso de espionaje por parte del gobierno chino a la oficina del Dalai Lama utilizando ingeniería social, troyanos y la poca preparación frente a esas cosas de los tibetanos.

Es muy interesante porque muestra cómo se puede lanzar un ataque de ‘baja’ tecnología, pero completamente dirigido contra alguien, para sacar partido de la información que está disponible en sus computadores; normalmente, lo que sale en los medios son los grandes ataques que ‘tumban’ un montón de computadores provocando poco más que molestias (tiempo y dinero) y pasan desapercibidas estas otras posibilidades. Son mucho menos molestas a nivel general, pero más peligrosas a nivel particular.

En el lado tibetano: información sin cifrar, tráfico sin cifrar, nada de compartimentalización (los computadores con los datos se usan para acceder a internet), gente con acceso a recursos delicados con un perfil ‘alto’ en la red, …

Como dice el artículo, ¿qué pasará cuando los ladrones normales empiecen
a utilizar estas técnicas contra empresas normales?