2015/11/21

Choco PI

Motivos: Seguridad, Educación y Bajo consumo


if you want an english version, feel free to ask me for it

Teniendo chicos hay tres caminos:

  • Permitir todo
  • Negar todo
  • Arremangarse


Lo normal es lo primero.

Mi impulso natural es el segundo.

Esta nota y alguna futura forman parte de lo que he hecho en el marco de lo tercero.

Aclaro que no soy pedagogo, esto es resultado de mi experiencia y sentido común.

Permitir todo


Es lo más sencillo. Mirá a tu alrededor y lo verás llevado a la práctica. Niños que no saben aún leer ni escribir manejando una tablet. Está ok, salvo que lo están haciendo en lugar de estar potrereando/andando en bici/patines/skate/pelota/trepar árboles/leer libros. Es la nueva tele.

Yo no estoy libre de pecado, de pequeño y no tanto pasé bastante tiempo jugando a los fichines o la Atari 130 XE, es que era un marginal.

Lo bueno es que aprenden a usar todo. Lo malo, es que a diferencia de los juegos de antes, ahora están conectados a Internet. Antes, cuando yo potrereaba, mis padres, tutores o encargados sabían lo que estaba haciendo pues lo habían hecho en su momento. Ahora, los niños estan "potrereando" en Internet, con adultos desconocidos ("no hables con extraños, no te subas al auto de un desconocido" -> "no chatees con extraños") y sus padres, tutores o encargados no tienen ni la menor idea, incluso hay algunos que ni siquiera potrerearon en el mundo real porque estaban mirando tele.

Negar todo


Lo segundo más fácil, mi impulso natural coherente con que el uso de mobile por menores en mi hogar despierta mi lado más paranóico, a tal punto que los aspectos educativos resultan perjudicados.

Ese es el problema, tampoco queremos analfabetos informáticos.

Un escenario común es "¿Podemos poner música?". Claro, siempre pueden y terminan mirando videos y de ahí está a un click jugar y es más fácil negar de una.

Arremangarse


Para no abandonarles en el ciberespacio ni negárselo, implantaré dos medidas: una, la del presente artículo, para reducir la interacción innecesaria con Internet y la otra, a futuro y en otra nota, la segmentación de la red y su monitoreo.

Puede parecer extremo, pero no tengo ganas de ser parte de una botnet. Tampoco quiero invadir su privacidad y estar mirando lo que hacen.


Teniendo un amplio y disponible almacén musical, ni hace falta pedir permiso y es sencillo restringir por contrato el acceso.


Aprovechando una Raspberry PI Model B, una caja plástica de bombones de chocolate, una adaptador usb/pata, un disco ide, un torno de mano, bastantes cds de música con sus correspondientes backups ripeados, es sólo pensar y trabajar un ratito para tener algo que permita escuchar música de algún modo.


No voy a entrar en detalles tipo instructables, pues las probabilidades de que tengas el mismo hardware que yo son bajísimas. Sólo mencionaré tips, recomendaciones y errores cometidos. Además asumo un conocimiento intermedio de administración linux, el objetivo de todo esto es estimular ideas para que te armes lo tuyo con lo que tengas.


Caminos no tomados


Quería aprovechar una SD Card de 2 GB, donde ya antes había instalado una distro para las pruebas con w3af, pero el esfuerzo de achicar alguna distro para que entre, aunque traería aparejado un brutal incremento de conocimiento, excede el alcance y tiempo de este proyecto, al punto que es más barato comprar SD del tamaño necesario, 8 GB.

Instalar una distro específica de media center que hubiese permitido instarlar en tan sólo 1 GB estuvo considerado, pero tenía que aprender cosas específicas, mejor invertirlo en conocimiento genérico.


Detalles


La idea más completa es esta, pero no implementé todo:

+--------------+         +-------+       +--------+
| Amplificador <--audio--< RBpi  <-------> mpc    |
+------^-------+         | Music |       | ncmpc  |
       |                 | Player|       | android|
       +----------IR-----< Daemon|       +--------+
                         +-^---v-+       

                           |   |           +--------+  
  +------------------------v-+ \-streaming-> http   |
  |smb/sftp/rsync/nfs/webdav |             | client |
  +--------------------------+             +--------+
                                          


Gabinete


Esto es probablemente lo más interesante de esta entrada.

Al cortar el plástico hay que usar una velocidad mas bien baja y no cortar por mucho tiempo, ya que el plástico se calienta, derrite y pega a la herramienta. La década perdida, o más bien, las tres décadas perdidas es no haber tenido antes un dremel, ¡qué lo parió!










Es recomendable pensar bien como van los componentes. Yo me equivoqué con el conector de audio, pues cuando armé el gabinete no había terminado de pensar como lo iba a usar y así fue como tuve que usar un conector de audio a 90° y además tener que sacar la RBpi para poder conectarlo y desconectarlo.

Mas o menos lo pensé en función de los cables y la circulación de aire.



Administración general


Lo más cómodo me ha resultdo ssh -X, que me permite abrir synaptic para instalar lo que necesite. Sólo hace falta conectar a kvm en el primer arranque para configurar la red.



Temperatura

En invierno no hay problemas, pero en verano se puede complicar. El único termómetro disponible es el del disco rígido, pero sensors-detect no lo vé. Mala suerte.



Real Time Clock

Raspberry PI no tiene batería ni RTC, así que hay que configurar correctamente NTP, lo cual parece ok, sólo porque la configuración de la red permite que ChocoPI acceda a Internet. Mmmm, veremos.

Hay que configurar correctamente la TimeZone, ntp viene activo por default.


Green Energy

La mayor parte del tiempo esta máquina está en vano, pero no quiero que se esté prendiendo y apagando. De hecho tiene una RBPI para que tenga bajo consumo. El disco sí me interesaría que se apague cuando sé que va a estar varias horas si uso. Eso se hace con hdparm, pero me complica la vida tanto como prender y apagar todo, así que, otro skip.



Power off


En teoría apagar una máquina debería ser de las cosas mas sencillas, ¿no? Para los que no recuerdan o no estuvieron, hubo un tiempo en el cual había que "aparcar" los cabezales de los discos rígidos antes de apagarlos para evitar que pegaran contra las superficies. Tambien eran los tiempos en que para apagar lo único que había que hacer era... apagar. Ahora hay que avisarle al sistema operativo. Más que avisarle hay que pedirle.

Con este modelo nos quedamos con lo peor de las dos épocas: hay que pedirle al sistema operativo para que apague la RBPI y hay que apagar la fuente a mano, pues el disco rígido está conectado directamente a la fuente.

Aprovechando la capacidad de I/O de la RBPI habría que poner un relé o similar y algún circuitito, pero como la idea es que esté siempre prendida, tiene muy baja prioridad.


Control del amplificador


Uno de estos días, aprovechando los pines de la RBpi, no sé cómo, voy a controlar el amplificador via el remoto infrarojo.

Storage

Primero hay que descubrir dónde aparece el disco

[dmesg]
[    7.223291] scsi 0:0:0:0: Direct-Access     XXX XXXXX          PQ: 0 ANSI: 0
[    7.248541] sd 0:0:0:0: [sda] 488397168 512-byte logical blocks: (250 GB/232 GiB)
[    7.278569] sd 0:0:0:0: [sda] Write Protect is off
[    7.302157] sd 0:0:0:0: [sda] Mode Sense: 33 00 00 00
[    7.365556] sd 0:0:0:0: [sda] Attached SCSI disk


Luego particionarlo con fdisk, formatearlo con mkfs

sudo mkfs.ext4 /dev/sda1

actualizar fstab para que se automonte:


[/etc/fstab]
/dev/sda1       /mnt            ext4    rw,relatime,data=ordered 0 0

y por último copiarle la data, como mas te guste.

MPD

Es el programa que ejecuta los temas con una interfaz remota.

Puse todos sus archivos en el disco usb, /var/lib/mpd a la par de la música y ajusté acorde a la configuración. Ahí también va el streaming.



[/etc/mpd.conf]
music_directory     "/mnt/musica/"
playlist_directory  "/mnt/mpd/playlists"
db_file             "/mnt/mpd/tag_cache"
log_file            "/mnt/mpd/mpd.log"
pid_file            "/run/mpd/pid"
state_file          "/mnt/mpd/state"
sticker_file        "/mnt/mpd/sticker.sql"
user                "mpd"
audio_output {
    type            "alsa"
    name            "My ALSA Device"
}
audio_output {   
    type            "httpd"   
    name            "My HTTP Stream"
    encoder         "lame"    port        "8000"
    bitrate         "128"

    format          "44100:16:1"
}
filesystem_charset  "UTF-8"




File Sharing

Teniendo sshd, ya tenemos SFTP. Cuando tenga tiempo, ganas y necesidad, configuraré smb y nfs de algún modo relativamente seguro.


Sincronización


En mi master de audio, cada tanto ejecuto rsync. El sentido de la confianza indica que no pueda hacer pull desde ChocoPI, en quien confío menos que mi master. No olvidés ejecutar mpd update tras cualquier cambio.

Extensión para FF


Minion, en mi caso no toma el servidor asi que hay que

about:config -> extensions.mpm.server -> ip:port

pero no hay manera de decirle la contraseña.

Metadata


Al igual que cualquier otro player, toma la metadata del archivo, no le interesan los nombres de los archivos o las carpetas contenedoras, lo cual a mi me rompe mucho los pies, pues tengo un esquema muy sencillo:

letra
   nombre.grupo
      año - nombre album
         número - nombre tema

Lo cual no se lleva muy bien con compilados, disc1 y disc2,  ni música clásica.

Si la vida fuera fácil:

ls -1 "$1" | while read interprete; do
  ls -1 "$1/$interprete" | while read disco ; do
    anio=$(echo $disco | cut -d"-" -f 1)
    eldisco=$(echo $disco | cut -d"-" -f 2-)
    ls -1 "$1/$interprete/$disco" | while read tema; do
      pos=$(echo $tema | cut -d"-" -f 1)
      eltema=$(echo $tema | cut -d"-" -f 2)
        id3tool \

          --set-title="$eltema" \
          --set-album="$eldisco" \
          --set-artist="$interprete" \
          --set-year="$anio" \ 
          --set-track="$pos" \
          "$1/$interprete/$disco/$tema"
    done
  done
done


Pero como la vida no es fácil, es otro skip...

Seguridad


Apesta, es por ello que ni me he molestado aún en configurar smb, nfs, http o webdav. MPD tiene passwords, pero, wireshark dice que


OK MPD 0.19.0
status
ACK [4@0] {status} you don't have permission for "status"
password "password"
OK
status
volume: 85
repeat: 0
random: 0
single: 0
consume: 0
playlist: 2
playlistlength: 9
mixrampdb: 0.000000
state: stop
song: 0
songid: 1
nextsong: 1
nextsongid: 2
OK



No hay manera sencilla de corregir esto

 

Links útiles


http://www.musicpd.org/clients/ncmpc/

https://wiki.archlinux.org/index.php/Music_Player_Daemon/Tips_and_tricks

http://www.suntimebox.com/raspberry-pi-tutorial-course/week-3/day-5/

http://daker.me/2014/10/how-to-fix-perl-warning-setting-locale-failed-in-raspbian.html

http://www.musicpd.org/doc/user/

http://mpd.wikia.com/wiki/Music_Player_Daemon_Security

2015/11/07

Solución definitiva a la comunicación segura

El otro día en la eko11 me hice nuevos amigos, como Iván @HacKanCuBa, aunque quizás ya lo conocía de antes, pero bueno, es el problema de tener sólo 64 Kb (https://twitter.com/dev4sec/status/660485176691138560). Hablábamos de temas que no vienen al caso cuando surgió un interesante spin off, relacionado a mensajería segura.

Por supuesto no recuerdo todos los detalles ni el orden ni quién dijo qué, asi que me tomaré algunas libertades con el relato, eliminaré las personas, agregaré docenas de detalles asumidos durante la conversación y pasaré a modo "ensayo" o "charla magistral". Prometí escribir esto en diez minutos, así que quizás hayan algunas inexactitudes, reclama y señala, por favor. Faltando a mi costumbre no he puesto citas que respalden lo que digo, muchas ideas son suposiciones.

En la actualidad la manera menos insegura de comunicación remota es mediante cartas en papel


Todo mensaje es eventualmente interceptable, sobre todo en el caso de las computadoras, dado el control existente sobre los nodos y canales. Esto incluye mail, foros, sms, chat, p2p, conversaciones telefónicas, lo que quieras.

Existen técnicas para ocultar el árbol en el bosque que cuentan con que el adversario no reconozca a un mensaje como tal. El problema es que si tiene todos los mensajes, en algún momento podría reparar en que algo se le ha pasado y revisar los mensajes viejos.

Como el almacenamiento no es gratis y tus mensajes ocupan lugar junto al de muchos otros objetivos, es importante lograr que los mensajes no sean reconocidos y sean descartados.

En apoyo a este punto se había dicho, creo que Snowden, que la inteligencia británica conserva durante unos pocos días todo el tráfico que logra ver de todo el mundo, implicando que luego buena parte se descarta. El criterio de descartar seguramente tiene que ver con que los mensajes califiquen y podemos imaginar que puede darle valor a un mensaje:
  • origen y destino, ya sea persona, cuenta, dominio o ip.
  • palabras claves
  • que no haya podido ser descifrado
  • correlación con otros eventos (supongo que por las dudas se conservan todos los mensajes N tiempo antes y despues de algún hecho importante de la realidad)


Para optimizar, probablemente se usen agentes recolectores en los blancos como finfisher, que tienen la ventaja de preseleccionar lo de interés.

Luego está el cibercrimen. Si tu máquina que ha pasado desapercibida para un organismo de inteligencia es víctima de malware común, quizás una mafia de Europa oriental esté recibiendo información a la que no dará valor, pero si sus servidores son capturados por las fuerzas del orden, ellos sabrán reconocerlo.

Y siempre queda el análisis forense, la capacidad de recuperar información pasada y supuestamente descartada analizando la memoria y disco de tu máquina.


De todo esto, para mí, lo fundamental es separar tu identidad real de la virtual, lo cual es muy difícil:


  • no debe haber relación por ips, mac address de wifi o bluetooth, cuentas de mail o social media
  • no debe tener un patrón de tráfico (horas, ubicaciones) similar
  • no debe tener una red de contactos similar 

En varias entradas ya he opinado al respecto, quizás debería reescribirlas de modo más coherente y actualizado. Va PostIt al backlog. 


Como dijo Gera en ekoXX, no recuerdo cuál, "Facebook me conoce aunque no tenga cuenta en Facebook, por todos los que me han invitado a unirme"


El correo común es mucho más difícil de interceptar por que no es automatizable. Hay que elegir cuales cartas evaluar, para lo cual rige bastante todo lo del análisis de tráfico ya mencionado. 

Luego hay que ver dentro de cada carta. De esto no sé nada, aparte de que se pueden abrir y volver a cerrar las cartas con vapor y me han dicho que se puede examinarlas sin abrirlas con un tomógrafo, lo cual debe ser bastante carito.

Se puede utilizar papel fotográfico sin revelar, de modo tal que si alguien expone la carta esta se arruina. El problema es que hace falta equipo especial y es más pesado el papel, comienza a destacar por encima del resto, no lo que queríamos.

Se puede usar tinta invisible, pero supongo que con un tomógrafo o similar es legible.

Y no estoy considerando en detalle el objetivo por parte del adversario de ver nuestra carta y que nos llegue sin que sepamos que ha sido interceptada.

El problema restante es que una vez que el adversario se ha hecho de nuestro mensaje, lo puede leer. Hace falta cifrarlo y aquí perdimos, pues cualquier cifrado que no esté hecho por una computadora es rompible por una computadora, por mera fuerza. Aunque estés un año haciendo cuentas para cada mensaje, igual la computadora te lo va a romper en segundos.

Volviendo a la conversación con Iván, pensamos en cifrar, imprimir, enviar por carta, scanear, OCR, descifrar. Con esto combinamos la capacidad de cifrar de las computadoras sin darles la ventaja del control sobre los canales de comunicaciones.

Y hemos vuelto a que estamos usando computadoras, blanco de análisis forense, emisiones electromágneticas y demases.

Si no fuera por la solución a la que arribamos posteriormente, es con lo que me quedaría. Obviamente con computadoras a las que le quitamos la capacidad de comunicación y almacenamiento y las usamos sólo para eso, probablemente arrancando de dvd, sin persistir nada, con impresoras básicas sin pooles. Quizás se podría reformular una impresora multifunción, va PostIt a backlog pero no el mío, jaja.



La solución definitiva


Finalmente, deseperados, arribamos a la solución definitiva, que usa papel, los mensajes son ilegibles y no usa computadoras: utilizar médicos que escriban nuestros mensajes y farmaceúticos que los lean.

Si queremos duplex necesitamos un médico y un farmaceútico en cada nodo, claro.


Los mensajes deben ser breves, tantas recetas podrían llamar la atención.

Cualquiera podría cuestionar que el adversario puede tener farmaceúticos. Si, seguro, pero nosotros ya tendriamos a los mejores, los que no necesitan preguntarle al paciente nada para terminar de interpretar la receta. No deben haber tantos.