SSL/TLS

¿Qué es el SSL/TLS? Veamos un ejemplo sencillo. Si yo quiero contar un secreto a una persona, no lo grito a los cuatro vientos, me acerco a ella y se lo cuento al oído. El hecho de hablar bajo hace que sea difícil que otros se enteren pero, ¿qué pasa si alguien utiliza un sistema de los que usan los espías en las películas para oírnos desde la distancia? La única solución sería hablar en clave, así por mucho que nos escuchen no nos entenderán. Pues en Internet pasa lo mismo, todas las comunicaciones pueden (y son) interceptadas (a veces por usuarios maliciosos y a veces, según lo que dicen los medios, incluso directamente por cuerpos de seguridad y gobiernos). Igual que antes, la solución es hablar en clave, cifrar nuestras comunicaciones.

Y aquí es donde entra el protocolo SSL/TLS. Su funcionamiento es sencillo, cuando voy a enviar un mensaje a un servidor seguro le pido una clave (pública) para cifrar la comunicación que después solo dicho servidor podrá descifrar con su clave (privada). Además, para dar un nivel extra de seguridad, el protocolo comprueba a quién corresponde esa clave y si es de confianza (es decir, que si yo me conecto al dominio “mibanco.com” y me invita a realizar una conexión segura, que las claves efectivamente pertenezcan a quien controla ese dominio). De esto se encarga una tercera entidad, denominada Autoridad Certificadora (CA en inglés), y aquí es dónde se encuentra la magia/problema/negocio: certificar que tú, como administrador, controlas un dominio para generar unos certificados y trabajar con SSL/TLS, cuesta dinero.

La solución gratuita pero no perfecta

Hasta ahora había generalmente dos opciones, la primera de ellas era por supuesto pagar. La segunda, generalmente utilizada por quien no se iba a lucrar con la securización de su sistema, crear una CA propia (es muy fácil hacerlo, os lo prometo) y validar con ella los certificados que se quieran generar. Ejemplo:

#Para simplificar, descargamos el siguiente fichero de configuración de CA
wget https://raw.githubusercontent.com/anders94/https-authorized-clients/master/keys/ca.cnf

#Después creamos nuestra CA
openssl req -new -x509 -days 9999 -config ca.cnf -keyout ca-key.pem -out ca-crt.pem

#Ahora generamos la clave privada del servidor (esta no se comparte con nadie)
openssl genrsa -out server-key.pem 4096

#A continuación debemos generar una petición de firma de certificado, para ello primero descargamos un fichero de configuración para simplificar
wget https://raw.githubusercontent.com/anders94/https-authorized-clients/master/keys/server.cnf

#Y posteriormente generamos la petición
openssl req -new -config server.cnf -key server-key.pem -out server-csr.pem

#Para terminar firmamos la petición con la CA y ya tenemos nuestro certificado listo para montar un servidor que soporte la comunicación segura
openssl x509 -req -extfile server.cnf -days 999 -passin "pass:password" -in server-csr.pem -CA ca-crt.pem -CAkey ca-key.pem -CAcreateserial -out server-crt.pem

Problema, cuando accedemos a un dominio que ha validado sus certificados mediante una CA no reconocida, que no tiene prestigio (¿que no cobra por ellos?), el navegador nos lanza una alerta como esta.

Esto se debe a que el navegador no tiene instalado por defecto el certificado de la CA y, por tanto, no la reconoce. Y esto, por supuesto, no genera demasiada confianza en el usuario…

Let’s Encrypt al rescate

Ya existían otras alternativas gratuitas que hacían de CA, pero su problema era el mismo que cuando generábamos una CA por nuestra cuenta: la confianza (o falta de) del navegador. Y entonces apareció Let’s Encrypt. Básicamente hacen lo mismo, pero esta vez tienen a muchos grandes de la industria apoyando la idea y han conseguido algo clave, la confianza de los navegadores. Para más información en cuanto a cómo obtienen esa confianza y cuáles son los navegadores soportados, os recomiendo visitar este post en su foro.

Si bien existen varias formas de conseguir los certificados para nuestros servidores a través de Let’s Encrypt, todas ellas bien documentadas y también explicadas a través del soporte de la comunidad, vamos a hacer una rápida prueba de concepto para securizar la comunicación con un servidor montado en una Raspberry Pi, uno de los dispositivos más populares en la actualidad con permiso de los Arduino, BeagleBoard o Teensy.

#En primer lugar, debemos asegurarnos de que los puertos 80 y 443 del router donde se encuentre la RPi están abiertos y el tráfico redirigido al servidor (la RPi). Let’s Encrypt los utiliza para validar el dominio.
#Después descargamos la última versión de Let’s Encrypt en /usr/local/src
git clone <a href="https://github.com/letsencrypt/letsencrypt" data-mce-href="https://github.com/letsencrypt/letsencrypt">https://github.com/letsencrypt/letsencrypt</a>

#Para este ejemplo utilizaremos el modo “Standalone” (más información en la documentación de Let’s Encrypt). No olvidarse de modificar el e-mail de contacto, con el que nos notificarán entre otras cosas de la caducidad de certificados (sí! caducan!) y el dominio para el que se quieren generar los certificados.
sudo ~/.local/share/letsencrypt/bin/letsencrypt certonly --agree-tos --email mymail@mail.com&nbsp; --standalone --domains midominio.com

#Los certificados se guardarán en /etc/letsencrypt (las carpetas “archive” y “keys” contienen las claves y certificados generados previamente, mientras que “live” contiene symlinks a las últimas versiones).
#Como se comentaba previamente, los certificados caducan, de hecho cada 90 días según la política de Let’s Encrypt, con lo que habrá que renovarlos, y mejor si es de forma automática.
#Para ello generamos un scrypt en /etc/letsencrypt
sudo nano auto-renewal.sh
#Con el siguiente contenido:
sudo ~/.local/share/letsencrypt/bin/letsencrypt certonly --standalone --domains claorden-home.du$
sudo cp /etc/letsencrypt/live/claorden-home.duckdns.org/fullchain.pem /var/www/rest-api/ssl/
sudo cp /etc/letsencrypt/live/claorden-home.duckdns.org/privkey.pem /var/www/rest-api/ssl/

#Aquí se podría añadir algún subscrypt que nos notifique de la renovación, por ejemplo mandando un mail o una notificación push a nuestro móvil.
#Le damos permisos de ejecución
sudo chmod +x auto-renewal.sh

#Y añadimos a crontab para que se ejecute de forma periódica
crontab -e

#el siguiente contenido:
#Run monthly, also use "@monthly"
0 0 1 * * /etc/letsencrypt/auto-renewal.sh

Con esto ya tenemos listos nuestros certificados. Ahora cuando montemos nuestro servidor en casa, debemos consultar según el sistema (Nginx, Node, Apache, IIS…) cómo realizar la comunicación mediante HTTPS y utilizarlos según las recomendaciones de cada uno. Así, al acceder a nuestro servidor podremos ver ese candado verde al lado de la URL que nos indica que la conexión es segura y quién ha verificado los certificados.

Y recordad, la próxima vez que contéis algún secreto por Internet, mejor decirlo en voz muy baja y al oído, que como diría mi compañero Iskander, el que avisa…

The post HTTPS con Let’s Encrypt, ¡protege tus comunicaciones! appeared first on S3lab.

Hoy vamos a jugar con una herramienta de búsqueda de vulnerabilidades web con la que podremos de forma muy sencilla comprobar la seguridad de nuestras aplicaciones web. La herramienta en cuestión elegida es Vega, una plataforma Open Source de auditoría web que puede ayudarnos a identificar y mitigar agujeros de seguridad ampliamente explotados.

Intalacion y escaneado

En primer lugar descargamos la herramienta desde la web oficial de Vega. Además, necesitaremos el entorno de ejecución de Java (JRE), con lo que en caso de darnos error al ejecutar la aplicación deberemos descargarlo (en versión de 32 o 64 bits, igual que Vega).

Comencemos entonces con el primer análisis. Para ello seleccionamos la opción “Start new scan” mediante su icono, a través del menú “Scan” o con el atajo de teclado “ctrl+n”.En la ventana que se nos presenta, podremos elegir la URI base sobre la que realizar la auditoría. Mucho cuidado eso sí con la elección. Salvo que se tenga consentimiento del responsable del dominio, podríamos tener problemas legales.

Posteriormente se nos ofrece la posibilidad de seleccionar los módulos a ejecutar, los diferentes tipos de ataques a realizar contra nuestro sitio web. Seleccionar todos significa mayor tiempo de análisis pero también mayor certeza de que estamos más protegidos. En caso de querer buscar cosas específicas, por ejemplo tras solucionar los problemas detectados tras un primer análisis, podríamos seleccionar solo aquellos que nos interesen. Por último, podemos añadir cookies que se enviarán en cada petición realizada por la herramienta durante la auditoría, esto puede ser muy útil para que el sistema tenga acceso a zonas que requieren autenticación (como por ejemplo un panel de administración).

Al darle a finalizar comenzará el escaneo, que podremos seguir en tiempo real, pudiendo visualizar las diferentes partes del sitio que han sido y serán analizadas así como las diferentes vulnerabilidades encontradas categorizadas según su relevancia.

Interpretación de los resultados

Una vez finalizado el análisis, podremos recorrer todos los elementos presentes en la sección “Scan Alerts”. Según vamos seleccionando cada una de ellas, se abrirán en la sección “Scan info”, donde no solo se amplía la información sobre la posible vulnerabilidad encontrada sino que además se ofrecen detalles como el impacto que puede tener sobre la aplicación web bajo análisis, como la posible solución que puede tener el problema. Si además seleccionamos la petición del apartado “REQUEST” accederemos a un nuevo panel en el que podremos observar tanto la petición como la respuesta dada por el servidor.

Una vez terminado el análisis podemos “limpiar” el espacio de trabajo a través de la opción “File – Reset Workspace”, no sin antes haber analizado cuidadosamente cada una de las alertas y, por supuesto, tratado de solventar todas ellas. Y con esto hemos realizado un primer análisis básico sobre una aplicación web que nos ayudará a conocer la situación actual de la misma y a paliar, en caso de que existieran, todas las vulnerabilidades que pudieran generar algún tipo de riesgo a los usuarios.

Cabe mencionar que existen multitud de herramientas similares a Vega (ver listado de otras soluciones) cada una con sus ventajas y desventajas. En próximas entradas analizaremos nuevas funcionalidades e intentaremos adentrarnos un poco más en el extenso mundo de la auditoría web. Y recordad, mucho cuidado con los objetivos, la seguridad por oscuridad sigue siendo una forma de vida ahí fuera y no todo el mundo agradece que le saquen las vergüenzas.

The post Buscando agujeros de seguridad en mis webs appeared first on S3lab.

Cuidado, que me estrellan el coche

Alguno estará pensando que esa posibilidad no existe, que es una locura: “Venga ya loco, el coche es pura mecánica, tendrían que acceder físicamente al motor/centralita/eje para poder hacer algo así. Lo único tecnológico que puede tener es la radio, bueno y el bluetooth, espera también la tarjeta SIM que el mío tiene mapas integrados que se actualizan solos…”. Pues bien, vayamos con algunos ejemplos recientes (que iremos actualizando según aparezcan nuevos casos, que aparecerán):

• Ya en 2011 unos investigadores mostraron cómo era posible atacar los sistemas de la gran mayoría de fabricantes que les permitía enviar comandos a la ECU del vehículo y realizar acciones como desbloquear puertas.
• Continuamos con una investigación de 2013, financiada por la DARPA, en la que los investigadores Charlie Miller y Chris Valasek mostraban como hacerse con el control de dos modelos de diferentes fabricantes de coches (artículo [EN], vídeo [EN])
• Y continuamos viendo ejemplos hasta que ya en 2015 un senador estadounidense dirige una carta a 16 fabricantes a partir de un estudio de seguridad que resalta las deficiencias de sus sistemas, incluyendo vulnerabilidades en los sistemas inalámbricos, falta de mecanismos para contrarrestar un ataque en tiempo real o incluso de detectarlo para un posterior análisis del mismo.
• BMW sufría en febrero de este año el primer contratiempo con su sistema ConnectedDrive, por fortuna ya solucionado, siendo sus vehículos vulnerables a un ataque que permitiría acceder a datos e incluso abrir el vehículo sin problemas.
• En marzo presentaba Ford su sistema MyFord Mobile, que permite acceder a los datos de tu vehículo e incluso preconfigurar temperaturas, localizar el coche o abrir y cerrar puertas. Si bien es interesante tener acceso a este tipo de funcionalidades, ¿qué pasaría en el caso de que nos hackearan el móvil?
• También en marzo descubrimos que Hyundai permite arrancar el coche o modificar la temperatura desde un reloj con Android Wear. ¿A alguien se le ocurrirá descargar su aplicación de Google Play y modificarla para tener acceso remoto al coche de los pobres usuarios que instalen la otra por equivocación? No creo, habría que tener mala leche.
• ¿Y si pudiéramos apagar el aviso de revisión del coche de forma remota? Vale, esa lucecita a veces molesta, pero está ahí por algo (¿no?). Sería peligroso que alguien se dedicara a desactivar ese aviso en todos los coches que fuera capaz de controlar. Pero bueno, por qué iba a querer nadie hacer eso.
• En una nueva prueba de concepto de julio, de nuevo Charlie Miller y Chris Valasek hackean un vehículo y toman su control, esta vez desde el sofá de casa, esta vez explotando un 0-day en un Jeep Cherokee.
• Pasamos ahora a agosto, y encontramos una demostración de cómo desactivar los frenos de un Chrysler mandando un SMS, trabajo mostrado en la prestigiosa conferencia de seguridad USENIX.

Entonces, ¿volvemos al carro tirado por caballos?

Y aquí nos encontramos, con una parte (fabricantes, actores tecnológicos y gobiernos) queriendo evolucionar e introducir tecnología en todos los aspectos posibles de nuestras vidas, y en este caso concreto en coches, y con la otra (expertos de seguridad y también gobiernos) demostrando que hay que pensar las cosas bien antes de llevarlas a mercado. Y es que la cosa va en serio, desde el gobierno de EEUU potenciando la comunicación entre coches, a los Google y Apple trabajando seriamente en sus soluciones Android Auto y Apple CarPlay respectivamente y Microsoft proponiendo su alternativa para el coche conectado. Por no hablar por supuesto del gran esfuerzo que se está haciendo en el campo del coche autónomo.

Y, entonces, ¿por qué queremos/quieren tener los coches conectados? Existen muchas aplicaciones que podrían beneficiarse de ello. Entre ellas nos encontramos desde la adecuación de las primas en los seguros en base al tipo de conducción de los usuarios a la reducción de accidentes automatizando en gran medida la conducción y teniendo un mayor conocimiento del entorno que rodea al vehículo.

¿Qué hacemos entonces? ¿Volvemos a los caballos? Yo desde luego no soy de los que piensan que la seguridad debe parar el avance de la tecnología, pero sí que parece realmente necesario que la industria del motor comience a ser consciente del peligro de avanzar demasiado deprisa. No se puede dejar de lado un aspecto tan importante como es el de la seguridad, no solo la física de los grandiosos dummies si no también la digital.

The post Un coche conectado o un carro tirado por caballos appeared first on S3lab.

Para empezar a jugar, vamos a descargar un conjunto de datos que contiene una buena cantidad de muestras de correo electrónico legítimo y correo electrónico ilegítimo (spam): SpamAssassin. Si abrimos este conjunto de datos con WEKA e intentamos realizar alguna clasificación como la vista en los artículos anteriores, veremos que la gran mayoría de algoritmos no están disponibles (aparecen en un tono grisáceo). Si volvemos a la pestaña de pre-procesado y nos fijamos en los atributos del conjunto de datos, podemos observar que solo cuenta con dos: el contenido del e-mail, de tipo texto (text) y la clase, spam/legitimate ($category$). Si bien ya habíamos trabajado anteriormente con el tipo nominal (el tipo de la variable clase) el tipo texto es nuevo, y para poder trabajar con él debemos adaptarlo a las necesidades de los clasificadores. El motivo principal: la gran mayoría de algoritmos con los que vamos a realizar pruebas no “entienden” el texto, con lo que debemos “traducirlo” a variables numéricas.

Y aquí es donde entra el Modelo de espacio vectorial (del inglés, VSM), que se encarga de representar esas palabras que encontramos en el contenido textual en un espacio vectorial de modo que los algoritmos de aprendizaje automático de WEKA puedan trabajar con ellos. Para representar nuestros mails de esta forma, debemos ir al apartado de pre-procesado en WEKA y seleccionar el filtro “StringToWordVector” que podemos encontrar en: filters-unsupervised-attribute.

Lo mejor que podemos hacer para ver las transformaciones es aplicar el filtro con las opciones por defecto, guardar el conjunto de datos transformado (añadiéndole el sufijo “_BOW” por ejemplo, del inglés Bag Of Words) y ver los resultados. Si abrimos el nuevo “Spam_Assassin_BOW” con un editor de textos, veremos que ya no tenemos solo 2 variables. Lo que hemos hecho es conservar la variable que contiene la categoría, el tipo de mensaje, y convertir la variable de tipo texto en todos los términos encontrados en el contenido de todos los mensajes del conjunto de datos. Si bajamos hasta la sección que contiene los datos (@data), podremos observar como cada e-mail se ha representado a través de parejas de números, correspondiendo el primero de ellos al número de atributo y el segundo a la aparición del mismo o no (1 o 0) en dicha instancia. Si bien de esta forma ya podemos representar ese texto de una forma matemática, la simple indicación de si un e-mail contiene o no un término no es un método muy preciso (ya que por ejemplo podría aparecer múltiples veces y no verse aquí reflejado). Así, accediendo a las opciones del filtro podremos incluir nuevas transformaciones que nos proporcionen un conjunto de datos más adecuado.

En primer lugar, nos encontramos con las transformaciones TF e IDF. Con la primera de ellas conseguimos la frecuencia de los términos en los documentos, es decir, la relevancia de cada palabra respecto al documento (al e-mail), en base a la extensión y número de apariciones. Con la segunda, frecuencia inversa de documento, obtenemos la relevancia de cada término respecto a la colección, es decir, si un término es representativo no solo para un documento sino para todo el conjunto.

Juntando ambas transformaciones conseguimos una representación mucho más interesante para nuestro conjunto de datos. Probemos ahora a aplicar cada una de las combinaciones y guardemos los resultados (“Spam_Assassin_TF”, “Spam_Assassin_IDF” y “Spam_Assassin_TFIDF”) para después compararlos abriéndolos con un editor de texto. Si seguimos investigando las opciones nos encontramos con otras como los atributos sobre los que queremos operar (attributeIndices), si queremos obtener las frecuencias de los términos por clase o respecto a toda la colección (doNotOperateOnPerClassBasis), si queremos reducir los términos a su raíz (stemmer), las palabras que queremos eliminar por carecer de valor semántico (stopWords), la forma de obtener los términos (tokenizer) o las palabras a quedarse por cada clase (wordsToKeep). Para obtener más información podemos pinchar en la opción “More”, que nos ofrecerá una descripción de cada una de las opciones disponibles.

Ahora que ya podemos dar por finalizada la representación de nuestro conjunto de datos de forma que los algoritmos de clasificación de WEKA puedan entenderlos, podemos pasar a la pestaña “Classify”, probar algunos de los algoritmos y valorar su funcionamiento siguiendo las medidas de calidad deseadas. No nos olvidemos por cierto de seleccionar el atributo clase antes de iniciar la clasificación (en la misma sección de clasificación) después de seleccionar el algoritmo deseado, o bien de reordenar los atributos como vimos en entradas anteriores. Y con esto ya tenemos el conocimiento básico para crear un clasificador de documentos.

Ahora solo queda decidir a cuál de las múltiples áreas que existen actualmente queremos aplicar estos métodos y, después, descubrir la forma de conseguir la mayor cantidad de datos (a poder ser de forma legal) para entrenarlos y conseguir así el mejor funcionamiento posible. Porque recordad, el conocimiento es poder y hoy en día ese conocimiento se fundamenta en nuestros datos.

The post WEKA, de los datos a la información (Parte III) appeared first on S3lab.

Después de introducción a Weka que vimos hace unas semanas, en el post de hoy trataremos de profundizar un poco más en esta herramienta. Para empezar, vamos a descargar un conjunto de datos nuevo con características sobre la producción vinícola: wine.arff. Para visualizar su contenido, podemos abrirlo directamente y seleccionar Weka como herramienta predeterminada o dentro de la sección Explorer y pestaña Preprocess, abrir el fichero.

Si repasamos los atributos del dataset, vemos que aparece como primero de ellos “class”, la clase de cada uno de los elementos que lo componen. En este caso tenemos las clases 1, 2 y 3, correspondientes a diferentes categorías de vino. Por defecto, Weka entiende que el último atributo será la clase de cada uno de esos elementos, por lo que lo primero que vamos a hacer es jugar un poco con los filtros para transformar nuestros datos. Abrimos entonces la sección Filter dentro de la misma pestaña Preprocess. Ahí vemos una gran cantidad de opciones, veremos algunas de ellas en ésta y en próximas entregas. Ahora seleccionamos unsupervised-attribute-REORDER. Este filtro nos permite ordenar nuestros atributos. Una vez seleccionado pinchamos en el nombre del propio filtro y nos aparecerá una ventana con opciones.

Cambiamos los parámetros de attributeIndices por “2-last,first” y pulsamos OK. Después seleccionamos Apply. Esos parámetros nos permiten reordenar los atributos a nuestro antojo de una forma sencilla (nótese que estos cambios no se han guardado en el fichero del conjunto de datos, están en memoria, si queremos conservarlos, deberemos guardarlos mediante la opción Save). Si el resultado del filtro aplicado no termina de convencernos, siempre podemos volver al estado anterior mediante la opción Undo. Probemos una clasificación rápida (e.g., Naive Bayes) y veamos los resultados. Son buenos pero siempre se puede intentar mejorarlos tratando un poco más nuestro conjunto de datos.

Antes de seguir viendo filtros, vamos a descubrir una nueva funcionalidad disponible en Weka desde la versión 3.7, el gestor de paquetes. Cerramos la ventana del Explorer y dentro de la ventana inicial seleccionamos Tools-Package Manager. Aquí tenemos un listado de módulos que ofrecen nuevas opciones a las ya de por si extensas disponibles por defecto. Busquemos por ejemplo el paquete SMOTE dentro de la categoría Preprocessing y lo instalamos. Este filtro genera nuevas muestras de forma sintética, lo que ayudará en los casos en los que el número de elementos empleados para generar el modelo (el “conocimiento”) no es demasiado extenso, como puede ser el caso de nuestro dataset de vinos. Porque recordemos, al igual que en la vida real, cuanto mayor es nuestro conocimiento mayor es nuestra capacidad de identificar elementos, de clasificarlos.

Volvemos al explorador y buscamos el filtro supervised-instance-SMOTE. Sin cambiar los parámetros de configuración del filtro, lo aplicamos. Vemos que pasamos de 178 instancias (elementos) a 226. Si probamos a clasificar de nuevo con el mismo algoritmo de antes, se puede apreciar una ligera mejoría en los resultados.

Y con ésto terminamos por hoy. Próximamente veremos cómo aplicar este tipo de algoritmos a textos, porque si alguno ha encontrado o generado un conjunto de datos con, por ejemplo, contenido de webs, tweets o e-mails habrá observado que no era posible realizar la clasificación siguiendo los pasos vistos hasta ahora. Con ello empezaremos a adentrarnos en el extenso mundo de la clasificación automática de textos, una de las bases para multitud de herramientas que usamos día a día.

The post WEKA, de los datos a la información (Parte II) appeared first on S3lab.

Una vez descargado e instalado, antes de comenzar a usarlo, deberemos buscar en el directorio de instalación de WEKA el fichero “RunWeka.ini” y modificar la línea “maxheap=” para aumentar la capacidad de la máquina virtual de Java y posibilitar así trabajar con volúmenes de datos más importantes. Un buen valor podría ser, siempre dependiendo de la cantidad de memoria RAM disponible, 4 gigas, quedando la línea entonces como: “maxheap=4G”. Ahora sí, ejecutamos WEKA. Para empezar, tenemos dos opciones de ejecución, “con” y “sin” consola. El primero nos ofrece constante feedback sobre lo que vayamos haciendo con la herramienta y puede ser de gran utilidad cuando nos encontremos con algún error durante el análisis de nuestros datos. Una vez iniciado WEKA, nos encontramos con varias opciones.La opción Explorer nos ofrece la posibilidad de trabajar con nuestro conjunto de datos, visualizarlo y pre-procesarlo, y por supuesto también realizar análisis y clasificaciones. La opción Experimenter nos permite, una vez tenemos nuestros datos preparados, realizar análisis de forma más automatizada/masiva. KnowledgeFlow es una herramienta que nos ayuda a crear un flujo de análisis de forma muy visual, arrastrando elementos al espacio de trabajo. Por último SimpleCLI nos permite realizar el tratamiento y análisis desde consola. En este artículo, nos limitaremos a conocer un poco la herramienta Explorer, vamos con ello.

Como vemos, nos encontramos diversas pestañas con una serie de opciones para tratamiento (Preprocess), clasificación (Classify-Cluster-Associate-Select attributes) y visualización de datos (Visualize). Por el momento vemos que la mayoría de opciones se encuentran desactivadas, el motivo, necesitamos cargar un conjunto de datos. Uno clásico para pruebas en WEKA es el de Iris, pero podemos escoger cualquiera o crear uno nosotros mismos en alguno de los formatos soportados (entre los que se incluye por ejemplo el formato csv). Si abrimos alguno de los ficheros con formato ARFF (específico de WEKA), podemos observar una primera sección de atributos, definidos mediante “@ATTRIBUTE”, y la sección de los datos propiamente dichos, delimitada por “@DATA”. Cada una de las líneas de la sección de datos (e.g., “5.1,3.5,1.4,0.2,Iris-setosa”) nos indican el valor tomado por cada uno de los atributos, siendo en este caso el último la clase de Iris de esa muestra.

Ahora sí, una vez cargado el conjunto de datos en WEKA, se nos activan todas las opciones y podemos comenzar a jugar con ellos. En la parte izquierda, podemos ver los atributos y si seleccionamos alguno de ellos veremos en la derecha los valores que toman. Por ejemplo, si seleccionamos el atributo “class” WEKA nos mostrará los diferentes tipos de Iris que componen el conjunto de datos: Iris-setosa, Iris-versicolor-Iris-virginica (en este caso con 50 instancias de cada una). En la parte izquierda, podemos ver los atributos y si seleccionamos alguno de ellos veremos en la derecha los valores que toman. Por ejemplo, si seleccionamos el atributo “class” WEKA nos mostrará los diferentes tipos de Iris que componen el conjunto de datos: Iris-setosa, Iris-versicolor-Iris-virginica (en este caso con 50 instancias de cada una). Una opción muy interesante en esta sección es la de Filter, que nos permitirá pre-procesar el conjunto de datos, eliminando atributos, ordenándolos, realizando transformaciones de los datos o, incluso, generando muestras de forma sintética. En próximas entradas iremos analizando estas opciones con más detalle para ver las inmensas posibilidades que ofrecen. Por el momento, y para ir acabando por hoy, pasemos a la pestaña de clasificación.

Aquí nos encontramos en primer lugar con la selección del clasificador (Classifier), donde podremos elegir qué algoritmo será el que determine el valor del atributo que queremos clasificar, en este caso “class”, la clase de Iris. Podemos observar que algunos algoritmos están desactivados, esto se debe al tipo de datos que tenemos cargados (también en próximas entregas, veremos con más detalle las limitaciones que tienen algunos algoritmos de clasificación y cómo solucionarlas). Por último, dentro de las opciones de prueba (Test options) nos encontramos con diversas posibilidades de cara a evaluar el funcionamiento de cada uno de los algoritmos que probemos. Por defecto tenemos seleccionada la validación cruzada (Cross-validation) con 10 folds. Este método divide el conjunto de datos en X subconjuntos, empleando X-1 para entrenar y 1 para comprobar, y realiza X iteraciones (siendo X el número de folds) este proceso.

Cuando se habla de entrenar y testear, muy resumido, los algoritmos analizan las características (atributos) del conjunto de entrenamiento y con eso generan los modelos de clasificación (el “conocimiento”) para después pasar a clasificar las muestras del conjunto de testeo en base a sus características. Ya que todo el conjunto de datos que estamos probando es conocido, es decir, conocemos la clase de Iris de cada una de las muestras, cuando el algoritmo termina de clasificar podemos comprobar si el resultado ha sido correcto. Esto nos indicará lo bien que lo hace cada uno de ellos y así decidir cuál será interesante utilizar cuando queramos emplearlo para clasificar muestras que son realmente desconocidas.

Pasemos entonces a hacer una prueba rápida. Seleccionamos dentro de los clasificadores NaiveBayes, dentro de Bayes, un clásico con una buena relación rendimiento-resultados, y comenzamos la clasificación (Start). A la derecha podremos ver el resultado obtenido por el algoritmo elegido. Aunque hoy no vamos a entrar a analizar en detalle estos resultados, podemos ver que ha conseguido clasificar correctamente un 96% de las muestras de prueba. Esto nos indica que, teóricamente, ante nuevas muestras desconocidas, facilitando atributos como la longitud y anchura de pétalo y sépalo, seríamos capaces de conocer el tipo de Iris que correspondería. Y con esto acabamos una toma de contacto muy rápida con WEKA, una potente herramienta para el tratamiento y análisis de datos. Como decíamos, en próximas entregas iremos profundizando para conocer con más detalle la infinidad de opciones que ofrece. Por el momento, ya podemos empezar a entender cómo funcionan estos sistemas, una de las piezas claves de este siglo XXI, el siglo del flujo de información, el análisis de datos y el profiling de usuarios.

The post WEKA, de los datos a la información (Parte I) appeared first on S3lab.