mrash/fwknopAutorización de un solo paquete > Golpeo de puertos
fwknop implementa un esquema de autorización conocido como Autorización de Paquete Único (SPA, por sus siglas en inglés) para un fuerte ocultamiento de servicios. SPA requiere solo un único paquete que está cifrado, no reproducible y autenticado mediante un HMAC para comunicar el acceso deseado a un servicio que está oculto detrás de un cortafuegos en una postura de filtrado por defecto de denegar. La aplicación principal de SPA es utilizar un cortafuegos para denegar todos los intentos de conexión a servicios como SSH con el fin de dificultar la explotación de vulnerabilidades (tanto de día cero como código sin parchear). Debido a que no hay puertos abiertos, cualquier servicio oculto por SPA naturalmente no puede ser escaneado con Nmap. El proyecto fwknop es compatible con cuatro cortafuegos diferentes: iptables, firewalld, PF e ipfw en Linux, OpenBSD, FreeBSD y Mac OS X. También hay soporte para scripts personalizados para que fwknop pueda adaptarse a otras infraestructuras como ipset o nftables.
SPA es esencialmente la siguiente generación de Port Knocking (PK), pero resuelve muchas de las limitaciones mostradas por PK mientras conserva sus beneficios principales. Las limitaciones de PK incluyen una dificultad general para protegerse contra ataques de repetición, los cifrados asimétricos y esquemas HMAC generalmente no son posibles de soportar de manera confiable, y es trivialmente fácil montar un ataque DoS contra un servidor PK simplemente falsificando un paquete adicional en una secuencia PK mientras atraviesa la red (convenciendo así al servidor PK de que el cliente no conoce la secuencia adecuada). Todas estas deficiencias son resueltas por SPA. Al mismo tiempo, SPA oculta servicios detrás de una política de cortafuegos de denegar por defecto, adquiere datos SPA de forma pasiva (generalmente a través de libpcap u otros medios) e implementa operaciones criptográficas estándar para la autenticación y el cifrado/descifrado de paquetes SPA.
Los paquetes SPA generados por fwknop aprovechan HMAC para el cifrado autenticado en el modelo de cifrar-luego-autenticar. Aunque el uso de HMAC es actualmente opcional (habilitado mediante la opción de línea de comandos --use-hmac), es altamente recomendado por tres razones:
La razón final anterior es por qué se debería seguir usando HMAC incluso cuando los paquetes SPA se cifran con GnuPG, debido a que los datos SPA no se envían a través de las funciones de libgpgme a menos que el HMAC se verifique primero. GnuPG y libgpgme son cuerpos de código relativamente complejos, y por lo tanto limitar la capacidad de un posible atacante para interactuar con este código a través de una operación HMAC ayuda a mantener una postura de seguridad más sólida. Generar un HMAC para comunicaciones SPA requiere una clave dedicada además de la clave de cifrado normal, y ambas pueden generarse con la opción --key-gen.
fwknop cifra los paquetes SPA ya sea con el cifrado de bloque Rijndael o mediante GnuPG y su cifrado asimétrico asociado. Si se elige el método de cifrado simétrico, como es habitual, la clave de cifrado se comparte entre el cliente y el servidor (consulte el archivo /etc/fwknop/access.conf para más detalles). La clave de cifrado real utilizada para el cifrado Rijndael se genera mediante el algoritmo estándar de derivación de claves PBKDF1, y se establece el modo CBC. Si se elige el método GnuPG, las claves de cifrado se derivan de los anillos de claves de GnuPG.
Las personas que utilizan Autorización de Paquete Único (SPA) o su primo con problemas de seguridad Port Knocking (PK) suelen acceder a SSHD ejecutándose en el mismo sistema donde está desplegado el software SPA/PK. Es decir, un cortafuegos en un host tiene una política de denegar por defecto contra todas las conexiones SSH entrantes para que SSHD no pueda ser escaneado, pero un demonio SPA reconfigura el cortafuegos para otorgar acceso temporal a un cliente SPA autenticado pasivamente:
"Uso básico de SPA para acceder a SSHD"
fwknop soporta lo anterior, pero también va mucho más allá y hace un uso robusto de NAT (para cortafuegos iptables/firewalld). Después de todo, los cortafuegos importantes suelen ser pasarelas entre redes, en lugar de estar simplemente desplegados en hosts independientes. NAT se usa comúnmente en tales cortafuegos (al menos para comunicaciones IPv4) para proporcionar acceso a Internet a redes internas que están en el espacio de direcciones RFC 1918, y también para permitir que hosts externos accedan a servicios alojados en sistemas internos.
Debido a que fwknop se integra con NAT, SPA puede aprovecharse para acceder a servicios internos a través del cortafuegos por parte de usuarios en Internet externo. Aunque esto tiene muchas aplicaciones en redes tradicionales modernas, también permite que fwknop soporte entornos de computación en la nube como Amazon AWS:
"Uso de SPA en entornos de nube Amazon AWS"
La interfaz de usuario oficial multiplataforma del cliente fwknop fwknop-gui (descarga, github) es desarrollada por Jonathan Bennett. Se soportan la mayoría de los modos SPA del lado del cliente, incluyendo solicitudes NAT, claves HMAC y Rijndael (GnuPG aún no es compatible), guardado de estrofas fwknoprc y más. Actualmente fwknop-gui funciona en Linux, Mac OS X y Windows. Aquí hay una captura de pantalla desde OS X:
"fwknop-gui en Mac OS X"
De manera similar, un cliente Android actualizado también está disponible.
Se puede encontrar un tutorial completo sobre fwknop aquí:
http://www.cipherdyne.org/fwknop/docs/fwknop-tutorial.html
La siguiente es una lista completa de características compatibles con el proyecto fwknop:
tcpdump -w <file>), desde el escritor pcap de iptables ULOG, o directamente mediante un socket UDP en modo --udp-server.El proyecto fwknop se publica como software de código abierto bajo los términos de la GNU General Public License (GPL v2) o (a su opción) cualquier versión posterior. La última versión se puede encontrar en http://www.cipherdyne.org/fwknop/
Este archivo README describe el estado actual del proyecto fwknop a partir de la versión 2.5 publicada en julio de 2013. En la actualidad, tenemos una implementación de la biblioteca Firewall Knock Operator; libfko, así como las aplicaciones cliente y servidor de fwknop. La biblioteca proporciona la API y la funcionalidad de back-end para gestionar los datos de Autorización de Paquete Único (SPA) que emplean los otros componentes de fwknop. También puede ser utilizada por otros programas que necesiten funcionalidad SPA (consulte el directorio perl para el módulo perl FKO como ejemplo, y también hay enlaces de python en el directorio python).
Si está actualizando desde una versión anterior de fwknop (y esto incluye la implementación original en perl), entonces querrá leer el siguiente enlace para garantizar una transición fluida a fwknop-2.5 o posterior:
http://www.cipherdyne.org/fwknop/docs/fwknop-tutorial.html#backwards-compatibility
Esta distribución utiliza GNU autoconf para configurar la construcción. Consulte el archivo INSTALL para conocer los conceptos básicos generales sobre el uso de autoconf.
Hay algunas opciones de "configure" que son específicas de fwknop. Son (extraídas de ./configure --help):
--disable-client No construir el componente cliente de fwknop. El
valor predeterminado es construir el cliente.
--disable-server No construir el componente servidor de fwknop. El
valor predeterminado es construir el servidor.
--with-gpgme soporte para cifrado gpg usando libgpgme
[predeterminado=check]
--with-gpgme-prefix=PFX prefijo donde está instalado GPGME (opcional)
--with-gpg=/path/to/gpg Especificar la ruta al ejecutable gpg que usará gpgme
[predeterminado=check path]
--with-firewalld=/path/to/firewalld
Especificar la ruta al ejecutable de firewalld
[predeterminado=check path]
--with-iptables=/path/to/iptables
Especificar la ruta al ejecutable de iptables
[predeterminado=check path]
--with-ipfw=/path/to/ipfw
Especificar la ruta al ejecutable de ipfw [predeterminado=check
path]
--with-pf=/path/to/pfctl
Especificar la ruta al ejecutable de pf [predeterminado=check
path]
--with-ipf=/path/to/ipf Especificar la ruta al ejecutable de ipf [predeterminado=check
path]
Ejemplos:
./configure --disable-client --with-firewalld=/bin/firewall-cmd
./configure --disable-client --with-iptables=/sbin/iptables --with-firewalld=no
Para aquellos que actualmente usan la versión Perl y planean migrar a esta versión, hay algunas cosas a tener en cuenta:
No todas las características y funcionalidades del fwknop basado en Perl se trasladaron a esta implementación. Consideramos importante mantener la versión C lo más ágil y ligera posible. La mayoría de las funciones/características omitidas (como las alertas por correo electrónico) se pueden lograr por otros medios (por ejemplo, usar un script externo para monitorear archivos de registro y alertar basándose en mensajes de registro apropiados).
Hay algunas diferencias en las directivas y valores de los archivos de configuración y acceso de fwknop. Algunas de estas son bastante sutiles. Debe prestar atención cuidadosa a la documentación y los comentarios en esos archivos.
Si está obteniendo esta distribución desde git, debe ejecutar el script autogen.sh para generar los archivos autoconf. Si obtiene errores sobre directorios o archivos faltantes, intente ejecutar autogen.sh nuevamente. Después de eso, puede ejecutar autoreconf -i cuando desee regenerar la configuración. Si, por alguna razón, autoreconf no funciona para usted, el script autogen.sh debería ser suficiente.
Las fuentes nroff de las páginas de manual de fwknop y fwknopd están incluidas en sus respectivos directorios (cliente y servidor). Estos archivos nroff se derivan de las fuentes asciidoc en el directorio 'docs'. Consulte el README en docs para obtener más detalles.