José Miguel Parrella Romero

Desde 2002 he tenido la oportunidad de asistir como participante, como ponente y como organizador a decenas de eventos tecnológicos, desde Argentina hasta la India. Una característica de estos eventos es que, para mantener a los geeks con vida, suele haber una oferta muy buena de acceso a Internet en la forma de una red alámbrica o inalámbrica. Aquí explico por qué esto es un falso amigo.

La semana pasada estuve en Guayaquil asistiendo al Barcamp que se hizo en la Perla del Pacífico. El evento fue hospedado por la FIEC de la ESPOL, en unas instalaciones que ya conocía por haber participado en el FLISOL 2009 como patrocinante. Llegué al evento muy temprano, cuando aun no habían llegado muchos de los organizadores y prácticamente ningún participante. A través de Twitter hice una recomendación a los participantes que iban al evento: cifren su tráfico.

Sé que es llover sobre mojado, pero definitivamente el acceso a Internet, o en general a redes de trabajo para computadores en este tipo de eventos, es un falso amigo. La mayoría de la gente considera que por tratarse de un evento de perfil tecnológico, la red de trabajo será algún tipo de panacea técnica de la privacidad y la seguridad, y en la mayoría de casos no es así, y se deberían continuar tomando las mismas medidas que un usuario o usuaria toma en escenarios hostiles.

Desde muy temprano en la mañana, la red inalámbrica de la FIEC, servida a través de varios puntos inalámbricos con dos ESSIDs diferentes y sin cifrado, estaba replicando paquetes a todas las estaciones. La FIEC utiliza un portal captivo de Cisco y esto genera en los usuarios y usuarias, y probablemente en los administradores de la red y de la Universidad una falsa sensación de invulnerabilidad ante escenarios muy simples de violación de la privacidad y seguridad de los usuarios y usuarias.

La utilización de cifrado de punto a punto (por ejemplo a través de una VPN), verificaciones estrictas de identidades en los extremos de una conexión SSL/TLS y/o cifrado peer-to-peer de comunicaciones, por ejemplo con GnuPG, hubiera minimizado el impacto individual y colectivo de esta situación. Y, adicionalmente, considero que muchas de estas tecnologías ya están muy desarrolladas como para centrarse en el triángulo de la seguridad vs. costos vs. usabilidad — para mayor información en este tema, el lector o lectora puede referirse a mi artículo Digital signature and personal mail encryption: an S/MIME and PGP review in real-life scenarios publicado en Security Acts de Agosto 2010.

Dentro del tráfico que fue posible interceptar con el objeto exclusivo de generar estadísticas y conclusiones para aumentar la sensibilidad de los usuarios y usuarias de la red del Barcamp Guayaquil y de otros eventos en Ecuador y la región, fue posible interceptar navegación Web no cifrada y especialmente tráfico de clientes Twitter (al parecer, este evento recopila demasiadxs twitters) que divulgaban desde Direct Messages hasta listas de contactos. También fue posible percibir el flujo de cantidades muy importantes de imágenes, específicamente avatares, imágenes de perfiles de Facebook, entre otros.

Una pequeña muestra tomada en 7 minutos y 53 segundos, desde las 1420 ECT del 31/07/2010, permitió obtener 97310 paquetes con un tráfico promedio de 1,355 Mbps, para un total de 80 MB. de tráfico. De este total, 98,41% de los paquetes son de protocolo IP y de esto solo 1,63% son de protocolo UDP (DNS y NTP) con un abrumador índice de 12,84 más tráfico sin cifrar que tráfico cifrado, del cual hubo escasos 3 Mb. bajo TLS/SSL.

En otra muestra un poco más grande, que cubrió 1 hora y 12 minutos desde las 0855 ECT, se obtuvieron 350716 paquetes con un tráfico promedio de 0,422 Mbps (todavía no había llegado la gente) donde se observan los mismos patrones de uso. En otra captura, la más grande, que cubrió 1 hora 46 minutos, desde las 1018 ECT, se percibió 1 MB. en archivos GIF y 2.76 MB. en archivos JPEG, así como adjuntos de mensajería electrónica, archivos XML con parámetros de configuración de clientes de Twitter y otros temas. Todas las muestras fueron destruídas luego de la obtención de estas estadísticas de uso y de la misma manera se exceptuó de las capturas información que permitiera correlacionar estas capturas con personas particulares.

Todo esto se hizo para una población variable que promedió 82 dispositivos en una de las dos redes, que, por cierto, usa direccionamiento IPv4 para sus clientes, lo cual es sinceramente un malgasto de recursos, que incluía 2 iPod/iPhone, 3 Nokia, 2 Blackberry, 47 equipos con Windows, 7 con MacOS X y 3 con Linux.

Es importante resaltar que toda esta información estaba disponible sin ninguna restricción debido a la falta de configuración en los equipos inalámbricos y redes conexas utilizadas en el evento. De la misma forma de que yo me percaté, lo pudo haber hecho cualquier otra persona, incluyendo potencialmente gente simplemente ociosa que hubiera podido generar daños gracias simplemente a la disponibilidad de esta información.

Lamentablemente, en mi experiencia, es futil arrojar la culpa a los administradores de la red solamente. Si bien ellos pueden encontrarse responsables del asunto, el enfoque de privacidad y seguridad en redes públicas debe ser proactivo y no solamente reactivo. En este sentido, el uso de tecnologías por parte del emisor y del receptor para facilitar los mecanismos que permitan incrementar la percepción de seguridad a la vez que se reducen tangiblemente los vectores de ataque es una de las medidas que es importante promover entre los usuarios y usuarias.

Hay distintos foros en Ecuador para apoyar sin fines de lucro a los usuarios y usuarias en el tema de seguridad de la información; uno de los más específicos era COMSec (seguridad.com.ec/hackers.ec) que ahora está offline, pero existen otros espacios, desde Twitter (hashtag #Ecuador) hasta listas de correo como Equinux o foros de grupos de interés. Yo estoy como siempre a la orden para aquellxs que quieran dar el primer paso para formar una cultura de seguridad de la información en su quehacer tecnológico diario.

Update: estamos en proceso de traducir la Cartilla de Seguridad del CERT.br al castellano con el apoyo del Grupo de Seguridad de LACNIC, ISOC Ecuador y voluntarios de la región.

Traditionally, Koha 3 depends on the items (we call them existencias in spanish) having a barcode in order to uniquely identify each item. Circulation, for example, requires the librarian to scan the barcode of an item in order to circulate it.

At times, this proves inconvenient since lots of biblios (titles, or títulos in spanish) have the same barcode printed on each item (usually the ISBN number) forcing the library to print new unique barcodes (Koha has a nice barcode generator) for each one of the items in existence.

However, it’s usually not feasible to relabel all items with new barcodes, especially if you have millions of items nationwide. So, I thought of an easy patch to Koha that allows to circulate items based on the item number, and not the barcode.

First of all, you should set the barcode number for each item equal to the item number for those items where you don’t have any barcode recorded. These is best accomplished after loading MARC records on the database using the MySQL console:

  UPDATE items SET barcode = itemnumber; -- optionally using something like WHERE barcode = ''

On my case, for over 1.1 million items, it took some 3 minutes 6 seconds to complete. There’s a drawback, however, because you need to run this periodically as you add more items, but it’s not something your DBA can’t automate. At this point you can circulate items using items number, and you can print barcodes with that number, but it’s still not easy for the librarian to either remember the item number or look it up before circulating.

You can apply an easy patch on line 44 of the modules/catalogue/moredetail.tmpl file of the Intranet, providing a new link on the Items tab of a biblio to start the borrowing workflow for a specific item:

<!-- TMPL_UNLESS NAME="issue" --><a href="/cgi-bin/koha/circ/circulation.pl?barcode=<!-- TMPL_VAR NAME="itemnumber" -->">[Circulate item <!-- TMPL_VAR NAME="itemnumber" -->]</a><!-- /TMPL_UNLESS -->

Of course, circ/circulation.pl on the Intranet also needs a small patch to store the barcode number on the session and then reusing it when the borrower is selected, near line 111:

my $barcode;
if ( $session->param('barcode') ) {
  $barcode = $session->param('barcode');
  $session->clear('barcode');
} elsif ( $query->param('barcode') ) {
  $barcode = $query->param('barcode') || '';
  $session->param('barcode', $barcode);
}

$barcode =~  s/^\s*|\s*$//g; # remove leading/trailing whitespace
...

Restart your Web server and that’s it. You can now search for a biblio, go to the Items tab, select an item to be circulated, select a borrower, and the item is circulated. For returns, search for the user and go to the end of the page, you can see all items on circulation, fines and return options. The workflow changes a little bit, but it’s the easiest way I’ve devised to operate a Koha ILS when barcodes are absent or outside your control.