Ceibal y Google Apps for Education: bienvenida la discusión, pero para arribar a conclusiones

IT_GAFElogo

El Plan Ceibal firmó un contrato para disponer de Google Apps For Education para la Educación Pública de Uruguay y recientemente la Universidad de la República (UdelaR) emitió un comunicado manifestando su «honda preocupación por la aplicación del acuerdo sin discusión previa«.

Su preocupación se centra en la  «cuestión la protección de los datos personales de los menores de edad alumnos de la ANEP, en clara discordancia con la normativa vigente en nuestro país«.  El comunicado concluye con la explícita disposición institucional para discutir y evaluar «alternativas eficaces» «que sean garantes de la protección de los derechos consagrados por la legislación nacional«.

Bienvenida la discusión, que siempre es buena y sana cuando su objetivo es arribar a conclusiones y lograr un mejor resultado que el originalmente previsto.

El Plan Ceibal sometió el contrato al análisis de la Unidad Reguladora de Control de Datos Personales (URCDP) que concluyó que el acuerdo «se adecúa a las disposiciones normativas vigentes en materia de protección de datos personales«.

Entonces lo primero a resolver es quién tiene razón si la Universidad de la República que ve una clara discordancia con la normativa vigente o la Unidad Reguladora de Control de Datos Personales que entiende que se adecúa a la normativa. Tiendo a pensar que la organización especializada en regular los datos personales (URCDP) a quién le piden un análisis específico, no se equivoca y creo que la Universidad de la República se apresuró en sus fundamentos, sin consultar a sus especialistas en la materia.

Pero más me llama la atención cuándo la Universidad de la República ofrece discutir y evaluar alternativas eficaces que sean garantes de la protección de los derechos, pues si tiene alternativas eficaces deberian estarlas planteando.  Es fácil darse cuenta que el Plan Ceibal YA TIENE el problema resuelto de ofrecer una plataforma mediante este acuerdo con Google, mientras que la Universidad de la República pretende detenerlo para abrir una mesa para una discusión abierta y minuciosa de alternativas (no manifiestas).

Bienvenida la discusión.  Discutamos, pero si es una discusión constructiva.

Percibo un mensaje de lo que hiciste no me gusta y como no lo discutiste conmigo, entonces «paren las rotativas»,  primero vamos discutirlo y luego vemos qué hacemos, y eso no parece constructivo.

Quién profesa «honda preocupación» por algo, no está a favor. ¿es esa la semilla para ofrecer un aporte constructivo?

¿por qué la Universidad ve problemas donde Ceibal no los ve? ¿acaso por la «clara discordancia con la normativa vigente»? …. ¿y URCDP?

o ¿por qué la Universidad conoce «alternativas eficaces» que Ceibal no conoce?  ¿por qué parecen estar  «reservadas» para la mesa de discusión una vez que el acuerdo se «congele»?   La Universidad de la República tiene gente con muchísima capacidad que seguro está al tanto de esas alternativas eficaces ¿por qué no las están planteando?

Sigo diciendo que es buena la discusión del tema y que se tiene que dar, pero que no así, que parece un palo en la rueda al Plan Ceibal.

No así, sin concretar esas alternativas eficaces a los servicios de Google Apps for Education de los que se habla, porque a mi me dan miedo otras empresas globales, competidoras de Google, que ya han ‘coqueteado’ con el Plan Ceibal y que si son alternativas.

Con comunicados de este tenor pienso que la Universidad de la República se está perdiendo la oportunidad de hacer un aporte sustancial al Plan Ceibal.  Si se tiene conciencia de los problemas relativos a la protección de la privacidad, aprovechemos a trabajar con los maestros, educadores, familias y niños para que cada uno pueda reconocer estos problemas y protejer sus datos.

Y sería bueno para toda la sociedad la discusión seria de las soluciones eficaces (que existen) para protejer la privacidad y los datos personales; pero cómo dice Raúl Echeberria en la nota de Subrayado «la discusión sobre la privacidad y protección de los datos personales ‘es otro tema’«, o  al menos es lo que hasta ahora parece y está quedando relegada.

Google-Authenticator: doble validación para tus cajas Linux

google-authenticator Cuando accedemos a nuestros servidores Linux mediante login (consola) o secure shell (SSH remoto) nos validamos como forma normal de dar seguridad al acceso. Estos mecanismos pueden ser mejorados en los niveles de seguridad mediante configuraciones en /etc/security (login) o ajustes y certificados en SSH; pero la validación en dos pasos, con clave («lo que se«) y también con código de un-solo-uso («lo que tengo») vuelve el proceso de validación mucho más seguro.

En este artículo se describe cómo instalar en el servidor Linux la validación en dos pasos de Google para pedir el código único de acceso inmediatamente luego de validar la clave. Los pasos descriptos son para CentOS 7, pero conceptualmente son equivalentes a los que requiere Debian, donde también lo he instalado; así que vamos:

Requisitos previos

Se requieren los paquetes para compilar el módulo de PAM correspondiente. Una primer opción es instalar todo el ambiente de desarrollo:

yum group install "Development Tools"

O si, solo quieres lo mínimo necesario, deberían ser suficiente estos paquetes:

yum install git autoconf make gcc pam-devel

Fuentes de google-authenticator

Clonamos el repositorio git con la última versión del código:

git clone https://github.com/google/google-authenticator.git

Los fuentes también incluyen las aplicaciones para móviles, pero a nosotros no nos interesan ahora.

Compilación e instalación

Seguimos el documento de instalación dado por los desarrolladores, indicando solamente dónde queremos el módulo, para que lo tome automáticamente CentOS:

cd google-authenticator/libpam/
./bootstrap.sh
./configure --exec-prefix=/usr/lib64
make
make install

(solo ‘make install’ requiere privilegios de root, por lo que debería precederse de ‘sudo’, si corresponde)

Instalación en login

Agregar módulo PAM en archivo /etc/pam.d/login inmediatamente debajo de la linea del módulo ‘system-auth’, o como último módulo del tipo ‘auth’:

auth required pam_google_authenticator.so

Instalación en SSH

El módulo tiene que ser agregado en el archivo /etc/pam.d/sshd, también como último módulo del tipo ‘auth’:

auth required pam_google_authenticator.so

Además en el archivo de configuración del servidor SSH /etc/ssh/sshd_config habilitar:

ChallengeResponseAuthentication yes

para que siga el procedimiento de autenticación de PAM.

Reiniciar servidor sshd

systemctrl restart sshd

Configuración de usuarios

Cada usuario debe inicializar el sistema de códigos de un único uso y sincronizarlo con la aplicación de su celular y no es mi objetivo profunzar mucho en esto, pero el usuario ejecuta:

$ google-autenticator

y el sistema le hará unas preguntas de configuraciones de seguridad y generará un archivo .google_authenticator en el home del usuario. En ese archivo se incluyen también algunos códigos de emergencia y el código para iniciar la aplicación del móvil a calcular códigos.

Resultado

Y ya queda activo para ese usuario; aqui con login:

linuxbox login: rodolfo
Password:
Verification code:

Aquí con ssh:

$ ssh rodolfo@linuxbox
Password:
Verification code:
Last login: Wed May 6 17:10:16 CDT 2015 from r167-anteldata.net.uy on ssh:notty
Last login: Wed May 6 17:09:04 2015 from 167.60.140.132
[rodolfo@linuxbox ~]$

El sitio de XModulo tiene un buen conjunto de tutoriales sobre la instalación y configuración de google-authenticator y más información también está disponible buscando un poco.

peligro caliente no tocar

Hasta que se solucione, por favor, no reiniciéis el ordenador

Suelo tratar el tema de «la confianza en el proveedor» cuando utilizamos software que descargamos y corremos. Es un riesgo que tiene que ser ponderado, discutido y acceptado de forma de tomar las precauciones de acuerdo a la importancia del negocio; pues los problemas se sucederán.

¿Qué información envías por correo electrónico?

«Una carta enviada sin sobre por el correo tradicional tiene menos posibilidades de ser leída que un correo electrónico normal»

(esto lo he repetido muchas veces, de varias formas distintas)

Foto: Nikhil Verma
Foto: Nikhil Verma

No dejo de maravillarme con el correo electrónico moderno, en cuanto a que puede ser fácilmente trucado, modificado y espiado pero funciona bién para la inmensa mayoría de la gente. Mientras otras tecnologias de Internet son insatisfactorias si no están cifradas, resguardadas, auditadas con altos requisitos de seguridad, el correo electrónico sigue tan campante desde 1970 siendo la herramienta de comunicación más utilizada y con mínimos (casi nulos) requisitos de seguridad.

Generalmente me llama la atención como importantes profesionales manejan datos realmente críticos y los hacen fluir por correo electrónico; pero además agregan el famoso pie «Si recibe este correo por equivocación…» tratando de obligar al destinatario a una confidencialidad que ellos mismos no han tomado precauciones en asegurar.

Y aca no hay inocentes:  no importa la profesión (abogados, ingenieros, contadores), ni la importancia del negocio (empresas nacionales o multinacionales), ni el rubro; la inmensa mayoría envia sus correos para que cualquiera lo lea y, de hecho, son muchas veces leídos, indexados, analizados y registrados de forma consetudinaria, minuciosa y rigurosa.

A todo esto, el gobierno de mi país (Uruguay) pone en funcionamiento un excelente software de «monitoreo» de correo electrónico: El Guardián

El País: «El Guardián»: gobierno pone en marcha súper espía informático

Mi única referencia sobre este software es que «es bueno» en lo que dice que hace y, con el correo electrónico como lo usamos no se necesita mucho empeño para serlo.

Espero que llegue el día en que podamos identificar la calidad del remitene y del mensaje en base a los recaudos que se tomaron para asegurar la confidencialidad del correo electrónico.

Administración de llaves SSH para aplicaciones

Las llaves de SSH permiten, por defecto validar la conexión al destino y cifrar el tráfico entre el cliente y el servidor. Con algo de configuración es posible validar el orígen contra el servidor y de esa forma en lugar de conocer la clave para acceder, la validación es por certificados. Cuando empezamos a utilizar aplicaciones y a automatizar los accesos aparecen los compromisos de seguridad, esta presentación aborda las configuraciones básicas para la administración de las llaves SSH cuando se usan para otorgar accesos a las aplicaciones.

Público objetivo: Casi cualquiera que utilice SSH para vincularse con servidores, equipos y aplicaciones remotas.

Requisitos: Conocimientos de SSH o haberlo utilizado como cliente.

Presentación realizada en:

  • 15 nov 2014 – Techmeetup 2014 – (Meetup Space) – Torre de las Comunicaciones, Montevideo, Uruguay

Truecrypt contenedor de datos cifrados

Durante bastante tiempo fui usuario de EncFS para guardar mis datos personales cifrados y poderlos transportar. La verdad que EncFS funciona de maravillas con fuse y es muy práctico, aunque el resultado es un directorio con datos (cifrados) y a mi siempre me atrajo la idea de armar mi sistemas encriptados en un archivo (contenedor), que yo pueda montar y ya hace tiempo que uso Truecypt para esto.

Truecrypt permite crear un archivo y luego montarlo en el filesystem y copiarle cosas adentro o trabajar con él, como si fuera un filesystem común, salvo que está encriptado.

Para instalarlo en sistemas *ubuntu, es tan fácil cómo descargar de aqui:

$ wget http://www.truecrypt.org/downloads/truecrypt-6.0a-ubuntu-x86.tar.gz
$ tar xf truecrypt-6.0a-ubuntu-x86.tar.gz
$ ./truecrypt-6.0a-setup-ubuntu-x86

y se siguen los pasos que se indican en la interfaz, lo mejor es instalar el .deb que sugiere y se va a encargar de colocar lo que haga falta (libfuse y fuse-utils).

Su uso por línea de comandos es muy simple:

Para crear un volúmen:

$ truecrypt -t -c archivo.tc
Volume type:
1) Normal
2) Hidden
Select [1]:

Enter volume size (sizeK/size[M]/sizeG): 10M

Encryption algorithm:
1) AES
2) Serpent
3) Twofish
4) AES-Twofish
5) AES-Twofish-Serpent
6) Serpent-AES
7) Serpent-Twofish-AES
8 ) Twofish-Serpent
Select [1]: 1

Hash algorithm:
1) RIPEMD-160
2) SHA-512
3) Whirlpool
Select [1]: 1

Filesystem:
1) FAT
2) None
Select [1]: 1

Enter password:
Re-enter password:

Enter keyfile path [none]:

Please type at least 320 randomly chosen characters and then press Enter:
asdlkfjdsalkfjasdlkfjasdl;kfjasd;lkfjasdl;kjf[…]

Done: 100,000% Speed: 13,8 MB/s Left: 0 s
The TrueCrypt volume has been successfully created.

$ ls -al archivo.tc
-rw——- 1 rodolfo rodolfo 10485760 2008-09-04 15:45 archivo.tc

y ahi está mi contenedor

Para montar el volumen encriptado en el filesystem es asi:

$ truecrypt -t -v archivo.tc /mnt
Enter password for /home/rodolfo/archivo.tc:
Enter keyfile [none]:
Protect hidden volume? (y=Yes/n=No) [No]:
Volume “/home/rodolfo/archivo.tc” has been mounted.

$ df -h
S.ficheros Tamaño Usado Disp Uso% Montado en
/dev/loop0 10M 0 10M 0% /mnt

$ truecrypt -t –list
1: /home/rodolfo/archivo.tc /dev/loop0 /mnt

y alli ya se puede usar copiando cosas para el /mnt

Para desmontarlo se pueden usar diferentes etiquetas, pero yo suelo usar el punto de montado:

$ truecrypt -t -d /mnt

Hay dos cosas que me gustan mucho de Truecrypt, la primera es que tiene una simple interfaz gráfica que funciona sola (al no usar el modificador -t):

la segunda cosa que me gusta es el hecho que es multi-plataforma, asi que mis contenedores truecrypt los abro transparentemente desde MacOSX también… y bueno, si algun día tengo que compartir algo con un usuario Windows, pues también! Así que en mi pendrive tengo una carpeta truecrypt con los ejecutables e instaladores para todas las plataformas.

Claves fuertes vs. claves débiles

Encuentro en el blog de Jimmy Ruska un artículo que analiza las claves (passwords) más usadas, allí textualmente dice:

Claves más comunmente utilizadas

1. 123456, 123, 123123, 01234, 2468, 987654, etc
2. 123abc, abc123, 246abc
3. primer nombre
4. grupo musical favorito
5. cancion favorita
6. primeras letras del nombre y del apellido
7. qwerty, asdf, y otras secuencias de teclado
8. comic favorito o película favorita
9. deporte favorito o estrella del deporte
10. país de origen
11. ciudad de orígen
12. todo números
13. alguna palabra del diccionario
14. combinación de dos palabras del diccionario
15. cualquiera de las anteriores escritas al revés
16. aaa, eee, llll, 999999, y otras repeticiones

Jimmy hace todo un análisis muy interesante sobre las claves y su opinión sobre este comportamiento común, que sugiero leer. De alli rescato también este cuadro, donde se muestra el tiempo que se tarda en generar todas las combinaciones posibles para distintos formatos y largos de claves:

Largo de Clave Letras Letras / Números
3 caracteres 1s 2s
4 caracteres 3s 10s
5 caracteres 1m17s 6m
6 caracteres 26min 3h30m
7 caracteres 14 horas 6 días
8 caracteres 15 días 205 días

Obviamente, a medida que el poder de cálculo de las computadoras aumenta, estos tiempos disminuyen.

Generador de claves

Si esto de las claves te es de interés, puedes empezar por un asistente generador de claves. Mi sugerencia es que si andas perdido SISMIT por ahí, tratando de crear una clave y luego poderla recordar, te vayas hasta SISMIT online Password generator with Sha-1 encryption, que te permite crear claves fáciles de recordar, para luego utilizar en distintos lugares. SISMIT es un sitio en Ajax que te pregunta un nombre favorito, una palabra favorita y una fecha favorita y con esos datos arma claves, que buscan ser fáciles de recordar a partir de esos datos favoritos.

También con

apt-cache search password generator

puedes ver varios generadores de claves para descargar y tener instalados en tu comutador.

Administrador de claves

Claro, luego llega un momento que por más mecanismos para recordar las claves, si queremos tener suficiente cantidad de claves distintas para sitios distintos, debemos recurrir a algun software de ayuda. (paradojicamente el software que estoy usando actualmente no es ninguno de los allí listados…. ya pondré un artículo sobre él).

Cordura de claves

Hasta que algun día evolucionemos intelectualmene y nos demos cuenta de lo obvio:

chiste18-09-09

(a ver…., no tomen muy en serio esto último…., o sí, medítenlo!)

Revisar Open Relay del servidor de correo

open relaySiempre que instalo un servidor de correo pruebo cómo quedo la configuración, aunque sea en sus características de seguridad más basicas y para esto siempre me ha sido útil el servicio de MAPS que hace unos testeos bastante exaustivos del servidor.

Para probar si el servidor es un open-relay, desde el servidor que se desea probar se hace un telnet:

telnet relay-test.mail-abuse.org

Y como resultado se obtiene:

steve@skx:~$ telnet relay-test.mail-abuse.org

Trying 168.61.4.13…

Connected to Cygnus.Mail-Abuse.ORG.

Escape character is ‘^]’.

Connecting to 212.13.199.210 …

< << 220 skx.vm.bytemark.co.uk ESMTP Exim 3.35 #1 Mon, 08 Nov 2004 12:52:47 +0000 >>> HELO cygnus.mail-abuse.org

< << 250 skx.vm.bytemark.co.uk Hello cygnus.mail-abuse.org [168.61.4.13] :Relay test: #Quote test >>> mail from:

< << 250 is syntactically correct >>> rcpt to: < 'nobody@mail-abuse.org'>

< << 501 <'nobody@mail-abuse.org'>: recipient address must contain a domain

>>> rset

< << 250 Reset OK :Relay test: #Test 1 ... ... ... System appeared to reject relay attempts Connection closed by foreign host.

La ventaja de este telnet, ante otros servicios que hay de prueba es que no tiene efectos secundarios (abuse.com coloca al servidor en blacklist en caso de open-relay) y además es instantáneo, pues las pruebas son en tiempo real.

Este artículo está basado en «Is your mail server an open relay?».