25.3.08

SPA (Single Packet Authorization) con fwknop



En este artículo se pretende hacer una introducción al concepto de ‘port knocking’ (técnica que se puede usar como complemento para securizar servicios que se encuentren detrás de un firewall) y más concretamente a una de sus variantes, ‘Single Packet Authorization’ (SPA), mediante un ejemplo práctico guiado paso a paso utilizando fwknop, una implementación de SPA de código abierto, bajo sistemas linux.

Introducción a Port Knocking

En informática, port knocking es un método utilizado para abrir puertos en un firewall mediante un conjunto de intentos de conexión lanzados sobre puertos cerrados. Cuando en el servidor se recibe la secuencia correcta de conexión, las reglas del firewall son modificadas dinámicamente para permitir al host que envió los paquetes conectar a un puerto/s específico/s.

El principal objetivo de port knocking es prevenir escaneos de puertos a un determinado equipo para evitar potenciales ataques a servicios vulnerables. Esto se consigue ya que, a menos que se envíe la secuencia de knocks correcta, los puertos aparecerán como cerrados para cualquiera que lance un escaneo sobre el equipo. Un 'port knocking' es similar a un handshake y consiste en una serie de paquetes TCP, UDP o incluso ICMP dirigidos cada uno a un puerto concreto en la máquina destino. La complejidad del 'knock' puede ir desde una simple lista de paquetes protocolo-puerto hasta un complejo hash encriptado controlado según IP origen y/u otros factores.

Ejemplo: Un demonio sshd configurado por defecto escuchará en el puerto 22. Configuramos el firewall para que cierre el puerto 22 y elegimos como secuencia de 'knocks' la sucesión TCP-100, UDP-200, TCP-300 que habilitará el puerto 22 en la máquina. El puerto permanecerá cerrado hasta que un usuario intente inicializar conexiones TCP y UDP hacia los puertos 100, 200 y 300 en ese mismo orden. En este caso, el puerto se abrirá durante un intervalo de tiempo determinado. En caso contrario, el usuario recibirá un paquete RST/ACK cuando inicialice conexiones TCP hacia el puerto22.


Pero Port Knocking tiene algunas debilidades:

Seguir Leyendo...


- Un atacante que no conozca la secuencia de 'knocks', mediante fuerza bruta, podría llegar a obtener la secuencia requerida para habilitar un determinado servicio.

- Monitorizando las comunicaciones, un atacante podría intentar detectar una secuencia de puertos para reproducirla posteriormente contra el servidor para conseguir acceso al servicio protegido.

- Las secuencias de port knock pueden ser encriptadas y existen diversas implementaciones que se pueden encontrar en www.portknocking.org. Pero cada paquete enviado puede contener sólo dos bytes de información debido al tamaño de 16 bits que tienen los campos de los puertos en las cabeceras TCP y UDP. Por tanto, para enviar una secuencia cifrada, utilizando por ejemplo un algoritmo simétrico de 128 bits, una secuencia de port knock estaría formada por 128/16=8 paquetes. Aquí nos encontramos con un posible problema de entrega desordenada de paquetes ya que en este caso no hay una conexión cliente-servidor (tipo TCP). Se puede añadir un retardo de medio segundo para evitar este problema, y en este caso el tiempo de entrega de la secuencia llegaría a 4 segundos. Pero si se decide utilizar algoritmos de cifrado asimétricos, la cantidad de bits a enviar es más grande y el tiempo de entrega de estos paquete se vuelve excesivo e inviable. Esto puede resultar una gran desventaja del port knocking.

Conclusión: Port knocking provee algunas ventajas que aumentan las seguridad, pero también tiene algunas limitaciones serias que hay que tener en cuenta. SPA (Single Packet Authorization) es un protocolo relativamente nuevo que mantiene los beneficios del port knocking pero soluciona algunas de las limitaciones del mismo.
Las primeras noticias que se tuvo de la implementación de SPA surgieron en Mayo de 2005 como una parte de un software llamado fwknop www.cipherdyne.org/fwknop.

Descripción de SPA (Single Packet Authorization)


SPA es una variante del port knocking donde sólo un 'knock' es necesario para validar la petición. Éste 'knock' consiste en un paquete encriptado.
SPA ofrece una arquitectura similar a la del port cknocking:

  1. Ambos sienen componentes cliente y servidor,
  2. El servidor matiene el control de filtrado por defecto a DROP
  3. El servidor monitoriza paquetes de forma pasiva.
Pero aquí es donde acaban las similitudes.

La principal ventaja que ofrece SPA es que la cantidad de información que puede ser incluída en el paquete sólo se encuentra limitada por el MTU. Esta ventaja permite que mediante SPA se pueda incluir en el paquete no sólo información de acceso, sino también por ejemplo, comandos que sean ejecutados en el sevidor SPA.

En definitiva, SPA provee un nivel de seguridad similar al port knocking en términos de proteger un servicio con un filtrado de paquetes en un sistema con una política por defecto de INPUT a DROP. En este entorno, cualquiera que realice un escaneo a la máquina no sería capaz de detectar si un servicio está realmente activo en ella, lo cual dificulta la explotación de muchas vulnerabilidades. SPA ofrece una solución elegante las limitaciones del port knocking.

Vamos a ver mediante un ejemplo práctico, cómo utilizar fwknop en modo Single Packet Authorization para proteger y ofrecer acceso al demonio OpenSSH.
- fwknop define el siguiente formato de paquete en la capa de aplicación:
  • 16 bytes de datos aleatorios
  • Nombre del usuario cliente
  • Timestamp del cliente
  • Version fwknop
  • Modo (acceso or comando)
  • Acceso (o una cadena de comando)
  • Resumen MD5 /SHA
Una vez que el cliente fwknop contruye el paquete con los campos arriba indicados, el paquete entero es encriptado usando un algoritmo de clave simétrica (128 bits) o asimétrica (utilizando GnuPG con una longitud de clave de 1024 - 4096 ). Por defecto, el cliente enviará un paquete UDP al puerto 62201, aunque esto se puede modificar fácilmente (mediante el uso del parámetro --Server-port)

A continuación se muestra un ejemplo de instalación, configuración y prueba de fwknop:

Tendremos que tener instalado GnuPG tanto en el servidor como en el cliente.

- Instalamos el servidor OpenSSH

# apt-get install openssh-server

- Instalamos los requisitos para fwknop:

# apt-get install build-essential libpcap-dev mailx


- Instalamos fwknop en el servidor:
En este caso, hemos instalado la versión 1.9.2 del 12 de Marzo de 2008

# wget http://www.cipherdyne.org/fwknop/download/fwknop-1.9.2.tar.gz
# tar zxvf fwknop-1.9.0.tar.gz
# cd fwknop-1.9.0
# sudo ./install.pl

- Nos hace una serie de preguntas a las cuales se ha contestado lo siguiente:

In which mode will fwknop be executed on the local system?
(client/[server]): server

Which of the following data acquistion methods would you like to use?
([pcap], file_pcap, ulogd, syslogd, syslog-ng): pcap

Which network interface would you like fwknop to sniff packets from? eth0

Enable fwknop at boot time ([y]/n)? y


- Podemos añadir fwknop al arranque del sistema:

# update-rc.d fwknop defaults 20

- Instalamos fwknop en el cliente:

# apt-get install build-essential libpcap-dev mailx
# wget http://www.cipherdyne.org/fwknop/download/fwknop-1.9.2.tar.gz (12 Mar 2008)
# tar zxvf fwknop-1.9.0.tar.gz
# cd fwknop-1.9.0
# sudo ./install.pl

En este caso, contestamos con las mismas respuestas excepto que indicamos que se instale como cliente.

- Generamos par de claves en el cliente:

# gpg --gen-key

- Nosotros elegimos las siguientes opciones:

  • Tipo -> DSA
  • Tamaño -> 2048
  • Periodo -> La clave no caduca nunca
  • Nombre y apellidos: client fwknop
  • Correo: cf@cf.com

- Obtenemos:

pub   1024D/A174FC70 2008-03-24
uid                  Server fwknop
sub   2048g/3220AE91 2008-03-24

- Exportamos la clave a un fichero

# gpg -a --export A174FC70 > fwknop-client.asc

- Generamos par de claves en el servidor:

# gpg --gen-key

  • Tipo -> DSA
  • Tamaño -> 2048
  • Periodo -> La clave no caduca nunca
  • Nombre y apellidos: Server fwknop
  • Correo: sf@sf.com

- Obtenemos:

pub 1024D/D417D41A 2008-03-09
uid Server fwknop
sub 2048g/F5F02C2B 2008-03-09


- Exportamos la clave a un fichero:

# gpg -a --export D417D41A > fwknop-server.asc

Copiamos los ficheros respectivos en las máquinas e importamos las claves.

- Importamos la clave del servidor en el cliente:

# gpg --import fwknop-server.asc
# gpg --sign-key sf@sf.com

- Importamos la clave del cliente en el servidor:

# gpg --import fwknop-client.asc
# gpg --sign-key cf@cf.com


- Finalizando la instalación:

- Editamos /etc/fwknop/access.conf:

SOURCE: ANY;
OPEN_PORTS: tcp/22;
DATA_COLLECT_MODE: PCAP;
GPG_HOME_DIR: /root/.gnupg;
GPG_DECRYPT_ID: D417D41A;
GPG_DECRYPT_PW: password para la llave D417D41A;
GPG_REMOTE_ID: A174FC70;
FW_ACCESS_TIMEOUT: 30;


- Iniciamos fwknop:

# /etc/init.d/fwknop start

- Prueba de funcionamiento:

- Ejemplo de sintaxis:

fwknop -a 'puertos' --gpg-recip SERVER_KEY --gpg-sign CLIENT_KEY -s -D SERVER_IP

  • Con -s indicamos que el servidor SPA utilice la ip de origen de la cual recibió el paquete para crear la regla.En lugar de -s se puede utilizar -w que realizará una petición a www.whatismyip.com para averiguar la ip origen

- Probamos con:
# fwknop -a 'tcp/22' --gpg-recip D417D41A --gpg-sign A174FC70 -s -D 192.168.6.137




- Si todo ha ido bien, el servidor añade la entrada correspondiente a iptables. Ésta se mantendrá durante 60 segundos, después de los cuales se eliminará automáticamente.
En este caso, nos crea una regla que permite a la IP 192.168.6.137 conexiones tcp al puerto 22.

- Podemos comprobar que todo ha ido bien consultando los logs en el servidor SPA:

# tail -f /var/log/syslog | grep fwknop



- Y cuando se acabe el tiempo disponible para realizar la conexión:




- Podemos consultar las reglas iptables en tiempo real con:

# watch -n1 iptables -L -n








NOTA:

fwknop crea una nueva una nueva cadena en iptables llamada FWKNOP_INPUT y la cadena INPUT hace referencia a ésta.
En el servidor probamos poniendo la política INPUT del iptables por defecto a DROP pero no la cadena OUTPUT. Hay que tener en cuenta que fwknop, por defecto, sólo añade reglas a FWKNOP_INPUT. También se puede habilitar en fwknop.conf para que se cree utilice la cadena
FWKNOP_OUTPUT y así se creará reglas para permitir tráfico OUTPUT.

- Para que se mantenga la conexión SSH que hayamos establecido durante el tiempo permitido, tendremos que tener en iptables una regla que permita las conexiones ya establecidas. Si no, la conexión quedará cortada cuando fwknop elimine la regla correspondiente. En nuestro caso, hemos añadido:

# iptables -A INPUT -p tcp -i eth0 -m state --state ESTABLISHED, RELATED -j ACCEPT


Referencias:

http://www.hispasec.com/unaaldia/3382

http://www.cipherdyne.org/fwknop/

http://mscoder.org/en/haking/articles_html.html

https://help.ubuntu.com/community/SinglePacketAuthorization