Aquellos que seguís este blog, seguramente habréis leido el post sobre cómo, a través del puerto paralelo de un PC, y un circuito hand-made, lograba encender y apagar mi alarma Iridium de Securitas, puenteando los botones del mando a distancia de la misma.
Hace unas semanas recibí una llamada de un comercial de Securitas, que me indicaba, como gracias a un cambio de una normativa, para que una Central de Alarmas pueda avisar a la policía en caso de detección por parte de algún sensor, es necesario que, a partir de no se qué fecha, exista una prueba fotográfica de que están robando en el recinto. Para ello, la solución que me ofrecían, era incluir cámaras, gestionadas por Securitas, que sólo se activan a través de un sensor con la alarma armada.
En general, lo que yo haga en mi casa es cosa mía, y el hecho de tener que vivir con unas cámaras que no gestiono yo (por mucho que respeten mi privacidad) apuntándome en mi propia casa, en modo Gran Hermano, no era algo que me hiciera especial ilusión, haga o no "edredoning".
A partir de ese momento, la seguridad y tranquilidad que suponía para mí, disponer de un sistema conectado a una central de alarmas profesional, dejó de ser una ventaja, por lo que, con la idea de darme de baja del servicio de mantenimiento que la mencionada compañía cobra mensualmente, pensé en reconfigurar la alarma de Securitas (de mi propiedad) para que en vez de hacer una llamada a la central en caso de aviso, lo hiciese a mi teléfono móvil. Recorrí foros y foros en los undergrounds de Internet en los que, incluso instaladores de Securitas (que funcionan como autónomos por cierto), decían que era imposible reconfigurar esa alarma para poder hacer que enviara a otro número, si no es reflasheándola con una aplicacion, privada y celosamente guardada, de Securitas.
Así pues, me dispuse a buscar una alternativa. Conjuntamente con mi amigo Juanjo, dimos con una solución. Una alarma que, mediante una configuración modular, cual estantería de Ikea, permita incluir los sensores necesarios, mandos, teclados, sirenas e interacción con dispositivos domóticos mediante X-10, acceso a un panel mediante un navegador web, etc,… La elegida fue una Visonic PowerMax Pro.
Después de una complicada instalación (no os imaginais la obra de ingeniería que he tenido que hacer para llevar un cable de red hasta donde está la centralita), la alarma ahora ocupa el sitio de la antecesora de Securitas. Sí, efectivamente, como dije antes, tiene cable de red, por tanto hay que configurar una serie de parámetros, como IP, máscara de red y gateway por defecto.
Por ser educado con la alarma, al menos durante los primeros 5 minutos, sólo me conecté al panel de control web para ver su funcionamiento. Dicho panel, quizá no tenga excesiva funcionalidad, aunque al menos permite integrar cámaras wireless, armar la alarma parcial y totalmente, desarmarla, etc,…
La verdad es que este post podría tener kilómetros de longitud explicando (una vez perdido el respeto a la alarma) las travesuras que se le hacen a cualquier cosa con RJ-45, con servicios abiertos y sobre todo un acceso web disponible. Pensaba hacerlo en un post más adelante, aunque aquí podéis ver un análisis inicial bastante interesante sobre los servicios de Powerlink2.
Sin embargo, algo que me llamó mucho la atención, fue que, una vez rellenado los datos de usuario para el acceso web, cada vez que se hace login en dicho panel, la alarma envía un correo a dicha dirección de email, indicando que ha existido un acceso. Esto me resultó raro, puesto que en ningún momento, tuve que indicar los parámetros IP de un servidor SMTP válido con el que la alarma pueda enviar estos correos. Analizando el tráfico saliente de dicha alarma, se observa que en el momento en que se produce un evento se efectúa una petición al puerto 8080 de la IP 212.179.58.186. Se trata de tráfico web en formato XML, del tipo:
[root@Carmen tmp]# tcpdump -n -i br0 host 192.168.52.200 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on br0, link-type EN10MB (Ethernet), capture size 65535 bytes -snip- E.....@.@..t..4...4.............P....x..POST /scripts/notify.php HTTP/1.1 Host: 212.179.58.186:8080 Accept: */* Content-Type: text/xml User_Agent: persist/1.0 Connection: keep-alive Content-Length: 541007890 516 999999 2 0 true
Curiosamente, la IP 212.179.58.186 pertenece a home.visonic.com, y aquí viene lo que más me preocupa, está geolocalizada en Israel.
[root@Carmen tmp]# lookupip.pl 212.179.58.186 Info about IP: 212.179.58.186 ======================== Geolocalization --------------- Country: ISRAEL Reverse resolution ------------------ 212.179.58.186 resolves as: home.visonic.com WHOIS ----- address: Petach Tikva 49170 Israel descr: BEZEQ-INTERNATIONAL e-mail: hostmaster@bezeqint.net inetnum: 212.179.58.0 - 212.179.58.255 netname: BEZEQINT-HOSTING role: BEZEQINT HOSTMASTERS TEAM
Si se sigue analizando el tráfico saliente de la centralita de la alarma, se ve que periódicamente envía paquetes web a dicha IP del tipo:
GET /scripts/update.php?serial=999999&id=power&account=007890&ver_sw=x.y.zz&ver_hw=789&ver_var=1001&upgrade_status=0&configuration_status=0 HTTP/1.1 Host: 212.179.58.186:8080 Accept: */*
Esto da la sensación que indica al fabricante qué versión de firmware tiene la alarma para ver si hay actualizaciones pendientes aplicables.
Buscando información en Internet sobre dicho direccionamiento IP, aparece un completo review de la versión anterior de Powerlink (el dispositivo que permite dotar de conexión TCP/IP al equipo) que podéis ver aquí: http://voksenlia.net/powerlink/
Analizando el tráfico, llegamos a las mismas conclusiones, en las que a ambos nos parece inadmisible que la alarma envíe un trap a una IP externa que se encargue de enviar correos de notificación.
Si alguien logra acceder a los datos almacenados en ese servidor, tendrá los accesos y eventos relevantes de todas las alarmas con interfaz powerlink del fabricante Visonic. Aunque no se guarden, simplemente los logs del servidor web utilizado, un Nginx sobre Fedora, descargado del conocido repositorio EPEL, bastará para ver la interacción de los usuarios de estas alarmas. La verdad es que no me inspira mucha confianza, la privacidad de mis datos, en un fabricante que no se molesta siquiera en quitar la página por defecto del servidor en el que está instalado.
En el caso del enlace que encontré, la versión de Powerlink anterior permitía acceso por telnet a un puerto raruno, con unas credenciales más o menos fáciles de adivinar, y modificando un fichero, se podía evitar que la conexión saliese hacia Internet y montar el sistema de forma local. He probado con mi Powerlink2, y no ha habido manera... todavía.
Así pues como no me hace ninguna gracia que los israelitas estén contando las notificaciones de cuántas veces entro al panel web, y por qué, así como otros eventos… me he ideado una forma para evitar que esto pase.
Cuento con un servidor Proxy HTTP Squid corriendo en la máquina que me da acceso a Internet, aunque en ninguna parte permite la alarma configurar parámetros de red referentes a proxy HTTP. Así que he forzado que el tráfico HTTP saliente desde la IP de la alarma, pase por el proxy de forma transparente.
Para ello, una sencilla regla IPTables que envíe todo el tráfico desde la alarma hacia la IP del fabricante en Israel, al puerto 8080, redirigido a la máquina local, al puerto donde escucha Squid:
/sbin/iptables -t nat -A PREROUTING -p tcp -m tcp -s 192.168.52.200 -d 212.179.58.186 --dport 8080 -j DNAT --to -destination 192.168.52.254:3128Luego, en la configuración del proxy, en el fichero /etc/squid/squid.conf añadí las líneas:
acl alarma src 192.168.52.200 #IP de la Alarma acl bad url_regex http://212.179.58.186:8080/scripts/notify.php http_access deny alarma bad
La solución fue efectiva, puesto que ahora, dejaron de llegarme correos cada vez que entro al panel web, y así lo reflejan los logs de Squid:
1326664189.591 180 192.168.52.200 TCP_MISS/200 272 GET http://212.179.58.186:8080/scripts/update.php? - DIRECT/212.179.58.186 text/plain 1326664310.585 208 192.168.52.200 TCP_MISS/200 272 GET http://212.179.58.186:8080/scripts/update.php? - DIRECT/212.179.58.186 text/plain 1326664431.714 186 192.168.52.200 TCP_MISS/200 272 GET http://212.179.58.186:8080/scripts/update.php? - DIRECT/212.179.58.186 text/plain 1326664475.645 0 192.168.52.200 TCP_DENIED/403 3620 POST http://212.179.58.186:8080/scripts/notify.php - NONE/- text/html
Así, me interesa que se descarguen y apliquen actualizaciones, y claramente NO me interesa que los israelitas sepan qué actividad tengo yo con mi alarma. No se lo digo a Securitas, pues menos a los de Visonic.
Me quedan más cosas por hacer con la alarma, como poder activarla y desactivarla por línea de comandos (o desde mi bot Gtalk), supliendo el hackeo directo al mando de la alarma de Securitas. Si os soy sincero, es algo que actualmente ya he logrado hacer, aunque estoy en modo pruebas, por lo que prefiero dejarlo para contároslo en otro post, más adelante.
Al final, el nuevo equipo no resulta precisamente barato, pero he calculado que en unos 10 meses de no pagar mantenimiento a Securitas por el servicio anterior, queda amortizado, por lo que me resulta hasta rentable.
Continuará….





























