Entries for redes

Para un proyecto que estoy desarrollando ahora mismo, he necesitado montar unos WebServices con Rest, usando JSON. La forma más rápida de testearlo es utilizando curl. Para ello podemos utilizar el siguiente comando para simular una petición GET. Esto nos mostrará algo parecido a lo siguiente:

$ curl -v -H "Content-Type: application/json" -H "Accept: application/json" -X GET  http://localhost:8888
* About to connect() to localhost port 8888 (#0)
*   Trying 127.0.0.1... connected
> GET / HTTP/1.1
> User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
> Host: localhost:8888
> Content-Type: application/json
> Accept: application/json
> 
* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
< Date: Mon, 29 Oct 2012 21:48:49 GMT
< Server: WSGIServer/0.2 Python/3.2.3
< Content-Type: application/json; charset=utf-8
< Content-Length: 159
< 
* Closing connection #0
{"respuesta": "en json"}

Ahora vamos a suponer un WebService que cree un usuario. Para ello, recibe 'username', 'password' y 'email'. Para la creación se va a utilizar el método POST. Y esto debe mostrarnos algo similar:

$ curl -v -H "Content-Type: application/json" -H "Accept: application/json" -X POST -d '{"username":"myuser", "password":"mypwd", "email":"myemail@mytest.com"}' http://localhost:8888
* About to connect() to localhost port 8888 (#0)
*   Trying 127.0.0.1... connected
> POST / HTTP/1.1
> User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
> Host: localhost:8888
> Content-Type: application/json
> Accept: application/json
> Content-Length: 69
> 
* upload completely sent off: 69out of 69 bytes
* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
< Date: Mon, 29 Oct 2012 21:52:47 GMT
< Server: WSGIServer/0.2 Python/3.2.3
< Content-Type: application/json; charset=utf-8
< Content-Length: 43
< 
* Closing connection #0
{"respuesta": "en json"}

Además, podemos aprovechar para testear métodos HTTP que no estén implementados. Supongamos que PUT no está implementado, entonces el resultado deberá ser 'Method not allowed':

$ curl -v -H "Content-Type: application/json" -H "Accept: application/json" -X PUT -d '{"...":"..."}' http://localhost:8888
* About to connect() to localhost port 8888 (#0)
*   Trying 127.0.0.1... connected
> PUT / HTTP/1.1
> User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
> Host: localhost:8888
> Content-Type: application/json
> Accept: application/json
> Content-Length: 69
> 
* upload completely sent off: 69out of 69 bytes
* HTTP 1.0, assume close after body
< HTTP/1.0 405 METHOD NOT ALLOWED
< Date: Mon, 29 Oct 2012 21:55:36 GMT
< Server: WSGIServer/0.2 Python/3.2.3
< Content-Type: text/html; charset=utf-8
< Allow: GET, POST
< Content-Length: 0
< 
* Closing connection #0

Por otro lado, también podemos probar que no se soporta una respuesta en algo que no sea json, por ejemplo text/html. Y como resultado obtendremos un 'Unsoported media type':

$ curl -v -H "Content-Type: application/json" -H "Accept: text/html" -X GET  http://localhost:8888
* About to connect() to localhost port 8888 (#0)
*   Trying 127.0.0.1... connected
> GET / HTTP/1.1
> User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
> Host: localhost:8888
> Content-Type: application/json
> Accept: text/html
> 
* HTTP 1.0, assume close after body
< HTTP/1.0 415 UNSUPPORTED MEDIA TYPE
< Date: Mon, 29 Oct 2012 22:00:34 GMT
< Server: WSGIServer/0.2 Python/3.2.3
< Content-Type: text/html; charset=utf-8
< Content-Length: 0
< 
* Closing connection #0

Llevaba cerca de dos días con un problema implementando el subscriptor MQTT. Aún no está hecho el diagrama de flujo ya que de momento estoy probando que las llamadas de la biblioteca funcionan. El escenario es el siguiente:

1. mqtt_connect
2. mqtt_subscribe
3. mqtt_unsubscribe
4. mqtt_disconnect

Conectamos el cliente, nos subscribimos a un topic, nos desubscribimos y desconectamos el cliente. Algo que a priori es sencillamente elemental.

Para comprobar que todo esto funciona he hecho uso del script para Wireshark que ya comenté. Pero el caso es que estaba encontrando errores en Wireshark que no eran lógicos. Yo mandaba un paquete de 17bytes y Wireshark decía que el paquete tenía 19bytes. ¿Qué estaba pasando aquí?

Acabo de terminar una primera versión del script que parsea MQTT para mostrar la información sobre este protocolo en Wireshark.

Lo he dejado colgado de Github, por si alguien está interesado en el tema.

Wireshark incluye el parseo de la inmensa mayoría de protocolos de red que existen, pero cómo es evidente, no todos. Estas semanas estoy trabajando con MQTT y para este protocolo hay un soporte muy muy básico.

Para lanzar el script, basta con ejecutar lo siguiente:

$ wireshark -X lua_script:mqtt.lua

donde mqtt.lua es el nombre de mi script.

Ahora mismo estoy trabajando en un script escrito en Lua para parsear información de un protocolo en en Wireshark. Necestio hacer unas pruebas como superusuario, pero por defecto, los scripts están deshabilitados para root.

Para habilitar el soporte a Lua, necesitamos editar el siguiente script:

sudo nano /usr/share/wireshark/init.lua

y comentar la siguiente función:

-- disable potentialy harmful lua functions when running superuser
--if running_superuser then
    --local disabled_lib = {}
    --setmetatable(disabled_lib,{ __index = function() error("this package has been disabled") end } );

    --dofile = function() error("dofile has been disabled") end
    --loadfile = function() error("loadfile has been disabled") end
    --loadlib = function() error("loadlib has been disabled") end
    --require = function() error("require has been disabled") end
    --os = disabled_lib
    --io = disabled_lib
    --file = disabled_lib
--end

Para comprobar rápidamente si un WebService está funcionando podemos utilizar el comando curl para hacer una petición y obtener la respuesta.

Para ello:

$ curl -d @request.xml http://localhost/soap/service

donde request.xml es el fichero que contiene la petición SOAP.

Actualización: 16/02/2012 0:44

Se me olvidó poner las cabeceras que son necesarias para que todo funcione:

$ curl -d @request.xml -H "SOAPAction: http://localhost/soap/service/action" -H "Content-Type: text/xml; charset=UTF-8" http://localhost/soap/service

Una vez que tenemos OpenWRT instalado en nuestro router llega el momento de habilitar IPv6. Para ello, vamos a utilizar Stateless auto configuration. Para ello necesitaremos hacer uso de IPv4. Aunque todo esto se puede configurar desde LuCI (la interfaz web de administración que usa OpenWRT), usaremos SSH por comodidad.

Hasta ahora, durante el reinado de IPv4, estamos acostumbrados a utilizar DHCP para la configuración de la dirección IP de nuestros equipos. Es rara la situación en la que no haya un servidor DHCP (usalmente en el router) y sea necesario configurar la IP de forma manual.

IPv6 ofrece un mecanismo nuevo: Stateless auto configuration o configuración automática sin estado. De esta forma, los propios dispositivos generan su propia dirección IP.

Tengo en casa un par de routers Comtrend CT-5361 que regalaban antiguamente compañías como Telefónica o Jazztel. Llevo ya unos meses trasteando con IPv6 y me he decidido a montar una red local. Para ello voy a utilizar este router:

Ya que el firmware que traen estos dispositivos no trae soporte para IPv6, he decidido instalar OpenWRT. OpenWRT es una distribución de Linux enfocada a routers.

Hace unos días estuve revisando la configuración de un router NetGear WNDR3300 debido a un mal funcionamiento. La causa resultó ser una serie de ataques DOS que se estaban realizando al router. Estos ataques se estaban realizando desde la propia red local, así que decidí hacerme un script para detectarlos lo antes posibles.

LOG_FILENAME=router.log
USER=admin
PASS=password
IP=192.168.1.1
LOGURL=FW_log.htm

curl -s http://$USER:$PASS@$IP/$LOGURL | grep '^\[.*[0-9]$' > $LOG_FILENAME
attacks="`grep -i 'DOS' $LOG_FILENAME`"
if [ attacks != "" ] ; then
    echo "$attacks"
    # Esta parte no es necesaria, a no ser que se quiera
    # hacer un tratamiento especial para cada IP de forma
    # independiente, cómo averiguar la dirección MAC
    ips=`grep -i 'DOS' $LOG_FILENAME | cut -f7 -d' ' | cut -f1 -d','`
    for ip in $ips
    do
        echo "Hacer algo con esta $ip"
    done
fi

Aquí podemos ver un ejemplo de la salida del script:

[DOS attack: STORM] attack packets in last 20 sec from ip [172.16.0.13], Sunday, Jul 24,2011 21:16:57
[DOS attack: STORM] attack packets in last 20 sec from ip [172.16.0.5], Sunday, Jul 24,2011 21:54:10
[DOS attack: STORM] attack packets in last 20 sec from ip [172.16.0.5], Sunday, Jul 24,2011 21:54:46
[DoS Attack: ACK Scan] from source: 50.99.45.xx, port 64976, Friday, July 29,2011 01:16:26
[DoS Attack: RST Scan] from source: 108.49.85.xx, port 56258, Friday, July 29,2011 01:16:21

Espero que sea de utilidad para alguien :)

Hoy he estado revisando los logs de mi servidor, y me he dado cuenta que llevan 5 días de ataques por fuerza bruta para intentar tener un acceso SSH. Seguro que a alguien le resulta útil este script:

import re
exp = re.compile(r'.*[\s]*sshd\[.*?\]:[\s]*Invalid user.*')
f = open('/var/log/auth.log')
for line in f.readlines():
    if exp.match(line):
        print line[:-1]

Este script nos mostrará todos los accesos fallidos que hay en el servidor. Ahora vamos a ver la forma más sencilla de impedir este tipo de ataques: fail2ban.

Hace ya unas horas que estoy en Glasgow y la verdad es que estoy muy contento, aunque más cansado aún (como véis, no estoy echando la siesta, estoy escribiendo la solución al primer problema en tierra escocesa). He venido a Glasgow a un curso de inglés durante tres semanas con mi novia. Resulta que en el cuarto sólo hay un único cable Ethernet y traemos los dos portátiles. ¿Qué podemos hacer para conectarnos los dos a la vez?