Mostrando entradas con la etiqueta geolocalización. Mostrar todas las entradas
Mostrando entradas con la etiqueta geolocalización. Mostrar todas las entradas

04 febrero 2014

Cómo saber qué aplicaciones te geolocalizan en IOS

A veces pasa, miras el móvil y ¡ sorpresa ! aparece el ícono de la brújula activado sin razón aparente. No estás usando el GPS, ni ninguna aplicación que a priori debería tirar del GPS.

Afortunadamente existe una forma muy sencilla en IOS para mitigar esos ataques de paranoia y descubrir qué aplicación o servicio está haciendo uso de la localización.

No hace falta hacerle un jailbreak al móvil ni instalar ninguna aplicación, el propio IOS (al menos la versión 6 y 7) tiene de serie un mecanismo para averiguar las aplicaciones que están en ese momento tirando del GPS.

Para averiguarlo, nos movemos a 'Ajustes'



Una vez ahí vamos a 'Privacidad'


Finalmente a 'Localización'


Y Si prestamos atención a la imagen podemos ver que algunas aplicaciones tienen un símbolo de brújula en diferentes colores, en esta captura lo vemos en 'Waze'.

Si vamos al detalle de la información que aparece abajo:


Podemos ver que cada color significa el momento en el que una aplicación está haciendo uso de la geolocalización, bien las últimas 24h, bien hace relativamente poco o finalmente las que estén en ese momento haciendo uso del GPS.

De esa forma, cuando veamos activa la brújula y no sepamos por qué, tenemos una forma fácil de identificar 'al culpable'
Leer más...

30 agosto 2012

Apache + mod_geoip = WIN

Personalmente, soy muy fan de la geolocalización como medida de seguridad a la hora de implementar servicios en Internet, de hecho, hace un tiempo presenté un boceto de 'GEO Ips' como herramienta para filtrar conexiones basadas en su procedencia geográfica.

Hoy voy a hablar de un módulo para Apache que, entre otras cosas, permite establecer controles de acceso basados en la procedencia de la conexión.

El objetivo es 'banear' unos cuantos países para que no puedan acceder al contenido de un servidor web.

Para ello, vamos a usar mod_geoips, creado por MaxMind, empresa muy famosa por liberar bases de datos de IPs y su procedencia geográfica.

Los ejemplos de este post se han llevado a cabo en una distribución Linux CentOS 6 pero son fácilmente adaptables a cualquier otra distribución.

Paso 1: Instalar las librerías GeoIP

# wget http://geolite.maxmind.com/download/geoip/api/c/GeoIP.tar.gz
# tar -xvzf GeoIP.tar.gz
# cd  GeoIP-1.4.8
# ./configure
# ./make
# ./make install

Con esto, habremos instalado las librerías sobre las que se apoya mod_geoips

Paso 2: Descargar la base de datos de IPs

# wget http://geolite.maxmind.com/download/geoip/database/GeoLiteCity.dat.gz
# gzip -d GeoLiteCity.dat.gz
# cp GeoLiteCity.dat /opt/

Es conveniente descargar con cierta frecuencia esta base de datos ya que se va actualizando, se puede crear un trabajo en Cron para que lo haga cada mes, por ejemplo.

Paso 3: Instalar mod_geoips

# wget http://www.maxmind.com/download/geoip/api/mod_geoip2/mod_geoip2_1.2.7.tar.gz
# tar -xvzf mod_geoip2_1.2.7.tar.gz
# cd  mod_geoip2_1.2.7
# apxs -i -a -L/usr/local/lib -I/usr/local/include -lGeoIP -c mod_geoip.c

NOTA: Para poder ejecutar el último comando es necesario tener instalado el paquete httpd-devel que provee el comando 'apxs'

Ahora, configuramos httpd.conf añadiendo lo siguiente:

<IfModule mod_geoip.c>
  GeoIPEnable On
  GeoIPDBFile /opt/GeoLiteCity.dat

</IfModule>

Paso 4: Configurar los bloqueos

Supongamos que no tenemos excesivo interés en recibir visitas desde China o Rusia en nuestro servidor web, para establecer un bloqueo a esos países, creamos un fichero .htaccess en la raíz del árbol html de nuestro servidor web de la siguiente forma:

SetEnvIf GEOIP_COUNTRY_CODE CN BlockCountry
SetEnvIf GEOIP_COUNTRY_CODE RU BlockCountry

Deny from env=BlockCountry

Y et voilà ! ya tenemos configurado nuestro servidor Apache para rechazar conexiones que provengan de China (CN) y Rusia (RU), como se puede ver, resulta muy fácil añadir mas países a la lista de 'castigados'.
Leer más...

27 octubre 2011

Gestionando, de forma artesanal, una flota de vehículos


Allá por Marzo de 2009, tenía en la cabeza reutilizar mi vieja Qtek 9100 con sus capacidades GPS y su arcaico e inestable Windows Mobile, para ejecutar una aplicación del proyecto OpenDTM/OpenGTS, a fin de enviar las coordenadas via GPS a un servicio en Internet que me permitiera saber dónde está mi coche en cada momento.

Por un lado, uno de los problemas que planteaba a nuestros lectores de aquella época, radicaba en la privacidad que ofrecían ese tipo de servicios en los que puedes enviar de forma gratuita, la posición de tu dispositivo y monitorizar si se ha llevado el coche la grúa, o algún amigo de lo ajeno. Es decir, ¿por qué el administrador, la empresa patrocinadora del servicio, o en caso de tener una seguridad deficiente, cualquiera con cierta curiosidad, pueden saber qué recorrido hago para ir a trabajar, dónde aparco todos los días o dónde he estado yo el último fin de semana?

Así pues, y como además me llamaba mucho la atención la idea, decidí montármelo yo mismo. Lo primero que elegí fue el software que iba a desplegar en casa para poder almacenar las coordenadas, así como su visualización en un mapa. El proyecto libre que más me gustó fue OpenGTS. Ahora tocaba elegir un dispositivo que fuera compatible al 100% con el proyecto y que vendieran en España. A través de la propia web, dí con el SANAV GC-101FA. En La Casa del GPS lo distribuían por unos 250 euros. Debido a que en esa época estaba potenciando un foro de coches creado por un amigo, propuse a la gente de La Casa del GPS, la posibilidad de vender un montón de ellos a los miembros de un foro y acordé un precio más conveniente con ellos. No os creáis que salió mucho más barata la broma, pero bueno. Si me roban el coche y no lo encuentro, el desembolso para hacerme con otro vehículo, seguro que es mayor.

En los estudios llevados a cabo por La Casa del GPS, el operador más rentable (en España) para utilzar con este tipo de dispositivo es Simyo. Incluso configurando el equipo para que envíe cada minuto su posición, costaba menos de 5 euros al mes hace dos años. Así pues, con la compra del GC-101FA, adquirí una tarjeta SIM de Simyo con un plan de datos. En estos dos últimos años, creo que el mes que más he pagado ha sido 3,3 euros, así que es todo correcto.

La instalación
  • Antes del do-it-yourself, probé el servicio al que tenía derecho con la compra del dispositivo y, sinceramente, amén de las trabas que hemos comentado anteriormente, la interfaz no me gustó en exceso.
  • En mi caso, la plataforma elegida fue mi CentOS Linux. Seguí los pasos dispuestos en el tutorial de instalación y configuración del proyecto OpenGTS. Me parece una tontería repetiros aquí los pasos. La documentación es bastante buena y como veréis requiere, entre otras cosas, de un servidor web Tomcat para que la aplicación funcione.
  • En mi caso, tengo Tomcat en la red interna y, para evitar publicar el servicio completo a Internet, tuve que hacer una sección en un Apache actuando como proxy inverso hacia el Tomcat cuando se llama a determinada localización. Nada que no haya explicado también otras veces en SbD.
  • El dispositivo GPS se configura, o mediante un cable USB y un software que viene con él, o mediante SMS, enviando un código de comando y determinados parámetros para que envíe la localización detectada al servidor correspondiente.
  •  Una vez que está correctamente parametrizado, las peticiones recibidas por Tomcat desde el dispositivo tienen el siguiente formato: GET /proxyquesea/Data?imei=[IMEI_del_GC-101FA]&rmc=[Posición_en_formato_$GPRC]. En este post viene explicado estupendamente los detalles del formato GPRC. Como bien podéis imaginar, si alguien falsea las peticiones conociendo las rutas y el IMEI del dispositivo GPS, podría generar posiciones aleatorias enviadas por mi coche y falsearían la posición donde se encuentra el mismo. No hay autenticación de ningún tipo en la petición; son meras GET en las que distinguimos el vehículo gracias al IMEI sumistrado como parámetro.
  • El GC-101FA trae una batería compatible con la de un móvil Nokia 8210 y tiene un par de horas de autonomía. Sin embargo, para monitorizar un vehículo en modo 24x7, es necesario suministrarle corriente de forma permanente. Así enviará la posición del mismo cada minuto sin problemas con la duración de la pequeña batería interna. Además, el dispositivo debería ir oculto dentro del vehículo, por lo que lo mejor es conectarlo a una toma de mechero del coche directamente a la batería. Otra opción es hacerlo a través de la caja de fusibles. Para ello, tomaremos la corriente mediante un fusible que sepamos que nos entrega energía de forma permanente, aunque no exista contacto bajo llave. Este es un blog de seguridad, por lo que las clases de electricidad y mecánica del automóvil, si alguien se anima y necesitáis ayuda, me lo comentáis en un correo y os explico cómo proceder para dar con un fusible válido. OJO: Añadir un dispositivo que está permanentemente conectado genera un consumo fijo esté o no el coche andando, por lo que la vida útil de la batería disminuirá. Este disclaimer tengo que ponerlo, aunque también os digo que en mi caso tengo varios cacharros conectados siempre y no he tenido problemas de momento.
  • La aplicación en el servidor Tomcat, se despliega en un fichero .war, y recibe las peticiones web del dispositivo, almacenando la información relativa a la posición enviada por el mismo en el formato GPRC (como la latitud, longitud, altitud, etc,...) en una base de datos MySQL dentro de la misma máquina (por defecto).
  • El GC-101FA es capaz de guardar además la altura a la que está el dispositivo (o en mi caso el coche). Utilidad para mí no tiene ninguna, pero siempre es interesante el poder ver de qué altura era el puerto por el que pasaste si no tienes la wikipedia a mano. Sin embargo, OpenGTS no implementaba la funcionalidad necesaria para quedarse con este dato, aunque la base de datos sí que lo contemplaba en su parámetro "altitude". Así que, ya que estaba, me pegué un rato navegando entre todo ese código Java para implementar lo necesario y poder parsear el parámetro de la altura y que lo insertara en mi base de datos también. Una vez hecho esto, lo empaqueté en un .war nuevo y lo desplegué en mi tomcat de nuevo. Las modificaciones que hice son tan complicadas como las siguientes en la aplicación gc101:
[root@Carmen gc101]# diff Data.java Data.java.orig
328d327
<         double  altitude  = isValid? StringTools.parseDouble(fld[12], 0.0) : 0.0;
364d362
<         evdb.setFieldValue(EventData.FLD_altitude    , altitude);
  • Luego, el interfaz web que proporciona OpenGTS, procesa las coordenadas GPS almacenadas, resolviendo mediante Google Apps, localizaciones entendibles por humanos (es decir, nombre de calle, número, ciudad, etc…), así como calculando la velocidad del dispositivo entre un punto y la posición anterior. Lo podéis ver en la imagen siguiente:

  • Una pena que no exista una aplicación para Iphone que permita acceder a este fantástico interfaz en tiempo real. Para casos en los que aparcas en un lugar en el que, ya sea por la grúa o los amigos de lo ajeno, puedas tener la tranquilidad que al salir de la reunión en la que estás, no tengas que volver a casa en taxi, haciendo una escala en la comisaría para denunciar un robo.
  • Así pues, ya que guardo en una base de datos de mi servidor las coordenadas e información necesaria, me decidí a implementar un sistema que, esté donde esté, pueda saber si todo sigue donde lo dejé. Para ello, aproveché el bot controlable por mensajería instantánea que utilizo para otras mil cosas como encender/apagar el aire acondicionado/calefacción de casa y/o la alarma , o para monitorizar si la roomba está limpiando, entre otras locuras,…  y le añadí una nueva funcionalidad. Ahora si, vía mensajería instantánea, a mi bot le escribo el comando "dnd N" me devuelve las N últimas posiciones registradas por el dispositivo GPS en las que ha estado mi coche. Como envía la posición cada minuto, puedo ver la posición en "formato humano" de los N últimos minutos registrados. Sorprendentemente, Google devuelve la dirección con bastante precisión.


El código perl necesario para lograr esto es el siguiente:

  if ($message =~ /^dnd/i)
  {               
        my $dbh = DBI->connect($dsn, $db_user_name, $db_password);
        my $num=1;
        if ($#fields >= 1 ) {$num=$fields[1];}
        my $tosend="";
        my $sth=$dbh->prepare("select address, deviceID,creationtime,longitude,latitude from EventData order by creationtime desc limit 0,$num");
        $sth->execute();
        my @longs,@lats;
        my $cuantos=$sth->rows;
        my $voypor=0;
        while (my ($donde,$device,$creationtime,$longitude,$latitude)=$sth->fetchrow_array())
        {
            utf8::decode($donde);
            my $dt = DateTime->from_epoch( epoch => $creationtime, time_zone => "Europe/Madrid" );
            if ($voypor > 0)
            {
                 if ( (@longs[$voypor-1] ne $longitude) && (@lats[$voypor-1] ne $latitude) ) 
                 {#No son iguales que la anterior, meto esa posicion en el array
                       my $dmy = $dt->dmy;
                       my $hms = $dt->hms;
                       $tosend.="El $dmy a las $hms el dispositivo $device estaba en $donde\n";
                       @longs[$voypor]=$longitude;
                       @lats[$voypor]=$latitude;
                 }
            }
            else
            {#Es la 0, pa dentro
                  my $dmy = $dt->dmy;
                  my $hms = $dt->hms;
                  $tosend.="El $dmy a las $hms el dispositivo $device estaba en $donde\n";
                  @longs[$voypor]=$longitude;
                  @lats[$voypor]=$latitude;
            }
      $voypor++;
    }

  • Ya puestos, por si no tengo claro dónde estoy a nivel de dirección, y ya que desde la mensajería instantánea, no puedo ver el mapa como para hacerme una idea, ideé otro mecanismo que, gracias a la API de Google, me envíe un enlace web con un mapa con las posiciones requeridas. Para eso, ejecuto el comando "dndm N" y así pido un mapa de las últimas N posiciones.



En el bot, el código necesario que tuve que hacer fue:


            
       if ($message=~ /^dndm/i)
       {#Donde con Mapa
           if ( ($cuantos > 1) && ($cuantos <= 5)) {$zoom=15;}
           elsif ( ($cuantos >5 ) && ($cuantos <= 10)) {$zoom=14;}
           elsif ( ($cuantos >10 ) && ($cuantos <= 15)) {$zoom=13;}
           elsif ( ($cuantos >15 ) && ($cuantos <= 20)) {$zoom=12;}
           elsif ( ($cuantos >20 ) && ($cuantos <= 25)) {$zoom=11;}
           else {$zoom=10;}
           my $urlbase="http://maps.google.com/maps/api/staticmap?zoom=$zoom&size=640x640&maptype=roadmap&markers=color:green";
           my $puntos; 
           for (my $i=0;$i<$cuantos;$i++)
           {
               $puntos.="|$lats[$i],$longs[$i]";
           }    
           my $url=$urlbase.$puntos."&path=color:0xff0000ff|weight:".$puntos."&sensor=true";
           my $urlapi = 'http://tinyurl.com/api-create.php?url=';
           my $ua = LWP::UserAgent->new;
           my $response = $ua->get($urlapi.$url);
           if ($response->is_success) 
           {
               $tosend.=$response->content;
           } 
           else
           { 
               $tosend.=$url;
           }
       }

  • Al pinchar en el enlace que nos envía el bot, podemos ver una representación en google maps como la siguiente:


Leer más...

12 abril 2011

Geolocalizando con precisión de cirujano!

Actualmente, y mayormente gracias a los GPSs incorporados en los dispositivos móviles, la geolocalización se encuentra de lo más extendido y natural. Incluso hay redes sociales como Foursquare o el "Yo estuve aquí" de Facebook, que reconozco haber utilizado aprovechando el GPS de mi teléfono móvil, permiten compartir todo el mundo dónde te encuentras en un momento determinado.

A nivel IP, muchas veces hemos hablado sobre las diferentes formas de explotar la rica variedad de funcionalidades y usos que nos puede dar el conocer la localización geográfica de una IP determinada. Desde poder obtener estadísticas en las que aparece una banderita con el país origen o destino; ser capaces de ofrecer un contenido en el idioma adecuado, o proveer publicidad específica para una determinada ciudad o código postal (al menos en USA). Incluso Yago desarrolló su GeoIPS para algo que me parece más que interesante desde el punto de vista de la seguridad: "Si yo vendo flores en España,  ¿en qué me puede beneficiar las visitas desde China?" Evidentemente desde el punto de vista del SEO, puede ser interesante tener enlaces desde muchos sitios y visitas desde diferentes orígenes, pero si lo que me interesa es evitar un gran porcentaje de ataques automatizados, ¿para qué permitir visitas no deseadas?

Existe varias bases de datos (como por ejemplo la de Maxmind) y servicios mejor o peor actualizados, que permiten mediante una API, consultar una IP determinada, dónde se encontraba en el momento que se registró. Aquí se cuentan direcciones IP de utilización dinámica, que muchas veces van cambiando de ciudad en ciudad, no siendo tan tan eficaz, pero que para un uso normal es más que suficiente.

Sin embargo, cuando ya parecía que estaba todo inventado al respecto, me llamó muchísimo la atención un artículo que leí en Newscientist.com en el que se explicaba magnífico trabajo realizado por Yong Wang, un ingeniero informático chino y su equipo de la Universidad de Evanston en Illinois.

La novedad es que ha diseñado un mecanismo para geolocalizar, con un error bastante bajo dentro de márgenes más que aceptables, dónde se encuentra una IP concreta.

Fundamentalmente, Wang se basa en que conoce previamente las coordenadas GPS y dirección física de más de 76000 entidades, entre Universidades y empresas, que cuentan con al menos una dirección IP fija . Así pues, crearon una base de datos con toda esta información (en el artículo denominan a cada entrada en esta base de datos "landmarks" o referencias/marcas terrestres).

Para saber a qué distancia está una IP, se suele acotar en tres fases diferentes:
  1. Se envía una serie de paquetes hacia la IP, y en base a lo que tarda en contestar se transforma en una distancia (más o menos esto vale para acotar a unos 200 kms)
  2. Después se envían paquetes a los servidores referencias de los puntos conocidos de Google Maps (imagino que sólo será a los "más cercanos" a la IP acotada anteriormente) para saber por qué routers pasan. Cuando una IP conocida y la que se pretende geolocalizar atraviesan el mismo router, se compara cuánto tardan en llegar los paquetes desde cada máquina a ese router. Así se va acotando la distancia, hasta poder acercarse a saber dónde está realmente la IP.
  3. Se repite el paso anterior pero sobre un área mucho más pequeña hasta determinar cuál de todos los servidores conocidos está más cerca del destino. Se han llegado a geolocalizar direcciones IP con una precisión de 690 metros!
Ante la evidencia científica yo expongo ciertas dudas:
  • Aunque lo dicen en el artículo, utilizando un proxy puedes evadir el sistema explicado, de manera que si sales a través de un proxy que está en otro país, engañaríamos a la mayoría de los sistemas de geolocalización. Al menos el de Google falla cuando voy a Francia y con el mismo PC en español, salgo a Internet a través de la red de mi empresa o atravesando una VPN hasta mi casa. Qué poco me gusta que Google.com me redirija a Google.fr pudiéndome llevar a Google.es a través de la VPN. Wang indica que son capaces de detectar si una máquina es un proxy o no, y mostrar un resultado nulo en vez de un falso positivo. En mi caso concreto, estoy seguro que daría un falso positivo, esté en mi oficina de París o en el salón de mi casa, puesto que el mecanismo de salida es siempre a través del mismo Squid y a través de una VPN con OpenVPN hasta la misma máquina, ya sea por red cableada en Francia como por red wireless en el salón.
  • Sigo sin tener claro, a no ser por el rigor de la prueba científica claro está, cómo es posible identificar una dirección IP con tanta precisión, en base al tiempo que demoran ciertos paquetes en llegar a un destino, siendo que la latencia dependerá del tráfico de la red, la carga de servidores, routers y balanceadores intermedios, que no siempre es la misma, máxime cuando se está hablando de direcciones IP en cualquier lugar del Mundo. De esta manera, cierto es que aunque una dirección IP sea dinámica, puede geolocalizarse igualmente sin tener que buscar en una base de datos que puede estar desactualizada, sino que la búsqueda se efectúa dinámicamente
  • Si este mecanismo de geolocalización se empezara a utilizar de forma masiva a nivel mundial, los dispositivos con IP fija que se utilizan como referencia, registrarían un incremento de tráfico de red para el que incluso puede que no estén preparados y el mecanismo, precisamente por los cambios en los tiempos de respuesta, dejarían de ser válidos.
  • Estoy completamente de acuerdo con el post de David Rubia de ALT1040 en el que se concluía que la geolocalización es algo que ha llegado a nuestras vidas para quedarse y que no es algo que simplemente pasará de moda llegado unos años dada la utilidad potencial que esto tiene.
  • Si pudiera hacerle una sugerencia al equipo de Wang, añadiría a su algoritmo de búsqueda un paso previo, que es geolocalizarlo según lo registrado en una base de datos, para hacer hincapié en servidores referencia de la zona "cercana" a lo que diga la base de datos. Dado el número de direcciones IP existentes y dado que nadie suele apagar el router en los tiempos que se corre, la probabilidad de que una dirección IP no haya cambiado de usuario, es bastante alta y puede valer como un elemento más a tener en cuenta en la ecuación para la geolocalización  
Leer más...