Análisis de equipos NAS comerciales y libres

El verano es la época del año en la que, por contar con más tiempo libre, solemos aprovechar para hacer un flush a aquellas tareas que suelen encontrarse en los To Do de cada uno. Que si pintar la casa, ordenar los armarios, organizar la colección de discos, de libros, de sellos, etc… o en caso de un informático, migrar el servidor de versión de sistema operativo o de darle una pensada a cómo mejorar la red de casa.

En mi caso ha tocado cambiar la máquina que tenía con CentOS 4.X a CentOS 6 en un equipo más moderno. Además he decidido unificar todos los contenidos que tengo en discos duros, DVDs y CDs sueltos a un sistema centralizado y compartido de almacenamiento: un NAS o Network-Attached Storage.

Ya hemos hablado en SbD sobre buenas prácticas para garantizar la diponibilidad de un sistema y por supuesto, hacer backups es algo que a todos, en más de una ocasión, nos ha hecho resoplar de tranquilidad tras una hecatombe. En el caso de los NAS, su utilidad está clara. Aparte de ofrecer espacio de almacenamiento masivo para contenidos digitales, puede ser utilizado para guardar remotamente nuestros backups, ya sean copias frías, incrementales, diferenciales o simplemente como repositorios de gran capacidad para redundar nuestros datos.

Buscando por diferentes tiendas en Internet, la oferta es muy variada: desde equipos de una sola bahía, más bien considerados discos duros de red, hasta "filers" de varias bahías. Para un uso casero, suele ser suficiente un equipo con un par de bahías capaz de de expandirse hasta unos 3 ó 4 TB. Estos dispositivos, suelen distinguirse por su sencillez, formados por una placa base y un procesador de muy bajo consumo, así como poca memoria RAM. Pensemos que la idea es tener un equipo disponible 24x7 para poder servir películas o música (por supuesto todo comprado legalmente, faltaría más!) a través de la red de casa.

Los fabricantes más reputados de este tipo de equipos para el mercado SOHO, por lo que he visto, son Synology, QNAP y Thecus, ditinguiéndose estos por proporcionar, además de recursos de almacenamiento, otro tipo de servicios como clientes P2P, servidores web y hasta de base de datos, así como cuidadas interfaces de configuración, en equipos de bajo consumo y sonoridad, si se comparan con PCs convencionales. Si bien éstos suelen ser más caros (desde unos 200 euros sin discos), comparados con los que encontramos en la siguiente línea: D-Link o Netgear, que tienen menos funcionalidades, pero cumplen con el objetivo de compartir recursos de almacenamiento a través de una red. Éstos son más baratos (desde unos 90 euros) y por lo que he leído, la sensación es de ser más "plasticoso" o peor calidad, así como un rendimiento bastante más bajo en las comparativas. La causa de este "bajo" rendimiento suele ser los procesadores Atom de entre 500-800 Mhz y 64-128 MB de RAM en los NAS de gama más baja o "algo mejor" con los procesadores de 1,2 Ghz y 256 MB de RAM de los de primera división.

En mi caso que soy bastante meticuloso, tanto con rendimiento, ruido, posibilidades de expansión y en una buena medida también el consumo del dispositivo, he decidido crear mi propio NAS re-aprovechando el equipo Core 2 Duo con 4 GB de RAM que en el que tenía el anterior servidor. Sinceramente, lo primero que se me ocurrió fue, instalo una distribución mínima de Linux, quito todos los servicios que no voy a utilizar, monto SAMBA y a correr. Sin embargo, encontré varios proyectos libres pensados y diseñados para ofrecer el servicio de NAS. Los dos más conocidos que te permiten montar tu propio NAS son FreeNAS y Openfiler.

Para mis pruebas, descargué las imágenes de instalación de ambas soluciones y creé dos máquinas virtuales en Parallels para Mac. Cada máquina virtual tiene un disco de instalación de sistema operativo de NAS (el tamaño depende de la solución a probar) y tres discos de 1 GB cada uno para definir "recursos compartidos". Aquí os cuento mis conclusiones de ambas.

FreeNAS 8

• Basado en FreeBSD
• Se instala en Compact Flash o pendrive USB (se puede instalar en un disco, pero ocupa poco y el resto del disco no puede utilizarse para almacenar datos), consumiendo muy pocos recursos.
• Kernel muy optimizado y se nota muy ágil.
• Se crean volúmenes en base a discos físicos y se configura el tipo de sistema de ficheros UFS o ZFS, con posibilidades de Mirroring, Stripping y/o RAID-Z
• Creación de recursos compartidos como Apple (AFP), UNIX (NFS) y Windows (CIFS).
• Excelente compatibilidad con Time Machine de Apple. Si bien es verdad, echo de menos poder definir un límite de tamaño máximo para un recurso definido. He leido que hay que hacerlo a nivel de sistema de ficheros en /etc/fstab configurando un tamaño máximo por cada usuario.
• Permite configurar interfaces bonding o teaming, de manera que se pueda hacer LAGG (Link AGGregation), permitiendo aumentar el ancho de banda disponible y además mejoramos la tolerancia a fallos en caso que un interfaz de red o un cable falle.
• Excelente interfaz de administración web. Muy buenas capacidades de gestión de permisos, usuarios y grupos. Asimismo, permite de una forma fácil el exportar/importar la configuración global del sistema. Muestra en un dashboard diferentes estadísticas de ocupación de CPU, memoria y disco de la máquina.

• Permite integración con repositorios externos de usuarios: LDAP o Directorio Activo. De esta manera se puede otorgar permisos de lectura/escritura a usuarios y grupos que pertenecen a repositorios externos, sin tener que definir usuarios locales.
• Servicios añadidos como SNMP y SMART para monitorización y notificación mediante traps de alarmas producidas por el sistema a un servidor SNMP (y permitir consultas bastante detalladas del estado del sistema), así como tests SMART a los discos, notificando (se supone) en caso de fallo.
• Existe una aplicación para iPhone llamada mFreeNAS que es válida, al menos para FreeNAS 7. Desconozco si para FreeNAS 8 seguirá siendo compatible.

Openfiler

• Basado en Linux, yo diría que la última versión deriva de RHEL/CentOS 6 (por  el kernel 2.6.32-71.18.1.el6) y la forma típica de arranque de CentOS/RHEL/Fedora.
• Se puede instalar en uno de los discos integrados en la máquina y compartir el resto.
• Requiere al menos 8 GB de tamaño en disco para el sistema operativo y 2 GB para Swap. Hay alternativas de sistemas Linux más reducidos. 
• En Parallels, donde yo hice mis primeras pruebas, (estoy en Portugal de vacaciones y no tengo acceso a pruebas con máquinas físicas), no me detecta los discos definidos para los volúmenes. Inicialmente los definí como SATA y no los reconocía. Luego probé como SCSI y tampoco. Posiblemente sea algún problema en la emulación.
• He buscado referencias para configurar recursos AFP a compartir en sistemas operativos Apple, pero los resultados han sido que se iba a incluir en el roadmap, pero luego se desestimó el hacerlo. Para mí esto es un show stopper y paré de mirar. Realmente FreeNAS ya cumple mis espectativas suficientemente.

Conclusiones: 

• Está bien claro, en mi caso, probaré con FreeNAS. Me ha dado el mejor feeling hasta ahora.
• Utilizaré la máquina que tenía anteriormente: Un Intel Core 2 Duo a 1,8 Ghz y 4 GB RAM con tarjeta de red Gigabit. Tengo claro que por problemas de rendimiento no va a ser. Monitorizaré el consumo con la factura de la luz y en caso que éste se dispare o que el ruido del ventilador de la máquina se escuche demasiado, me plantearé la compra de un barebone con mecanismos de refrigeración pasiva y con un menor consumo/potencia (Una vez movidos todos los datos, no será tanta la necesidad de procesamiento).
• Entre comprar un NAS ya hecho y hacértelo a tu gusto, además hay que contar como punto positivo que en caso de que la capacidad de los discos SATA que dispongo no sean suficientes, aún quedan otras dos interfaces SATA en la placa base para añadir más discos y definir nuevos volúmenes y recursos compartidos.

Leer más...

Android y el uso de la SD Card

No llevo mucho tiempo manejando Android pero la verdad es que la facilidad con la que una aplicación puede hacer más de lo que dice me está sorprendiendo... No es nada raro descargarse aplicaciones que no provienen de fuentes "de confianza", y viendo el nulo control que hay en el Market por parte de Google (ver 'La cruda realidad del Market de Android'), puedes llevarte una sorpresa.

Dejando de lado las posibles técnicas para saltarse los permisos que el usuario otorga (más bien acepta) a la aplicación, me gustaría hacer hincapié en algo mucho más simple, lo que todos pueden ver pero que no debería ser público, el típico 'read4all'.

Cuando instalamos una aplicación se nos muestran unos permisos que tenemos que aceptar. En el blog El Android Libre tenéis un artículo en el que se explica cada uno de ellos. Estos permisos delimitan bastante las capacidades de las aplicaciones pero, ¿son suficientes?.

Voy a poner un par de ejemplos en los que los permisos igual no son lo suficientemente restrictivos:

1. Tu información personal – Leer datos de contacto

Cuando estaba realizando la aplicación QuoteIt me sorprendió que el permiso fuera tan genérico, pudiendo acceder a todos los datos de cualquier contacto. Si la aplicación solo necesita el email de los contactos, ¿por qué debería tener acceso también a su dirección, teléfono, etc? Creo que se debería mantener el permiso global pero crear subpermisos para que podamos controlar algo más a qué datos accede la aplicación.

2. Almacenamiento – modificar/borrar archivos en SD

Al igual que hay un permiso para poder escribir en 'sdcard', ¿por qué no lo hay para la lectura?. Como veremos más tarde, hay demasiada información delicada almacenada en 'sdcard' como para que no haya un control de qué aplicaciones pueden acceder a ella.

3. Comunicación de red – acceso íntegro a Internet

Al igual que en el primer ejemplo, programando QuoteIt Slim me sorprendió que la ejecución de comandos no necesitara declaración de permisos de seguridad. Es cierto que los comandos disponibles permiten hacer muy pocas cosas pero sigue siendo un problema. En la RootedCON 2011, Francisco Jesús Gómez y Carlos Juan Diaz ('Cloud Malware Distribution: DNS will be your friend') comentaron como era posible almacenar y distribuir malware a través de la infraestructura de servidores DNS Caché públicos de Internet. Relacionado con este tema, puesto que una aplicación no necesita ningún permiso para realizar un ping por consola, podría aprovecharse de este método para controlar la aplicación u obtener información del dispositivo de forma transparente.

Vistos estos tres ejemplos, ahora toca profundizar un poco más con el tema del 'read4all' y la 'sdcard'.

El problema, a parte de lo ya comentado anteriormente, creo que se encuentra en el uso que hacen las aplicaciones de la SD. Entiendo que en él se almacene información que pueda resultarle util al usuario cuando conecta el teléfono al ordenador en modo USB, pero ¿es recomendable sabiendo que cualquiera puede acceder a esos datos?. ¡Las fotos sí pero mis conversaciones de WhatsApp no!

Alguna de la información que se almacena en la SD (p.e de las aplicaciones que tengo instaladas en mi teléfono):

1. La cache de la aplicación de Tuenti.

2. Fotos y videos de la cámara (y capturas de pantalla).

3. Descargas realizadas.

4. Titanium Backup.

5. Backup Dolphin HD

6. Databases (automáticas) de WhatsApp

7. Caché de Dropbox.

Como ya he dicho, hay algunas que entiendo que estén ahí almacenadas pero, ¿la caché de Tuenti?, ¿backups sin proteger?, ¿la caché de Dropbox?, etc. Con respecto a los backups, Titanium debería de protegerlos pues es un peligro que cualquier aplicación pueda acceder a esos archivos, el de Dolphin HD no se genera salvo que el usuario lo haga manualmente por lo que si se hace, hay que retirarlo lo antes posible (puedes tener credenciales almacenadas, etc) aunque todos los backups deberían protegerse. Con respecto a WhatsApp, ahora las bases de datos ya están cifradas (aunque desconozco lo seguro que pueda ser) aunque por ese mismo motivo, como el usuario no puede acceder a su contenido, no veo comprensible que estén ahí. Finalmente, lo que más me sorprendió es la carpeta Dropbox que contiene todos los archivos que hayas visualizado... (desde la aplicación puedes borrar la caché)

Como véis, si las aplicaciones utilizan la SD para almacenar información sensible sin proteger, cualquier aplicación podrá acceder a ella sin problemas. Sobretodo hay que tener cuidado con el tema de backups, como el caso de Titanium.

-------------------------

Artículo cortesía de Luis Delgado

Leer más...

Buenas prácticas garantizando la disponibilidad de un sistema

Una de las características más importantes a garantizar en un sistema es su disponibilidad. En caso de que tengamos un fallo (hardware, software, involuntario o premeditado por otras partes) que inutilice parte o la totalidad de los datos que se encuentran en el sistema, deberemos disponer de mecanismos que nos permitan restaurar el servicio lo antes y mejor posible.

Creo que en SbD, no hemos tocado de una forma frontal y directa, una de las prácticas de mantenimiento más importantes que se deben llevar a cabo como parte de la vida de un sistema.

Por ello me gustaría dar ciertas pautas sobre qué puede hacer por nosotros una buena política de backups:

• RAID: Desde el punto de vista de los discos duros, el RAID 1 es la disposición en la que más espacio de almacenamiento se desperdicia, pero también es el que mayor disponibilidad ofrece. Si alguno de los dos discos del RAID se muere, el otro tiene toda la información actualizada hasta el momento final. Otra alternativa comúnmente utilizada y bastante eficiente es RAID 5.

• Redundancia: El servicio ofrecido en sí debe estar ofrecido por dos o varios nodos de cada dispositivo en lo que se conoce como un clúster. De esta manera, si un nodo de cualquier parte de un sistema deja de estar operativo, el/los otro/s siguen haciendo la misma función. Asimismo, es una buena medida, redundar el propio servicio en sí en otra ubicación geográfica diferente para evitar catástrofes (que aunque poco probables, ocurren) en las que un edificio entero que alberga uno o varios CPDs, arden o se destruyen, por algún tipo de atentado terrorista por ejemplo.

• Copia fría: Nada más instalar el sistema completamente funcional, afinado, optimizado, parcheado y securizado, es imprescindible hacer lo que se llama una copia fría de la instalación. Este mismo tipo de copia es conveniente hacerla con cierta frecuencia para poder volver a un punto de buen funcionamiento conocido, en caso que suceda alguna catástrofe. Al menos sabes que "hasta aquí" funcionaba bien y siempre puedes partir de aquí si toca hacer una restauración. Las copias frías se llaman así porque se hacen sin estar utilizándose ninguno de los datos de los discos, es decir no hay ningún fichero en uso. La mejor forma es hacerlo arrancando con otro sistema operativo Live (ya sea en un CD o en un USB) y copiar las particiones de los discos de forma completa tal cual están, sin ni siquiera acceder a los ficheros en sí. Suelo utilizar una distribución Linux basada en Gentoo llamada "System Rescue CD" que incorpora una utilidad llamada "Partimage". Con ésta puedes seleccionar las diferentes particiones del disco que quieres clonar. Aunque se puede comunicar en modo cliente-servidor con un servicio Partimage instalado en otra máquina, yo suelo operar de otra manera. Arranco otra máquina de la red en la que comparto por Samba o por NFS algún recurso. Previamente a ejecutar Partimage, montamos ese recurso de red en un punto de montaje en el /tmp virtual del sistema arrancado. Luego a Partimage le digo que la copia de cada partición me la deje en /tmp/remote por ejemplo. Me ha tocado tener que restaurar en más de una ocasión desde ese backup y el resultado es excelente, por lo que la herramienta es altamente recomendable.

• Copia caliente: Consiste en copiar los datos que consideramos críticos de un sistema a otra ubicación. La finalidad es tener una copia más actualizada de los mismos de lo que nos puede dar una copia fría. Lo que se guarda y la frecuencia definida, en este caso, depende mucho de la funcionalidad del sistema en sí, así como de lo cambiante de los datos, por lo que debe ser tenido analizado caso por caso por parte de los responsables de la información a guardar. Para ello se suele utilizar software de backup, comercial o libre, o en algunos casos (me incluyo) mediante scripts hechos a mano que copien en un tar.gz/bz2 o (elige tu algoritmo de compresión favorito) que empaquete los datos. Con cada paquete de datos copiados, es recomendable no dejarlos en la propia máquina, sino enviarlos a otro sitio. En caso de una red casera en la que no se quiera tener varias máquinas encendidas, quizá sí que sea válido copiarlos en un DVD regrabable o en un USB permanentemente conectado, para poder tener una copia de actualizada si fallan los discos, pero en el caso de una empresa, lo mejor es tener centralizadas las copias en otra ubicación.

• Vaulting: Este tipo de backup consiste en que los datos (en caliente) se van replicando en "casi tiempo real" en otra ubicación. Suele ser costosa en términos del ancho de banda necesitado para llevar los datos de muchas máquinas a otro sitio, pero permite que en caso de hecatombe de la ubicación completa, los últimos datos disponibles se encuentran en otros sitios. Es importante guardar datos de varias "épocas" puesto que si una máquina se ve comprometida o troyanizada y se restituye el último backup existente, se restaura también el troyano en la máquina nuevamente.

• Time machine: Aunque este concepto lo empecé a conocer como original de Apple, y no como un "estándar de backups", me gustaría explicarlo un poquito. Es un híbrido entre Vaulting y Copia Caliente. La idea es definir un dispositivo (ya sea un disco duro externo o un Time Capsule, a través de red inalámbrica) sobre el que con bastante frecuencia se irán haciendo "copias calientes". No llega a ser Electronic Vaulting en sí, pero es una buena solución para redes "caseras". Para sistemas operativos Linux podemos utilizar TimeVault.
  

Leer más...

Seguridad en Wordpress

Dentro del mundo blogger, una de las primeras cosas a tener en cuenta, después de la temática, es sobre qué tipo de gestor de contenidos estará funcionando el blog. Si se elige Wordpress como base, también tenemos varias opciones: utilizar Wordpress.org que nos proveerá de forma gratuita los servicios básicos para albergar nuestros contenidos (teniendo que pagar si queremos añadirle ciertos extras); o bajar Wordpress e instalarlo en un servidor web que ya tengamos (se recomienda Apache o Nginx).

Nada nuevo os voy a contar con que para mantener lo más segura posible una instalación de Wordpress es imprescindible contar con la última versión disponible y que la contraseña de administración ha de ser lo más compleja posible, con caracteres no alfanuméricos, aleatorios, etc....

Sin embargo, una de las riquezas de wordpress es el grado de personalización en forma de plugins desarrollados que existen, y entre ellos los hay también dedicados a la seguridad.

Entre otros podemos destacar:

• WP Security Scan: Se crea una pestaña nueva llamada Security, desde la que nos aparece el resultado de un análisis de seguridad de caja blanca de diversos puntos a nivel de versionado, servidor, base de datos, usuarios (habilitar otro usuario administrador diferente al "Admin" por defecto), checks de seguridad por oscuridad (de versión, de prefijos de tablas), crear etc,...

• Wordpress Exploit Scanner: Este plugin está más dedicado a saber si nuestra instalación ha sido o no comprometida, más que como recomendaciones o medidas preventivas. Si no tenemos la posibilidad de instalar en la máquina que alberga Wordpress sistemas de control de integridad de ficheros como AIDE o Afick, siempre podemos utilizar este plugin para analizar ciertos parámetros generales, ficheros, base de datos, permisos, etc,...

• Wordpress Database Backup: Como administradores del blog debemos establecer una política de backups frecuentes, de manera que si el blog se ve comprometido, o una mala actualización provoca alguna catástrofe que nos haga necesitar restaurar un backup, tengamos esa posibilidad. Plugins como éste nos permiten generar backups bajo demanda o incluso programarlos con una determinada frecuencia y recibirlos en una cuenta de correo.
• SI Captcha Antispam: A fin de evitar los molestos comentarios automatizados con Spam en los posts, y visto que la eficacia de Akismet (incluido de serie con Wordpress) no es gran cosa (genera un montón de falsos positivos) esta puede ser una buena opción.
  

Yo por mi parte, en el blog "El Sumidero", aparte de utilizar varios de los plugins que he comentado para analizar la seguridad del mismo, he implementado mecanismos de control de accesos para la administración de Wordpress dentro de la configuración del propio Apache, basados en la IP origen (Si quiero administrarlo o lo hago desde la red interna o vía VPN).


<Location /wordpress/wp-admin/>
Order deny,allow
Allow from 192.168.1.27
Deny from All
</Location>


En cuanto a las tareas de backup de base de datos, utilizo desde hace varios años una herramienta llamada mysqlblasy. Es un script hecho en Perl para hacer un backup de todas las bases de datos que queramos de un servidor MySQL.

Si además queremos auditar el estado de nuestro Wordpress como lo puede hacer cualquiera desde Internet, podemos utilizar una herramienta como Plecost, que además de hacer fingerprinting de la base de Wordpress que disponemos, reconoce los plugins y sus versiones y es capaz de mostrarnos vulnerabilidades con enlaces CVE incluidas en caso de encontrar algún plugin vulnerable. Un análisis con esta herramienta (que requiere la versión 2.4 de Python como mínimo para funcionar correctamente) puede ser la guinda del pastel para la securización de la instalación de Wordpress y sus plugins.

Leer más...

Electronic vaulting: Mashup con fuse-sshfs, truecrypt y qdsync

¿Quieres vulnerar la política de seguridad de tu organización para robar información crítica y vendérsela a la competencia para poder pagar la hipoteca de una forma más cómoda?

Si además de poder pasar las fronteras árabes con PDFs más pesados de lo normal decides que según se haga un cambio en un directorio concreto, quieres ser el primero en enterarte de qué es lo que se ha modificado, sigue este post y sacia tu curiosidad.

Decir que la idea inicial era sincronizar un directorio "en tiempo real" con un espacio que físicamente se encuentra en otra localización. Sentadas las bases, lo deseable es lograr que cada vez que se realice un cambio en un directorio, queden reflejados en un lugar remoto (la finalidad puede ser como un backup online o electronic vaulting para evitar catástrofes como las del edificio Windsor, replicar logs de forma remoto para que sirvan de evidencia para propósitos forenses, robo selecto de información, etc,...)

Importante es que la información quede almacenada de forma cifrada en el destino remoto, con controles de acceso sólidos, así como que el canal de comunicación y sincronización también sea cifrado y autenticado.

Manos a la obra y planifiquemos (como nos decían los compradores de Auna) cómo hacerlo. Necesitamos un repositorio remoto accesible 24 horas (en este caso un servidor linux con el servicio SSH funcionando), un canal de comunicación cifrado y autenticado (SSH cumple perfectamente los requisitos), para guardar los datos de forma segura en la localización remota utilizaremos un contenedor cifrado con TrueCrypt (hablamos en su día de la confidencialidad que aporta el contenedor cifrado aquí), para sincronizar directorios utilizaremos QdSync (podríamos haber utilizado rsync y sería más POSIX).

Sé positivamente que a golpe de scp podríamos haber copiado y movido ficheros, sin embargo, pienso que es mucho más cómodo utilizar un módulo fuse llamado fuse-sshfs, que permite montar un sistema de ficheros remoto mediante SSH y utilizar ese espacio para almacenar información. Ni que decir tiene que el servicio SSH no tiene por qué estar en el puerto TCP 22 sino que puede ser cualquier otro (se especifica en el momento del montaje)

Por partes:

1.-) Instalamos el módulo fuse. En mi caso en una CentOS 4.7 instalamos el paquete fuse-sshfs-2.0-1.el4.rf.i386.

2.-) Descargamos y descomprimimos QdSync (en mi caso en /opt/qdsync)

3.-) Decidimos qué directorio vamos a sincronizar puesto que hay que establecer una "marca" inicial para comparar el estado del directorio con el actual (Esto se entenderá mejor más adelante). En nuestro caso he elegido el directorio /var/motion. Para hacer la primera "marca" ejecutamos un "du -ah /var/motion > /var/index_motion"

4.-) Creamos el contenedor cifrado en local con truecrypt (importante elegir el tamaño y el sistema de ficheros que mejor se adecúen a nosotros) y lo copiamos a la ubicación remota de forma manual.

5.-) Añadimos al fichero .ssh/authorized_keys2 del directorio remoto para añadir nuestra clave pública SSH. La idea es poder comunicarnos entre ambas localizaciones con SSH with Keys de manera que sea siempre de forma no interactiva

6.-) Creamos un script como el siguiente, que realice de forma automatizada todo el proceso teniendo en cuenta posibles problemas (que la localización remota esté ya montada, que no sea accesible por SSH, etc...). En mi caso el directorio a sincronizar es /var/motion. Hemos elegido /mnt/remote para hacer el primer montaje con el sistema de ficheros SSH y /mnt/cifrado como punto de montaje para el contenedor cifrado con truecrypt desde el propio sistema de ficheros remoto.

#!/usr/bin/perl
#Script que sincroniza /var/motion con contenedor cifrado en ubicación remota
#1.- Compruebo que no está montado ya /mnt/remote

if ( `mount | grep -i remote` || `mount | grep -i cifrado`)
{
system "logger \"Algo habia montado, no hago nada mas\n\"";
}
else
{
#2.- Validamos si algo ha cambiado con lo anterior
my $temp="/tmp/syncing";
$temp.=rand(100);
system "du -ah /var/motion > $temp";
if (`diff $temp /var/index_motion` != '') #Si ha cambiado algo nos interesa sincronizar
{
my $tries=0;
while ( (`mount | grep -i remote` eq '') && ($tries < style="font-style: italic;"> `sshfs root\@200.XX.YY.ZZZ:/root/Lawrence /mnt/remote`;
#montamos el sistema de ficheros remoto
$tries++;
}

if (`mount | grep -i remote` eq ''|| $tries==10) {die "no he podido montar /mnt/remote";}
# Generamos de nuevo fichero index_motion
system "du -ah /var/motion > /var/index_motion";
#montamos el contenedor como sistema de ficheros también
system "truecrypt --non-interactive -p securitybydefault /mnt/remote/Lawrence.tc /mnt/cifrado";

#Sincronizamos
system "/opt/qdsync/src/qdsync /var/motion/ /mnt/cifrado/";

#TO DO: valida tamaño que queda en contenedor sea menor que lo que hay que sincronizar
system ("truecrypt -d /mnt/cifrado");# Desmontamos el contenedor
sleep "5";
system ("fusermount -u /mnt/remote");# Desmontamos el sistema de ficheros remoto
}
unlink ($temp);

7.-) Añadimos una línea en el cron que cada minuto ejecute el script anterior. También se puede ejecutar dicho script como demonio y controlar el tiempo cada X segundos de forma manual


De esta manera, cada minuto se ejecutará el script anterior y, si ha habido algún cambio en el directorio seleccionado (o alguno de sus subdirectorios) se montará y sincronizará de forma segura.

Leer más...