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.
,
como la inclusión de la IP de origen dentro del paquete cifrado, lo
que
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)
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
