It should work…

Estaba curioseando por foros de Gentoo cuando me encontré un post interesante sobre una evolución del clásico Port-Knocking,  pero vayamos por pasos.

Port-Knocking

Cuando nosotros tenemos un servicio en un servidor, éste, escucha en uno o varios puertos las peticiones externas. Este puerto deberá estar abierto en el firewall para que se puedan efectuar estas conexiones. La idea del Port Knocking es que el puerto del servicio permanece cerrado y sólo se abrirá bajo una petición externa basada en un paquete o grupo de paquetes específicos, previamente conocidos por el cliente, que serán enviados al servidor. Es decir, yo tendría mi servidor ssh con el puerto 22 cerrado y cuando un cliente envíe un paquete con ciertas características a otro puerto entonces el puerto 22 se abriría temporalmente para ese cliente. De este modo permanecería escondido antes escaneos de puertos e intentos automatizados de fuerza bruta, por ejemplo. Este sistema se podría ir mejorando:

• que tenga que ser una secuencia de puertos y no uno sólo
• que además tengan que ser unos puertos de origen específicos
• combinarlo con otras herramientas: Portsentry, denyhost, fail2ban (destaco la primera herramienta  ya que es una forma fácil de banear intentos de escaneos sin el uso de un IDS completo ni cortafuegos)
• jugar con las FLAGs TCP y opciones poco comunes de los paquetes
• abrir el puerto sólo para la IP llamante, no todas
• <paranoic>requerir una temporización determinada (algo elástica, claro está) entre en el envío de los paquetes</paranoic>
• y mil cosas que se nos puedan ocurrir

Para estos menesteres existen varias herramientas pero todo suelen terminar siendo scripts que escuchan los puertos y van cambiando reglas del cortafuegos y los servicios. Pero no todo es bonito e ideal, imaginad que no tienes una puerta trasera, ¿qué ocurre si cae el servicio encargado de escuchar el portknocking? Te quedas tú sin poder acceder. Deberías dejarte una IP blanca por ejemplo, que siempre tuviera acceso al puerto sin mayor barrera. O tener otro servicio que compruebe si el primer servicio está online y haga de watchdog xD.

Pero ¿cuál es la debilidad clave un sistema así? Replay Attack. Me explico, si mi máquina está en una subred y otra máquina de esa subred ha sido comprometida, ésta podría estar usando un sniffer (tcpdump, wireshark) y capturar la secuencia usada para la apertura de puertos. Y aquí es donde entra lo que he venido a contar.

Crypt-Port-Knocking

Vamos a cortar por lo sano esa debilidad: Single Packet Authentication. Esta manera de proceder difiere en que vamos a llamar a un puerto aleatorio cada vez y la conexión con el servicio también se hará en un puerto aleatorio cada vez pero lo que es más importante añadiremos información cifrada en el paquete gracias a OpenSSL con lo que se quiera hacer (en este caso usando 256-bit AES-cbc, se podría mejorar para ultraparanoicos™  usando un cifrado asimétrico con GPG, por ejemplo). Podríamos pensar que para evitar ataques replay en la información cifrada se podría incluir datos variantes en el tiempo, cambios preacordados de la clave de cifrado, usar iteraciones en una función de hashing pero se complica el tema cuando hay muchos usuarios. Para ello, es mejor opción aprovechar que podemos tener 16bytes de datos aleatorios en el paquete que luego podemos identificar gracias a un hash del mismo e ignorar todos los paquetes duplicados. Para crear los paquetes a medida podremos usar hping.

Para hacer uso de las características del Single Packet Authentication el autor del post, BoneKracker, ha creado una serie de scripts en bash, formados por un cliente y un servidor de una forma bastante clara y transparente. Echadle un vistazo que ahí está todo el código y con una explicación más extensa.

–
Fuente original en http://vierito.es/wordpress

Similar Posts:

• Dejar bonito un server SSH – Parte 1
• [Campus Party 08] Taller de antenas y charla sobre servidores
• Dejar bonito un server SSH – Parte 2