Creando un túnel DNS para navegar saltándose un Firewall.

Buenas tardes,

Hace ya algún tiempo publiqué una entrada haciendo referencia a túneling mediante SSH (https://www.bitsdelocos.es/2015/08/tunnel-ssh-con-raspbian-y-bitvisessh/). En esta entrada, versará sobre túneling sobre DNS (Domain Name Server). El concepto es el mismo: sobre un flujo de peticiones DNS insertar consultas forjadas de un modo conveniente parainyectar información de otro protocolo sobre DNS y así saltarse las protección de un firewall. La definición de un túnel en informática es:

Se conoce como túnel o tunneling a la técnica que consiste en encapsular un protocolo de red sobre otro (protocolo de red encapsulador) creando un túnel de información dentro de una red de computadoras.

Para poder llevar a cabo este escenario, necesitaremos:

  • Servidor: VPS o un equipo linux con una IP de internet estática.
  • Cliente: Sistema operativo linux o una máquina virtual con linux en su defecto.
  • Tener control sobre un dominio y sus entradas de DNS.
  • Tener chrome con la extensión SwitchyOmega.

La idea principal se basa en crear un subdominio al que se le harán las peticiones de DNS y un NS (Name Server o Servidor de nombres) al que enviar las peticiones malformadas. Necesitaremos añadir la siguiente configuración en nuestro DNS público:

  • tunel.bitsdelocos.es (NS apuntando a ns.bitsdelocos.es)
  • ns.bitsdelocos.es (A apuntando a la IP del VPS)

De este modo se conseguirá que todas las peticiones DNS del tipo xxxx.tunel.bitsdelocos.es se envíen a ns.bitsdelocos.es. Lo siguiente que necesitamos es montar un servidor de nombres que haga la función de resolver de paquetes generados maliciosamente que le lleguen. En este caso usaremos iodine (https://github.com/yarrick/iodine) . He usado debian 9 base como servidor de DNS. Para hacer el build de iodine necesitaremos ejecutar como super usuario:

apt-get install gcc make autoconf libz-dev git
git clone https://github.com/yarrick/iodine.git
cd iodine
make && make install

Si todo ha ido bien iodine estará instalado en nuestro sistema:

root@Debi:~# iodine -v
iodine IP over DNS tunneling client
Git version: 27e5d6f

Para hacer funcionar este servidor de DNS bastará con ejecutar:

iodined -c -P <PASSWORD> -n <IP ESTATICA> 172.16.0.1 tunel.bitsdelocos.es -F /var/run/iodine.pid

En el caso de que estemos usando la red local 172.16.0.0/24 podremos cambiar este rango por uno que no estemos usando.

Para comprobar que todo salió bien, se puede ejecutar el comando ip addr show para ver si se asignó una ip a la interfaz virtual dnsX:

root@Debi:~# ip addr show dev dns0
11: dns0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1130 qdisc pfifo_fast state UNKNOWN group default qlen 500
    link/none 
    inet 172.16.0.1/27 scope global dns0
       valid_lft forever preferred_lft forever

En nuestro PC debemos ejecutar el cliente que nos levantará el túnel contra el NS ns.bitsdelocos.es haciendo uso de resoluciones DNS al subdominio tunel.bitsdelocos.es. Para ello lanzaremos iodine en el cliente del siguiente modo:

iodine  -P <PASSWORD> <IP DNS FORWARDER> tunel.bitsdelocos.es -F /var/run/iodine.pid

Donde es la ip del forwarder que use la red a la que estamos conectados o bien un servidor externo como el NS de google (8.8.8.8). Si no ha habido errores se podrá levantar un proxy SOCKS5 con el comando SSH:

ssh -fN -D *:8080 root@172.16.0.1

La IP 172.168.0.1 es la ip que se le habrá asignado a la interfaz dnsX en el servidor.

Para comprobar que todo ha ido bien se debe instalar el plugin switchy omega en el navegador chrome y configurarlo:

La IP que aparece en la captura es la ip de la máquina virtual donde se está ejecutando el cliente de iodine.

Para comprobar si ha ido bien la configruación del proxy, debemos abrir una web y con F12 inspeccionar la ip remota de la página abierta, si corresponde con la ip de nuestro proxy significa que habrá funcionado.

Se ha configurado Switchy omega con Chrome.

Otro modo de comprobar si funciona es usando CURL en un terminal linux

[root@localhost ~]# curl --socks5-hostname  127.0.0.1:8080 www.bitsdelocos.es -v
* About to connect() to proxy 127.0.0.1 port 8080 (#0)
*   Trying 127.0.0.1...
* Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: www.bitsdelocos.es
> Accept: */*
> 
< HTTP/1.1 302 Found
< Server: openresty
< Date: Sun, 21 Oct 2018 15:52:40 GMT
< Content-Type: text/html; charset=iso-8859-1
< Content-Length: 211
< Connection: keep-alive
< Location: https://www.bitsdelocos.es/

Este método de túneling es mucho menos efectivo que el túnneling por ssh ya que el overhead introducido es mucho mayor.

Shaping con nginx: Limitando CPS (II)

Hace unos días, se me planteó el problema de limitar las CPS (conexiones por segundo a un servicio de APIs externo), por lo que mi primera idea fue limitarlo en el proxy de salida de los servidores (SQUID). Pero eso implicaba cambiar y tunear las IPtables de una forma poco dinámica ya que si el proveedor está en una CDN habría que montar un proceso de actualización de reglas,.. o bien limitarlo para todas las salidas externas del proxy con lo que no resultaba ser una buena opción así que seguí buscando,… en este caso encontré nginx como proxy inverso con el módulo limit_req_zone que permite hacer rate limiting de peticiones.

Siguiendo el esquema de la entrada anterior (Shaping con Iptables: Limitando CPS):

Y la misma arquitectura de pruebas:

Nombre del Servidor IP Descripción
shaper01 10.112.112.101 Nginx Reverse Proxy
webserver01 10.112.112.102 Servidor web con nginx
server01 10.112.112.106 Envío de tráfico

Para simplificar configuraciones, y la lectura de los scripts se han hecho 2 suposiciones.

  1. Tenemos acceso privilegiado a la máquina (sudo -i) o similar.
  2. En el archivo de hosts (/etc/hosts) de cada máquina se ha añadido lo siguiente:
    10.112.112.101 shaper01
    10.112.112.102 webserver01
    10.112.112.106 server01
    

Para las pruebas se ha habilitado la siguiente zona en nuestro nginx (/etc/nginx/conf.d/rate-limit.conf):

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;
server {
    listen       80;
    server_name  shaper01;
    location / {
       limit_req zone=mylimit;
       proxy_set_header Host "webserver01";
       proxy_pass http://webserver01;

    }
}

En esta zona se indica que todas las peticiones con el server_name “shaper01”, en la ruta / e hijas se aplicará un rate-limiting de 10r/s, y tras aplicar esta limitación serán reenviadas las peticiones contra el servidor webserver01.

El único cambio que hay que hacer en el programa cliente es la url dónde apuntarán sus peticiones, en este caso, se deberán abrir contra el servidor shaper01 en lugar del endpoint de la API.

Las pruebas se han lanzado con curl igual que en la entrada anterior:

while [ 1 ]; do curl shaper01 -s > /dev/null; done

Tras analizar los resultados del nginx del server web, podemos afirmar que está funcionando el rate-limiting.

Conexiones Por segundo usando nginx

Shaping con Iptables: Limitando CPS

Buenas noches, después de mucho tiempo sin pasarme por aquí, esta noche os traigo una pequeña entrada para ver como se puede configurar un rate limiting (shaping) en función de las conexiones por segundo en lugar del por ancho de banda (bandwidth).

Durante el transcurso de esta semana, me han consultado si se podría limitar el consumo de una API REST de un proveedor externo a priori no debería ser mucho problema, cuando te piden esto lo primero que piensas es en limitar el ancho de banda consumido en un packetshaper/firewall aplicando políticas de QoS. Pero esta vez, se solicitó que se limitara por transacciones por segundo permitidas. Tras revisarlo con los compañeros nunca habíamos montado nada así por lo que me he dispuesto a investigar un poco más y he llegado la solución que os contaré en este post.

En la siguiente imagen se describe la arquitectura inicial, en el recuadro rojo se muestra que existen N instancias de una aplicación que competirán por 10 conexiones por segundo contra la API externa (verde).


Sigue leyendo

Integración OSSIM – Elasticsearch

Qué es ossim?

El software de seguridad OSSIM, del inglés Open Source Security Information Management, es un conjunto de herramientas de seguridad (recogida de logs, monitorización, escaneo de vulnerabilidades,…) orquestadas para conseguir una solución de seguridad capaz de correlacionar y detectar eventos de seguridad y vulnerabilidades en una infraestructura determinada.

Tras haber gestionado ossim, me he dado cuenta que la integración de OSSIM con el mundo exterior es algo complicada.. expresiones regulares, creación de nuevos plugins, tener que pasar siempre por syslog,… Para evitar estos problemas se ha desarrollado un nuevo datasource de ossim para permitir la integración de OSSIM con elasticsearch.

El código se encuentra en mi repositorio público:

https://github.com/berni69/ossim-agent-elasticsearch

El código que se debe añadir a ossim es:

ParserElastic.py
ElasticDetector.py

Además se debe modificar el componente Agent.py (línea 559 aprox) para añadir un nuevo tipo de datasource.

                elif plugin.get("config", "source") == "elasticsearch":
                    parser = ParserElastic(self.conf, plugin, None)
                    parser.start()
                    self.detector_objs.append(parser)

Para que esto funcione se debe añadir la librería de elasticsearch para python:

pip install elasticsearch

Ejemplo de configuración:

https://raw.githubusercontent.com/berni69/ossim-plugins-elasticsearch/master/elasticsearch-example.cfg

Mantén tus dispositivos actualizados con Ansible

Si te gusta cacharrear como a mi, al final terminas teniendo varios dispositivos conectados a la red de tu casa y otros tantos distribuidos en el cloud, una de las tareas más tediosas a las que te puedes enfrentar es irlos actualizado a medida que pasa el tiempo. No a todos estos dispositivos me conecto habitualmente por lo que no siempre recuerdo actualizarlos, para solucionar esto he decidido que voy a usar Ansible. Esta pieza de software se define como:

Ansible es categorizado como una herramienta de orquestación. Maneja nodos a través de SSH y no requiere ningún software remoto adicional (excepto Python 2.4 o posterior para instalarlo). Wikipedia

Para poder instalar Ansible es necesario disponer de Pip y Python en nuestro sistema. Yo lo decidí instalar en mi Raspberry Pi por lo que además tuve que instalar software adicional:

apt-get update
apt-get upgrade python
apt-get install libssl-dev libffi5-dev python-dev build-essential
cd /tmp/
wget wget https://bootstrap.pypa.io/get-pip.py
python get-pip.py
pip install ansible

Dependiendo de la velocidad de la tarjeta SD de tu Raspberry Pi y la versión de ésta, puede tardar casi una hora en instalar todo el software necesario.

Una vez instalado el software, debemos crear el inventario de máquinas en /etc/ansible/hosts

mkdir /etc/ansible/
touch /etc/ansible/hosts

En mi caso voy a crear un grupo de servidores llamado servers que contiene un servidor vps y 2 raspberrys:

[servers]
mivps.example.com   ansible_connection=ssh  ansible_user=root
rpi1                ansible_connection=local #Host donde ejecuto ansible
rpi2                ansible_connection=ssh  ansible_user=pi    ansible_host=192.168.1.13

Donde la primera columna es el nombre del dispositivo al que nos vamos a conectar, ansible_host es la ip en el caso de que el nombre no se pueda resolver por dns y ansible_user es el usuario que usará ansible para conectarse al dispositivo.

Habitualmente, si no se especifica lo contrario, ansible intentará usar la clave ssh del usuario local para conectarse a los servidores remotos, si el usuario no tiene ninguna clave ssh generada, la crearemos.

mkdir $HOME/.ssh
chmod 600 $HOME/.ssh
ssh-keygen -t ecdsa -C "miusuario@miequipo"

Este proceso debe generar 2 claves (pública y privada) llamadas ~/.ssh/id_ecdsa.pub y ~/.ssh/id_ecdsa. Debemos copiar la clave pública (.pub) en el archivo authorized_keys del servidor remoto, para ello ejecutaremos el comando:

ssh-copy-id -i ~/.ssh/id_ecdsa root@mivps.example.com

Si queremos probar que se han copiado las claves ssh correctamente y tenemos acceso podemos ejecutar el comando

root@rpi1:~# ansible servers -m ping
mivps.example.com | SUCCESS => {
    "changed": false, 
    "ping": "pong"
}
rpi1 | SUCCESS => {
    "changed": false, 
    "ping": "pong"
}
rpi2 | SUCCESS => {
    "changed": false, 
    "ping": "pong"
}

Si todos los hosts aparecen como success, es que la instalación de claves ha ido correctamente.

Una vez copiadas todas las claves en los servidores, debemos crear el archivo /etc/ansible/update.yml:

---

- hosts: servers
  become: true
  become_user: root
  become_method: sudo
  tasks:
    - name: Update packages list [APT]
      apt: update_cache=yes
      when: ansible_os_family == 'Debian'
    - name: Upgrade packages [APT]
      apt: upgrade=safe
      when: ansible_os_family == 'Debian'
    - name: Upgrade packages [YUM]
      yum:
        name: '*'
        state: latest
        update_cache: yes
      when: ansible_os_family == 'RedHat'

Para finalizar, debemos lanzar el comando

root@rpi1:~# ansible-playbook /etc/ansible/update.yml

PLAY [servers] *********************************************************************************************************************************************************************************************

TASK [Gathering Facts] *************************************************************************************************************************************************************************************
ok: [mivps.example.com]
ok: [rpi2]
ok: [rpi1]

TASK [Update packages list] ********************************************************************************************************************************************************************************
changed: [mivps.example.com]
changed: [rpi2]
changed: [rpi1]

TASK [Upgrade packages] ************************************************************************************************************************************************************************************
changed: [mivps.example.com]
changed: [rpi1]
changed: [rpi2]

PLAY RECAP *************************************************************************************************************************************************************************************************
mivps.example.com          : ok=3    changed=2    unreachable=0    failed=0   
rpi1                       : ok=3    changed=2    unreachable=0    failed=0   
rpi2                       : ok=3    changed=2    unreachable=0    failed=0   

Si todos los hosts aparecen como 0 failed y 0 unreachable es que la ejecución del script ha ido correctamente.

Reiniciando automáticamente el router CG6640E

Desde hace un tiempo el router de ONO me falla cuando hace más de una semana que no se ha reiniciado, por lo que cada X tiempo me tenía que acordar de reiniciarlo para no quedarme sin servicio durante algún hito importante.

Trasteando un poco he visto que en su firmware existía una página que estaba oculta en los menús:

http://192.168.x.1/modem_configuration.html

Esta página, además de permitirte hacer un reset de fábrica del aparato, te permite cambiar las frecuencias favoritas del CM y hacer un reboot del dispositivo:

Configuración avanzada del modem de ONO

Con lo que con un poco de ayuda de las herramientas de desarrollador de google y unos cuantos reinicios del dispositivo he podido ver que estaba ejecutando por debajo:

http://192.168.x.1/setRestartCM.html

Eso es un avance, llamando a esa url se reinicia el módem siempre que haya un usuario logeado en el módem desde la IP que llama.

Por lo que he tenido que investigar como hacer login en el dispositivo, es un mecanismo muy sencillo que no usa ni cookies ni tokens ni sesiones, solo depende de la IP de origen de la petición:

http://192.168.x.1/login/Login.txt?password=xxxx&user=admin

Una vez hecho login la petición de login, el router devolverá el nombre del usuario si ha sido correcto o false si no ha funcionado el login.

Para finalizar, sólo es necesario hacer una petición http a cualquier html para que el reinicio se ejecute correctamente.

Si juntamos todos estos requisitos, queda el siguiente script en bash:


#!/bin/bash

USER="admin"
PASSWORD='password'
HOST="192.168.x.1"

#Login

echo "[+] Loging"

curl -v -G -XGET "http://${HOST}/login/Login.txt" --data-urlencode  "password=${PASSWORD}" --data-urlencode  "user=${USER}"


#Reboot
sleep 4
echo "[+] Rebooting"
curl -0 -v -XGET  "http://${HOST}/setRestartCM.html"

# Fake HTML

sleep 1
echo "[+] Sending Fake HTML"
curl -0 -v -XGET  "http://${HOST}/index.html"

Con un crontab para ahorrarnos el trabajo, quedaría un script capaz de reiniciar automáticamente el router con la frecuencia que le digamos.