Las cámaras con GPS incorporado, que cada vez son más populares, permiten grabar en el fichero de la imagen los datos de ubicación y, con un poco de habilidad, podemos crear mapas personalizados con nuestras fotos.
Esto es posible porque los ficheros de imágenes además de la información necesaria para construir la imagen sobre la pantalla contiene otra información que no tiene nada que ver con la propia imagen. A esta información se la llama metadatos. Ya vimos los metadatos en los documentos ofimáticos y como manipularlos.
Información oculta pero accesible.
Los metadatos pueden ser de tres tipos:
Identificativas: modelo, tipo.
De la foto: fecha y hora, apertura de diafragma, tiempo de exposición, datos del GPS y cualquier otra medida que haya podido tomar los sensores de la cámara
De autor. Información personalizada del autor.
Normalmente esos datos se generan de forma automática con la excepción de la información de autor que además puede ser introducida de forma manual.
Con la herramienta EXIFTOOL que esta disponible tanto para Linux como para Windows podemos ver la información contenida en los metadatos de una fotografia.
Parte de la información:
Y la parte con la información geográfico, si está presente:
La ubicación.
Los datos que nos interesan para la ubicación de las fotos son los datos del GPS, siempre y cuando la camara tenga GPS.
Pero.... ¿y si no lo tiene?
Al campo con la cámara.
Muchas veces, sobre todo entre excursionistas es fácil que se lleven ambos dispositivos: el GPS para ayudarnos en la orientación y la cámara de fotos para llevarnos a casa esos paisajes que vamos descubriendo durante la excursión.
En casa volcamos al ordenador toda la información sobre nuestra maravillosa excursión. Por un lado la fotos, por otro lado el track del GPS.
El reto es: ¿Y si pudiéramos llevar la información que hemos grabado con el GPS y llevarla a los metadatos del las fotos?.
La clave es seleccionar el registro del track que se estaba grabando cuando se hizo la foto. ¿Hay alguna información común que permita relacionar ambos sucesos?.
La hay: el momento en que se hizo la foto.
El proceso no puede ser entonces más sencillo:
Extraigo la fecha y hora de los metadatos de la foto y seleccionamos el registro del track cuya fecha hora coincida (o esté lo mas cercano posible).
Solo un pequeño requisito: la fecha y hora de la cámara debe estar puesta correctamente. No es necesario una sincronización al segundo ya que estamos tratando con información relativamente precisa.
Conceptualmente el proceso en sencillo. Una vez entendido el proceso vamos ha buscar una herramienta que nos haga este proceso.
Yo uso GPicSync que es freeware.
Simplemente hay que decirle cual es el directorio donde tenemos las fotos, cual es el fichero de track (admite ficheros Garmin y NMEA) y, opcionalmente, el nombre del fichero de Google maps si queremos que nos genere un fichero para posteriormente tratarlo con este programa.
Para este ejemplo le hemos indicado que además de georeferenciar las fotos nos genere un fichero kmz
Le damos al botón Syncronize! et voilá...
Si abrimos el fichero generado en Google Earth podemos ver el resultado:
Un poco más en profundidad.
Analicemos el log de la sincronización. Hemos sincronizado dos fotos y nos dice lo siguiente:
Starting to generate a Google Map file (doc-web.kml) in the picture folder ...
(Found 25062011080.jpg ... : WARNING: DIDN'T GEOCODE, no track point below the maximum time range ( 300 s) : 2011-06-25-14:46:46 time difference (s)= 2770
For information nearest trackpoint was at lat=40.7981159 long=-2.1545944
(Found 25062011060.jpg ...taken 2011-06-25-14:00:08, writing best latitude/longitude match to picture: N 40.7981423 ,W -2.1546282 : time difference (s)= 21
*** FINISHED GEOCODING PROCESS ***
El primer mensaje nos dice que no ha encontrado un registro de track cercano y que el más cercano está a... !2770 segundos¡.
Salvo que tengamos muy claro lo que pasó en ese momento lo más lógico sería descartar esa foto. Observemos que el tiene un tiempo de aviso de 300 segundos.
En la segundo foto nos dice que ha encontrado un registro de track a solo 26 segundos lo que es una razonable diferencia de tiempo (salvo que tiremos la foto desde un tren de Alta Velocidad)
Para aquellos que no se sientan muy cómodos con las líneas de comando indicar que este programa trae además un visor de metadatos de la foto.
También nos permite reescribir los datos para realizar ajustes sobre la información o eliminar información que no queramos que forme parte del fichero.
miércoles, 2 de enero de 2013
viernes, 23 de noviembre de 2012
Fortaleciendo un sistema Joomla
Vimos en post anteriores; Vulnerabilidades en Joomla (I) y Vulnerabilidades en Joomla (II) como detectar vulnerabilidades en un sistema Joomla.
En este post contaré las medidas que conviene tomar para tener una web joomla lo más segura posible.
Que necesitamos tener para dormir un poco tranquilos:
Copias de seguridad.
Sobra cualquier explicación de porque esta debe ser la primera medida de seguridad.
Normalmente los proveedores de alojamiento a través de sus paneles de control te permiten hacer copias de seguridad.
Se trata de herramientas muy generales y como tenemos un sitio con un sistema determinado mi consejo es usar una herramienta más específica.
Recomiendo Akeeba Backup, una de las mejores herramientas para salvaguardar sistemas Joomla. Tiene una configuración muy versátil que nos permite diversos tipos de respaldo: Completos, incrementales, sólo bases de datos, exclusión de tablas, ficheros o directorios.
Además necesitamos una herramienta que nos planifique las la realización de las copias y la descarga a otro sitio externo.
Remote Control, otro producto de Akeeba Backup realiza esta dos tareas de forma muy efectiva.
Una lista muy completa es la Jooma VEL (Vulnerability Extensión List), que siempre que se detecta una vulnerabilidad envía un correo con toda la información disponible sobre la vulnerabilidad detectada.
También debemos tomar la costumbre de consultar esta lista cuando instalemos un nueva extensión de Joomla.
Y muy importante tener claro: Desactivar una extensión no elimina los potenciales peligros que pueda tener dicha extensión.
Importante pues borrar todas aquellas extensiones que no se usen.
Hosting
Comprobar que el hosting tiene también el software actualizado: Versiones de servidor web, de php, de base de datos, del panel de control.
Comprobar que puertos y servicios presta el hosting y solicitar que se cierren todos aquellos que no usamos (si el alojamiento es compartido probablemente nos digan que no se puede).
Comprobar que las configuraciones están de acuerdo a las prácticas de seguridad.
En cierta ocasión me encontré con un Hosting que no solo tenía el puerto 3306 (standard de MySQL) sino que además la versión de MySQL estaba fuera de mantenimiento.
Si estamos en un servidor compartido la seguridad de nuestro sitio web depende además de la seguridad de las otras webs que estén en el mismo servidor y de la configuración de seguridad de la infraestructura del servidor.
A veces nos fijamos demasiado en el espacio o transferencia a la hora de contratar un hosting y olvidamos temas de seguridad.
Medidas específicas en el hosting.
Revisemos las opciones de seguridad que nos da el hosting a través de su panel de control y veamos como nos pueden ayudar: filtros, firewall, protección contra ataques DDoS, etc.
Fichero .htaccess.
Alimentar constantemente este fichero con nuevas directivas. Analizemos nuestro access log y veamos que tipos de ataques nos hacen y pongamos las medidas correcta para que queden detenidos en este nivel de seguridad.
Medidas específicas en Joomla.
Además de las medidas anteriores que son válidas para cualquier sistema hay extensiones de Joomla que nos pueden ayudar a proteger nuestra web.
Estas extensiones se ejecutan en el mismo de nivel de arquitectura y privilegio que el propio Joomla por lo que cualquier vulnerabilidad de las descritas anteriormente puede inutilizar las que hagamos dentro de Joomla.
Antes de empezar a ver que extensiones nos pueden ayudar tomemos algunas simples medidas profilácticas:
Y a continuación veremos algunas extensiones de seguridad para Joomla
Quienes tengan cierta experiencia en Joomla ya imaginarán que las extensiones de seguridad estará formada por una serie de plugins.
He aquí los plugins que recomiendo usar:
jHackGuard: Actúa como filtro para bloquear ataques de inyección, file inclusion y transversales de directorios. Es muy similar a lo que hace el .htaccess aunque más fácil de configurar. Es una extensión gratuita que ha creado SiteGround un proveedor holandés de alojamientos. Coloca un pequeño enlace en la parte inferior con un link a su web. Es posible por configuración eliminarlo.
Joomla Backend Token: Sirve para ocultar el acceso al backend. Ya sabemos que es posible acceder a formulario de acceso colocando a continuación el directorio /administrator/
Con este plugin necesitaremos además especificar un token:
Es configurable la redirección en caso de no concordar el token suministrado con el token requerido: la home de sitio, google, etc.....
Este plugin no se ha actualiza a las últimas versiones de Joomla
Login Alert. Este plugins simplemente manda un correo cuando un usuario determinado se conecta al backend. No protege de nada pero te avisa de accesos no autorizados.
Si queremos gastarnos algo de dinero podemos usar Admin Tools Profesional, del mismo equipo que ha desarrollado Akeeba Backup.
Integra tareas similares a las de los plugins descritos y muchas cosas mas.
Y para finalizar
La seguridad no es proyecto con fin definido, si no un estado. Y debemos estar siempre trabajando para que ese estado no caiga por debajo de unos umbrales mínimos de calidad.
Y siempre, el ultimo recurso: las copias de seguridad.
En un proximo post, aunque no el siguiente: Me han atacado... y ahora qué?
En este post contaré las medidas que conviene tomar para tener una web joomla lo más segura posible.
Que necesitamos tener para dormir un poco tranquilos:
- Copias de seguridad
- Versiones de los programas actualizadas.
- Calidad del hosting
- Medidas específicas de seguridad
Copias de seguridad.
Sobra cualquier explicación de porque esta debe ser la primera medida de seguridad.
Normalmente los proveedores de alojamiento a través de sus paneles de control te permiten hacer copias de seguridad.
Se trata de herramientas muy generales y como tenemos un sitio con un sistema determinado mi consejo es usar una herramienta más específica.
Recomiendo Akeeba Backup, una de las mejores herramientas para salvaguardar sistemas Joomla. Tiene una configuración muy versátil que nos permite diversos tipos de respaldo: Completos, incrementales, sólo bases de datos, exclusión de tablas, ficheros o directorios.
Además necesitamos una herramienta que nos planifique las la realización de las copias y la descarga a otro sitio externo.
Remote Control, otro producto de Akeeba Backup realiza esta dos tareas de forma muy efectiva.
Una adecuada política de copias de seguridad: tipos y periodicidad es impresencidible si queremos marcar la diferencia entre un servicio web profesional y la web hecha por el amigo de un primo que sabe hacer páginas web
Versiones de los programas actualizadas.
Es importante estar suscrito de correos relacionadas con la seguridad de los componentes que tengamos instalados en nuestra web Joomla.Una lista muy completa es la Jooma VEL (Vulnerability Extensión List), que siempre que se detecta una vulnerabilidad envía un correo con toda la información disponible sobre la vulnerabilidad detectada.
También debemos tomar la costumbre de consultar esta lista cuando instalemos un nueva extensión de Joomla.
Y muy importante tener claro: Desactivar una extensión no elimina los potenciales peligros que pueda tener dicha extensión.
Importante pues borrar todas aquellas extensiones que no se usen.
Hosting
Comprobar que el hosting tiene también el software actualizado: Versiones de servidor web, de php, de base de datos, del panel de control.
Comprobar que puertos y servicios presta el hosting y solicitar que se cierren todos aquellos que no usamos (si el alojamiento es compartido probablemente nos digan que no se puede).
Comprobar que las configuraciones están de acuerdo a las prácticas de seguridad.
En cierta ocasión me encontré con un Hosting que no solo tenía el puerto 3306 (standard de MySQL) sino que además la versión de MySQL estaba fuera de mantenimiento.
Si estamos en un servidor compartido la seguridad de nuestro sitio web depende además de la seguridad de las otras webs que estén en el mismo servidor y de la configuración de seguridad de la infraestructura del servidor.
A veces nos fijamos demasiado en el espacio o transferencia a la hora de contratar un hosting y olvidamos temas de seguridad.
Medidas específicas en el hosting.
Revisemos las opciones de seguridad que nos da el hosting a través de su panel de control y veamos como nos pueden ayudar: filtros, firewall, protección contra ataques DDoS, etc.
Fichero .htaccess.
Alimentar constantemente este fichero con nuevas directivas. Analizemos nuestro access log y veamos que tipos de ataques nos hacen y pongamos las medidas correcta para que queden detenidos en este nivel de seguridad.
Medidas específicas en Joomla.
Además de las medidas anteriores que son válidas para cualquier sistema hay extensiones de Joomla que nos pueden ayudar a proteger nuestra web.
Estas extensiones se ejecutan en el mismo de nivel de arquitectura y privilegio que el propio Joomla por lo que cualquier vulnerabilidad de las descritas anteriormente puede inutilizar las que hagamos dentro de Joomla.
Antes de empezar a ver que extensiones nos pueden ayudar tomemos algunas simples medidas profilácticas:
- Empezamos borrando ficheros inútiles como el configuration.php-dist probablemente no sea necesario volver a tirar de él.
- Comprobar los permisos de ficheros y directorios
- Saquemos del configuratión php fuera del document root.
- Cambiemos el nombre del usuario admin
Y a continuación veremos algunas extensiones de seguridad para Joomla
Quienes tengan cierta experiencia en Joomla ya imaginarán que las extensiones de seguridad estará formada por una serie de plugins.
He aquí los plugins que recomiendo usar:
jHackGuard: Actúa como filtro para bloquear ataques de inyección, file inclusion y transversales de directorios. Es muy similar a lo que hace el .htaccess aunque más fácil de configurar. Es una extensión gratuita que ha creado SiteGround un proveedor holandés de alojamientos. Coloca un pequeño enlace en la parte inferior con un link a su web. Es posible por configuración eliminarlo.
Joomla Backend Token: Sirve para ocultar el acceso al backend. Ya sabemos que es posible acceder a formulario de acceso colocando a continuación el directorio /administrator/
Con este plugin necesitaremos además especificar un token:
http://www.tusitio.com/administrator/index.php?token=xxxxx
xxxx será el número que nosotros especifiquemos.Este plugin no se ha actualiza a las últimas versiones de Joomla
Login Alert. Este plugins simplemente manda un correo cuando un usuario determinado se conecta al backend. No protege de nada pero te avisa de accesos no autorizados.
Si queremos gastarnos algo de dinero podemos usar Admin Tools Profesional, del mismo equipo que ha desarrollado Akeeba Backup.
Integra tareas similares a las de los plugins descritos y muchas cosas mas.
Y para finalizar
La seguridad no es proyecto con fin definido, si no un estado. Y debemos estar siempre trabajando para que ese estado no caiga por debajo de unos umbrales mínimos de calidad.
Y siempre, el ultimo recurso: las copias de seguridad.
En un proximo post, aunque no el siguiente: Me han atacado... y ahora qué?
sábado, 3 de noviembre de 2012
Un apóstofre (') no es una comilla (")
Me he visto en la necesidad de tener que revisar mucho en shell de Unix y he visto como muchos progamadores usan el apóstofre (') o la comilla (") indistintamente, pero no es lo mismo.
¿Cuándo usar apostrofes ('') y cuando usar comillas ("")?
Los apóstrofes nos permiten expresar cadenas de texto, por ejemplo:
echo 'hola ';
Algo más complejo:
nombre = ' Juan';
echo 'Hola ' . $nombre;
Aparecería el saludo : Hola Juan;
A ninguno se nos escapa que si ponemos:
echo 'Hola $nombre";
nos aparecerá es lo siguiente: Hola $nombre
Ahora es donde introducimos el comilla (") porque la comilla no es un simple carácter para delimitar un texto es mucho más porque lleva implícita una llamada a un parser, que no es poco.
El proceso es siguiente: se analiza carácter a carácter el texto que es tratado como literal hasta que en encuentra un nombre de variable y lo sustituye por su valor y continua el proceso hasta el final.
Entonces:
echo "Hola $nombre";
Nos dará este resultado: Hola Juan;
Variaciones (sobre un mismo string).
Con lo anteriormente visto tenemos varias posibilidades con resultados iguales.
Las tres primeras opciones dan el mismo resultado pero solamente la primera y la tercera se pueden considerar sintácticamente correctas.
La tercera hace algo sin sentido: pone al parser a analizar un cadena con un solo string. Trabajo en balde.
La cuarta daría un resultado no deseado.
De las dos correctas. ¿Hay alguna mejor que la otra?.
Dado que ambas dan el mismo resultado, lo siguiente que debemos preguntarnos es: ¿Cual tiene mejor rendimiento?.
La respuesta es fácil: Aquella que no use el parser.
Los parser son unos grandes devoradores de recursos de un sistema por lo que debemos intentar evitar su uso siempre que nos sea posible.
¿Cuándo usar apostrofes ('') y cuando usar comillas ("")?
Los apóstrofes nos permiten expresar cadenas de texto, por ejemplo:
echo 'hola ';
Algo más complejo:
nombre = ' Juan';
echo 'Hola ' . $nombre;
Aparecería el saludo : Hola Juan;
A ninguno se nos escapa que si ponemos:
echo 'Hola $nombre";
nos aparecerá es lo siguiente: Hola $nombre
Ahora es donde introducimos el comilla (") porque la comilla no es un simple carácter para delimitar un texto es mucho más porque lleva implícita una llamada a un parser, que no es poco.
El proceso es siguiente: se analiza carácter a carácter el texto que es tratado como literal hasta que en encuentra un nombre de variable y lo sustituye por su valor y continua el proceso hasta el final.
Entonces:
echo "Hola $nombre";
Nos dará este resultado: Hola Juan;
Variaciones (sobre un mismo string).
Con lo anteriormente visto tenemos varias posibilidades con resultados iguales.
- echo "Hola $Juan"
- echo "Hola" $Juan
- echo 'Hola' $Juan
- echo 'Hola $Juan'
Las tres primeras opciones dan el mismo resultado pero solamente la primera y la tercera se pueden considerar sintácticamente correctas.
La tercera hace algo sin sentido: pone al parser a analizar un cadena con un solo string. Trabajo en balde.
La cuarta daría un resultado no deseado.
De las dos correctas. ¿Hay alguna mejor que la otra?.
Dado que ambas dan el mismo resultado, lo siguiente que debemos preguntarnos es: ¿Cual tiene mejor rendimiento?.
La respuesta es fácil: Aquella que no use el parser.
Los parser son unos grandes devoradores de recursos de un sistema por lo que debemos intentar evitar su uso siempre que nos sea posible.
Suscribirse a:
Entradas (Atom)