Archive for Redes

BSSID Finder

En este post veremos que sólo 20 líneas de python son las necesarias para complementar el comportamiento de un sniffer y lograr que éste cumpla con nuestras necesidades. No obstante, el objetivo principal es proporcionar una introducción práctica a la librería scapy.

Este script resulta útil cuando en las auditorías wifi se requiere el conocimiento de los distintos AP de la organización que están a nuestro alcance. Un objetivo claro puede ser, por ejemplo, suplantar la identidad de los puntos de acceso para el envío de paquetes de desautenticación a las estaciones clientes.

Evidentemente esta tarea se puede realizar de forma manual, simplemente lanzado airodump-ng y anotando los bssid de interés, y cruzando los dedos para que no existan demasiados puntos de acceso. No obstante, contemplar las posibilidades del script resulta interesante, ya que son muy extensas. Por ejemplo, con pocas líneas es posible automatizar el envío de los paquetes de desautenticación y al final, todo se reducirá en un cd y un enter.

Para hacer uso del script, como siempre, debemos disponer de nuestra tarjeta en modo monitor:

monitor_mode

La sentencia “airmon-ng check kill” nos permite matar los procesos que pueden interferir con nuestro modo monitor de la tarjeta. Es muy recomendable usar esta sentencia, ya que nos podemos ahorrar la posibilidad de obtener un comportamiento no deseado de la misma, y en consecuencia, una situación de confusión.

Read more

Instalación de un IDS con Snort. Parte II

Continuando con la instalación de un IDS con Snort (Parte I), vamos a ver como actualizar las reglas de VRT o EmergingThreats para SNORT.

snort_large

Existen varios programas para dicho cometido, pero nosotros vamos a utilizar “PulledPork”.

Lo primero que tenemos que hacer es instalar los pre-requisitos necesarios para su instalación, Para ello ejecutamos:

            apt-get install libcrypt-ssleay-perl libwww-perl

A continuación procedemos a la instalación de PulledPork:

cd /usr/src

wget http://pulledpork.googlecode.com/files/pulledpork-0.7.0.tar.gz

tar -zxvf pulledpork-0.7.0.tar.gz

cd pulledpork-0.7.0

cp pulledpork.pl /usr/local/bin

cd etc/

cp *.conf /etc/snort

El siguiente paso a realizar, es la configuración de Pulledpork.

1.Editamos el fichero de configuración:

      nano –c /etc/snort/pulledpork.conf

**Nota: Necesitarás darte de alta en la página http://www.snort.org y después de activar tu cuenta deberás solicitar tu Oinkcode.

snort

2. Modificamos las siguientes líneas:

Comentamos las líneas 19, 21 y 26. Para ello ponemos a principio de la línea el carácter “#”.

A continuación de la línea 26 añadimos las siguientes líneas

rule_url=https://www.snort.org/rules/|snortrules-snapshot-2976.tar.gz|aquí hay que poner tu Oinkcode

rule_url=https://rules.emergingthreatspro.com/|emerging.rules.tar.gz|open

Y modificamos las siguientes líneas

Línea #74 – cambiar por: rule_path=/etc/snort/rules/snort.rules

Línea #81 – des-comentar y cambiar por: out_path=/etc/snort/rules/

Línea #89 – cambiar por: local_rules =/etc/snort/rules/local.rules

Línea #92 – cambiar por: sid_msg=/etc/snort/sid-msg.map

Línea #119 – cambiar por: config_path=/etc/snort/snort.conf

Línea #121 – cambiar por: sostub_path=/etc/snort/rules/so_rules.rules

Línea #133 – cambiar por: distro=Debian-Lenny

Linea #141 – cambiar por: black_list=/etc/snort/rules/black_list.rules

Línea #192 – des-comentar y cambiar por: snort_version=2.9.7.6

Línea #196 – des-comentar y cambiar por: enablesid=/etc/snort/enablesid.conf

Línea #198 – des-comentar y cambiar por: disablesid=/etc/snort/disablesid.conf

Línea #199 – des-comentar y cambiar por: modifysid=/etc/snort/modifysid.conf

A continuación ejecutamos el siguiente comando para deshabilitar todo el bloque de reglas fwsam.

echo pcre:fwsam >> /etc/snort/disablesid.conf

Si queremos guardar todas las reglas en un solo fichero, tenemos que ejecutar el siguiente comando.

      /usr/local/bin/pulledpork.pl -c /etc/snort/pulledpork.conf -T -l

Para guardar las reglas en ficheros diferentes

     /usr/local/bin/pulledpork.pl -c /etc/snort/pulledpork.conf -k -l

Una vez actualizadas nuestras reglas para Snort procedemos a la instalación y configuración de BARNYARD2.

Para ello realizamos los siguientes pasos.

1.Instalación de pre-requisitos

      apt-get install libpcre3 libpcre3-dbg libpcre3-dev build-essential autoconf automake libtool libpcap-dev libnet1-dev mysql-client libmysqlclient-dev

2.Instalación de barnyard2

cd /usr/src/

wget http://www.securixlive.com/download/barnyard2/barnyard2-1.9.tar.gz

Si no funciona podemos utilizar el siguiente enlace

wget ftp://ftp.tw.freebsd.org/pub/ports/distfiles/barnyard2-1.9.tar.gz

tar xvfz barnyard2-1.9.tar.gz

cd barnyard2-1.9

./configure –with-mysql

Si durante la instalación se produce el siguiente error es que no encuentra la librería libmysqlclient.*. Para saber en qué directorio se encuentra podemos ejecutar el siguiente comando

      find / -name libmysql*

snort

snort

Como vemos en la imagen anterior (lo he marcado en rojo) ya sabemos la ruta donde se encuentra la librería y reanudamos la instalación.

./configure –with-mysql –with-mysql-libraries=/usr/lib/i386-linux-gnu

make

make install

cp /usr/src/barnyard2-1.9/etc/barnyard2.conf /etc/snort/

 3.Configuración del fichero barnyard2.conf.

nano –c /etc/snort/barnyard2.conf

Comprobamos las siguientes líneas.

Linea 29     config reference_file:     /etc/snort/reference.config

Linea 30     config classification_file: /etc/snort/classification.config

Linea 31     config gen_file:           /etc/snort/gen-msg.map

Linea 32     config sid_file:           /etc/snort/sid-msg.map

Y añadimos al final del fichero

output database: log, mysql, user=<usuario base de datos> password=<pasword usuario> dbname=<base de datos> host=<indicamos ip del servidor sql> sensor_name=<nombre de sensor>

           Un ejemplo de configuración para añadir las alertas a la base de datos de Snorby,

output database: log, mysql, user=snorbyuser password=PASSWORD123 dbname=snorby host=192.168.1.111 sensor_name=sensor1

Para terminar comprobamos que funcione correctamente Snort y Barnyard2

/usr/local/bin/snort -q -u snort -g snort -c /etc/snort/snort.conf -i eth0 &

/usr/local/bin/barnyard2 -c /etc/snort/barnyard2.conf -d /var/log/snort -f snort.log –w /etc/snort/bylog.waldo &

Con esto finalizamos el artículo de hoy, en el siguiente veremos cómo instalar y configurar Snorby para complementar nuestro IDS.

Saludos.

Juanjo Martínez

mitmproxy: MitM de tráfico Web for fun and profit

¿Qué es mitmproxy?

En esta nueva entrada del blog vamos a tratar un tema que siempre despierta un gran interés. No se trata de ninguna técnica nueva ni mucho menos, pero sigue dando mucho “juego“. Se trata de los ataques a la red TCP/IP, concretamente haciendo Man-in-the-Middle con envenenamiento de ARP. Algo de lo que ya hemos hablado en varias ocasiones en ese blog, pero en esta ocasión nos vamos a centrar en el tráfico Web el cual vamos a controlar con un proxy Web diseñado precisamente para el tipo de ataque que vamos a ver a continuación, mitmproxy.

Esta herramienta, que la podéis descargar desde su GitHub en esta dirección https://github.com/mitmproxy/mitmproxy, actúa como un proxy Web donde podemos interceptar tráfico, como lo haría otros proxies Web locales como Burp o ZAP, y nos proporciona una serie de scripts en Python para, por ejemplo, inyectar código HTML. Suena divertido, ¿verdad? Hay muchas herramientas que también permiten hacer esto, pero hemos elegido esta por su sencillez a la hora de lanzar este ataque.

Objetivo: inyectar código HTML

Nuestro objetivo es lanzar un ataque de MitM utilizando la técnica de envenenamiento ARP, redirigir el tráfico Web a nuestro proxy local, mitmproxy, e inyectar nuevo código en la respuesta del servidor, para alterar la apariencia de la Web en el navegador del usuario.

Escenario

Como venimos haciendo últimamente en el blog, pasamos a explicar cuál es el escenario que vamos a usar para esta prueba de concepto del ataque.

Tenemos dos máquinas virtuales; una Windows 7 (192.168.10.146) que actuará como víctima y una Kali 2 (192.168.10.149) que actuará como máquina atacante.

Herramientas a usar en máquina atacante:

  • arpspoof: para lanzar ataque MitM evenando tabla ARP
  • iptables: para redirigir tráfico 80/443 a mitmproxy
  • mitmproxy: para interceptar e inyectar código HTML

Si usáis como máquina atacante Kali 2, estas herramientas ya las tendréis a vuestra disposición para ser usadas.

Ataque MitM y redirección de tráfico

Antes de poder inyectar tráfico HTML en las respuestas del servidor al cliente (navegador Web de la víctima), necesitamos que su tráfico de red pase por nuestra máquina atacante, para ello lanzamos un ataque de arpspoofing con la herramienta arpspoof.

Pero antes de hacer esto, si no queremos dejar a la víctima sin acceso a Internet u otras redes, tenemos que hacer que nuestra máquina atacante actúe como un router, y haga reenvío de paquetes.

echo 1 > /proc/sys/net/ipv4/ip_forward

Teniendo en cuenta, que la puerta de enlace es la 192.168.10.2, la sintaxis quedaría de la siguiente manera:

arpspoof -i eth0 -t 192.168.10.146 192.168.10.2

Si todo se ha ejecutado correctamente, ya tenemos pasando por nuestra interfaz el tráfico de red de la máquina Windows 7. Como hemos comentado anteriormente, nuestro objetivo es interceptar el tráfico Web, tanto http (80) como https (443), así que necesitamos que este tráfico sea redirigido a mitmproxy, que por defecto escucha en el puerto 8080.

iptables -t nat -A PREROUTING -p tcp –destination-port 80 -j REDIRECT –to-port 8080

iptables -t nat -A PREROUTING -p tcp –destination-port 443 -j REDIRECT –to-port 8080

Read more

Creando un túnel SSH con Nessus

Muchas veces a la hora de hacer una auditoría externa y tener algún sistema de protección exterior (Firewall, IDS…), se nos habilitan diferentes mecanismos para poder acceder dentro de la red que queremos auditar sin que su seguridad exterior se vea comprometida. Es muy común habilitar un túnel SSH para acceder al interior de la red local.

notaLegal

Hoy vamos a ver cómo aprovechar ese túnel para correr Nessus como si estuviéramos ubicados dentro de la red. Como sabéis, la versión gratuita de Nessus tan sólo nos permite escaneos a direcciones IP locales, sin embargo mediante el túnel vamos a conseguir utilizar esta herramienta frente a una IP pública, como si estuviéramos dentro de la red a auditar aún estando fuera de la misma.

Vamos a utilizar para ello un túnel SSH y la herramienta Proxychains de la cual tenéis un artículo en el blog sobre cómo trabajar con ella y Tor.

http://hacking-etico.com/2013/08/27/anonimato-con-tor-y-proxychains/

En el siguiente diagrama vemos el entorno en el cual vamos a trabajar:

tunel

La idea es crear un túnel SSH y haciendo uso de Proxychains reenviaremos todas las peticiones de nuestro PC (Nodo A) a través del túnel, de tal forma que Nessus va a pensar que está corriendo el scanner en la máquina intermedia (Nodo B) que sí está en la misma red del servidor a auditar (Nodo C). Los pasos a seguir son los siguientes:

Creación del túnel SSH con el nodo B.

Para crear el túnel previamente tenemos que tener habilitado en el nodo B el servicio SSH con nuestro usuario correspondiente y una regla en el Firewall que permita las peticiones desde exterior hacia la máquina B (natearemos el puerto 22 mediante Port Fowarding a la máquina B).

Con todo preparado pondremos a la escucha un puerto en la máquina local A, de tal forma que todo lo que se envíe a ese puerto se reenviará a través del túnel que crearemos contra la máquina B. Usaremos el siguiente comando:

sudo ssh –p 22 –N –D 8081 [email protected]_B

Read more

Port Knocking con PowerShell

Después de varios días investigando con el USB Rubber Ducky para preparar una ponencia en el VI Congreso ACCID, sobre los peligros de los dispositivos USB si no se dispone de un control de éstos,  y como nos gusta tanto compartir con vosotros nuestras experiencias, os dejo este artículo sobre cómo hacer Port-Knocking con PowerShell para, por ejemplo, poder ejecutarlo desde nuestro querido Pato (USB Rubber Ducky).

A estas alturas creo que todos conocéis ya de sobra a nuestro amigo Pato, oficialmente conocido como USB Rubber Ducky y del que nuestro compañero Goldrak ya nos ha hablado. Si aún no habéis leído sus dos primeros artículos de esta serie, os aconsejo que lo hagáis:

Cuando el pato teclea Cuack Cuack – Parte 1

Cuando el pato teclea Cuack Cuack – Parte 2

¿Por qué Port Knocking?

La idea original era que el Pato ejecutara una instrucción PowerShell para descargar desde un servidor Web el payload que previamente habríamos preparado con Metasploit, para que la víctima (mejor dicho, nuestro Pato) lo descargara y ejecutara para obtener una sesión Meterpreter.

Así lo hice, monté mi servidor Web con Apache, generé con msfpayload un payload de tipo windows/meterpreter/reverse_tcp con los parámetros correspondientes y subí el fichero al servidor Web, listo para su descarga.

Problema: si dejo el servidor Web funcionando continuamente a la espera de algún ataque con el Pato, corro el riesgo de que el servidor y el recurso sean indexados por buscadores, crawlers y otras arañas. Lo ideal sería que fuera el propio Pato el que levantara el servicio Web, descargara el payload, y bajara el servicio. De esa forma dejar el servidor lo más “invisible” posible.

Se me ocurrió hacerlo con Port-Knocking, así que instalé knockd en mi servidor, donde tengo montado el servidor Web y subido el payload. El siguiente paso era configurar el knockd para que al “tocar” los puertos TCP 7000, 8000 y 9000 en un tiempo máximo de 10 segundos, levante el servicio Web, espere 30 segundos y lo vuelva a bajar. ¿Sencillo verdad?

Este es el archivo de configuración de knock.conf:

[options]

logfile = /var/log/knockd.log

sequence    = 7000,8000,9000

seq_timeout = 10

command     = service apache2 start ; sleep 30 ; service apache2 stop

tcpflags    = syn

En la opción command, escribo los comandos que quiero que se ejecuten en caso de que haya un Port-Knocking correcto: Iniciar Apache, esperar 30 (tiempo para la descarga del payload) y parar Apache. Read more

Descubriendo la red con Python y Nmap – Parte 3

Buenos vamos con la siguiente entrega de Python y Nmap, recordar que tenemos la parte 1 y parte 2, para entender que vamos a hacer en este post, donde vamos a crear un pequeño script que nos almacenara en un fichero los host que están levantados, que luego podemos usar en otras herramientas.

python-nmap Read more

Descubriendo la red con Python y Nmap – Parte 1

Nuestro compañero Miguel, nos enseñó cómo descubrir el terreno de juego con Nmap (Parte 1, Parte 2) ahora que ya sabemos, ¿Por qué no automatizamos, gracias a nuestro amigo Python, los proceso de Nmap con la librería de Python-nmap y descubrimos la red de manera automatizada?

python nmap Read more

Parando Metasploit con Snort

Hoy vamos a ver como podemos detectar cualquier tipo de ataque a una aplicación vulnerable de nuestro servidor, simplemente analizando aquellos posibles exploit que puedan ser lanzados contra este y añadiendo una regla en nuestro IDS para detectarlos y pararlos, en nuestro caso utilizaremos Snort. El escenario sería el siguiente:

escenarioPC-Metasplit

La idea es identificar una característica única del exploit a detectar con el IDS y crear una regla con Snort para detectarlo. Para ello previamente lo que hacemos es lanzar el exploit para explotar la vulnerabilidad y capturar el tráfico para analizarlo.

meterpreter

En este momento tenemos que identificar una característica única/particular de este exploit. Debemos ser capaces de obtener la máxima información de como funciona el exploit, para ello podemos analizar el código del propio exploit así como examinar su documentación.

Exploit –> http://www.exploit-db.com/exploits/28681/

Concretamente hemos usado un exploit bajo metasploit para explotar el puerto 21 de un FreeFTPd con una vulnerabilidad que lleva a cabo un PASS Command Buffer Overflow, es decir, introducir una contraseña no esperada para provocar un desbordamiento de buffer. Lanzamos el exploit varias veces y obtenemos varios ficheros .pcap que nos disponemos a analizar exhaustivamente:

wireshark1

wireshark2

Una vez que somos capaces de sacar información que identifique al exploit unívocamente nos disponemos a generar una regla en Snort. Las reglas en Snort constan de dos partes: la cabecera y las opciones. El objetivo de este artículo no es explicar el funcionamiento de Snort, ni tampoco el de como crear una regla, para ello podéis consultar su manual en http://manual.snort.org/.

Si analizamos cada uno de los paquetes que lanza el exploit veremos que se están inyectando operaciones tipo NOPs (No-Operation, instrucciones que no hacen nada, como por ejemplo sumarle 0 a un registro) para rellenar instrucciones además del Payload inyectado. Esto se suele hacer por muchos tipos de malware para reconducir la ejecución del programa, caso de caer en una posición de memoria donde haya una NOP, se ejecutarán todas las instrucciones que no hacen nada hasta llegar al trozo de código malicioso que realmente quiere ejecutar el atacante. Vemos con Wireshark las NOPs y lo que realmente inyecta el Payload.

nops

user_pass

Con toda esta información ya podemos crear un regla en nuestro IDS Snort para detectar este exploit. A continuación mostramos la regla creada según las peculiaridades encontradas en el exploit:

drop tcp $EXTERNAL_NET any -> $HOME_NET 21 (msg:”Exploit FreeFTPd  PASS Command Buffer Overflow detectado by Hacking-Ético”;  content:”USER anonymous”; content:”PASS “; pcre:”/^PASS\s[^\n]{100}/smi”; classtype:shellcode-detect; sid:1000001; rev:1; nocase;) ;

Hemos visto que el exploit va dirigido al puerto 21, que hace uso del usuario anónimo y que introduce varios caracteres raros en la parte de la PASS, por tanto esas serán nuestras características concretas para nuestra regla.

Analicemos pues la parte de la cabecera:

drop tcp $EXTERNAL_NET any -> $HOME_NET 21

Se aplicará la regla de eliminación de paquete (drop) a todos aquellos paquetes que vengan vía tcp desde una red exterior ($EXTERNAL_NET es una variable que identifica cualquier IP externa) desde cualquier puerto de comunicación en el origen (any); y cuya petición vaya destinada a una IP interna ($HOME_NET idem IP interna) sobre el puerto 21.

 Dentro de la parte de las opciones:

(msg:”Exploit FreeFTPd  PASS Command Buffer Overflow detectado by Hacking-Ético”;  content:”USER anonymous”; content:”PASS “; pcre:”/^PASS\s[^\n]{100}/smi”; classtype:shellcode-detect; sid:1000001; rev:1; nocase;) ;

En este apartado determinaremos que características tienen los paquetes que deben ser eliminados. Dejaremos constancia del bloqueo de paquetes en el log de Snort con el mensaje que aparece en msg.

El paquete debe ser una petición de usuario anónimo y que la clave contenga alguno de los datos contenidos en la expresión regular (pcre). Dicha expresión regular debe estar escrita en perl, podéis encontrar diferentes expresiones regulares y reglas en el fichero policy.rules de Snort. El resto de las opciones determinan la clase de paquete (classtype), el identificador de la regla local (sid) y revisión (rev); y por último añadimos la palabra nocase para indicar al motor de Snort que la aplicación de la regla no sea “case-sentitive“.

La regla se añadirá al final del fichero de configuración de snort (snort.conf). Una vez añadida se comprueba su funcionamiento con los .pcap capturados del ataque para ver si es efectiva en caso de producirse nuevo ataque.

snort -A fast -c /ruta/snort.conf –pcap-dir=”/ruta/pcaps/” -l .

-A modo de la alerta, rápida en este caso (fast)

-c fichero de reglas, en este caso el snort.conf que hace referencia a todos los ficheros de reglas de que se encuentra en la carpeta de snort (/rutaSnort/rules) y además contiene al final nuestra regla. Debe ponerse todo en una sola línea.

–pcap-dir indicamos la carpeta donde están los pcap para comprobar.

-l indicamos la carpeta de salida del log (se creará un fichero llamado alert)

Una vez comprobado el funcionamiento de las reglas con los pcaps que contienen la captura del exploit, obtenemos el siguiente resultado:

alert

 Vemos como además de nuestra regla, hay otras reglas dentro de snort que detectan el uso del usuario anonymous o el overflow en la PASS. Ahora sólo tendremos que coger un exploit de un 0day y analizarlo para crear una regla de Snort y que no afecte a nuestro servidor hasta que podamos parchear la vulnerabilidad en cuestión. También se suele analizar el tráfico que genera ciertos malware y crear reglas en función de las peticiones que realicen.

Bueno ahora sólo queda que os pongáis a jugar con algunos exploits y los analicéis para poder detectarlos.

Un handshake

@eduSatoe

“Si caminas solo andarás más rápido, si caminas acompañado llegarás más lejos”

WP Maltor: Plugin de seguridad WordPress para banear direcciones IP maliciosas

¿Quieres evitar que desde direcciones IP reportadas como maliciosas accedan a tu WordPress? ¿Prefieres que no accedan a tu WordPress desde Tor? Ahora con el nuevo plugin de seguridad WordPress, WP Maltor, puedes conseguirlo de una manera muy sencilla.

Este plugin, desarrollado conjuntamente por David Merinas de la empresa Deidos y Miguel Ángel Arroyo de SVT Cloud Services, mantiene actualizada una base de datos de direcciones IP que están reportadas como maliciosas, así como una lista de nodos Tor.

Desde ya el plugin de seguridad WordPress está disponible en el repositorio oficial de WordPress y listo para su instalación.

Enlace del plugin WP Maltor: https://wordpress.org/plugins/wp-maltor/

WP Maltor - Plugin de seguridad para WordPress

La instalación es muy simple y desde el momento que lo instales, y actives el plugin, ya estarás bloqueando el acceso a direcciones IP maliciosas y a nodos de Tor.

WP Maltor - Plugin de seguridad para WordPress

El plugin en su primera versión no requiere de configuración adicional. Sólo activar el plugin y estará listo para bloquear direcciones IP.

WP Maltor - Plugin de seguridad para WordPress

En la siguiente imagen se puede ver una captura del plugin en funcionamiento, bloqueando el acceso desde una IP maliciosa o proveniente de un nodo Tor.

WP Maltor - Plugin de seguridad para WordPress

Esperamos que os guste y os resulte útil.

Metadatos en Twitter con Rest API 1.1

Muchas veces no nos damos cuenta de la cantidad de datos que ofrecemos en la redes sociales cada vez que publicamos alguna nueva entrada. ¿Qué pasaría si accediéramos a la base de datos que utiliza cualquiera de estas redes sociales? Además de la información que vemos , ¿qué otra información guardan?

Vamos a ver que información obtenemos haciendo uso de la REST API 1.1 de Twitter que utilizan los desarrolladores de apps móviles (entre otros) para hacer peticiones al servidor y recuperar toda la información de usuarios, tweets, imágenes, etc. Aquí tenéis el enlace dentro de su sitio Web (https://dev.twitter.com).

¿Qué es REST? 

Es una arquitectura basada en el estándar HTTP y que nos permite crear servicios que pueden ser utilizadas por cualquier dispositivo cuyo cliente pueda trabajar con HTTP. Esto nos permite ofrecer un servicio Web accesible desde cualquier apps que entienda el protocolo HTTP, independientemente del sistema operativo en el que nos encontremos.

REST API 1.1 Twitter

Concretamente la tecnología que utiliza Twitter es precisamente la comentada anteriormente. Han creado para ello una API, actualmente la versión la versión 1.1, donde nos permite hacer uso de su servicio Web para acceder a los datos de su servidor. En esta versión 1.1 es necesario realizar las peticiones al servicio REST con alguno de los mecanismos de autenticación disponibles  (https://dev.twitter.com/docs/auth). 

Accediendo a la consola

Nosotros vamos a hacer peticiones a su servicio REST por medio de su consola (https://dev.twitter.com/console). 

01apiConsole

Consola de la REST Api de Twitter

Vamos a usar el método de autenticación OAuth, para lo cual debemos loguearnos con nuestro usuario y contraseña de Twitter y autorizar la aplicación de consola a utilizar como vemos en las siguientes imágenes.

01apiConsoleOAuth

Métodos de Autenticación para el uso de la REST Api 1.1

04apiOauth

Autorización de la consola

 

Consultas desde la consola

Ahora ya tenemos todo preparado para hacer consultas al servicio REST haciendo uso de la API 1.1 de Twitter. Debemos tener en cuenta que la contestación de las respuestas se lleva a cabo en formato JSON. Vamos a ver cuales son las posibilidades que tenemos accediendo a la documentación de la misma (https://dev.twitter.com/docs/api/1.1)

Ej.1 – Buscando tweets de una cuenta.

Vamos a averiguar que software ha creado ese tweet: Android, IOS, Paper.li, Buffer, Tweet Old Post… y la cuenta que lo ha creado, junto con su id.

Ejecutamos para ello la siguiente URI:

https://api.twitter.com/1.1/search/[email protected]_etico y buscamos dentro de sus resultados en formato JSON la caracterítica source de cada uno de los tweets. El resultado lo podemos ver a continuación.

ej1-consola

Usuario que usa Twitter desde Android

ej1-consola2

Usuario que usa Twitter desde iPhone

 

Ej.2 – Buscando tweets en un lugar geolocalizable.

Vamos a dar unas coordenadas que podemos averiguar de Google Maps con un radio de acción de 1km y una palabra de búsqueda. 

Ejecutamos para ello la siguiente URI:

https://api.twitter.com/1.1/search/tweets.json?q=ccf&geocode=37.872371,-4.764628300000027,1km donde las coordenadas que hemos dado son las del estadio del Córdoba CF y la palabra de búsqueda es CCF. El resultado sería el siguiente:

ej2-consola

Búsqueda de tweet geolocalizable.

ej2-consola2

Tweet encontrado en coordenadas dadas.

 Conclusiones

Esta es alguna de la metainformación que podemos manejar en Twitter para obtener interesantes búsquedas, todo ello manejando sus datos como si de una consulta en una BBDD se tratase. Existen muchas otras posibilidades dentro de la API 1.1 que seguro o serán muy interesantes: filtros de fechas, relación entre usuarios, geolocalización inversa, búsqueda de lugares, búsqueda de tweets por ip, etc.

Un handshake para todos !! @eduSatoe

 “Nunca darse por vencido. Nunca aparentar.

Nunca mantenerse inmóvil. Nunca aferrarse al pasado.

Nunca dejar de soñar

Steve Jobs