Llamada de puerto ¿es una buena idea?

Aunque todavía no lo he implementado, conozco a muchas personas que lo han implementado. Cada uno de ellos ha notado una reducción significativa en la cantidad de ancho de banda consumido por cosas como los ataques de fuerza bruta SSH como resultado.

Sin embargo, eso no quiere decir que no haya inconvenientes. AFAIK, no hay implementaciones de eliminación de puertos basadas en el kernel disponibles, lo que para mí sería la verdadera clave para la adopción. Los demonios de detonación de puertos se basan en la lectura de entradas de archivos de registros fallidos (filtrados / prohibidos) de un sistema de firewall. Todo eso está bien y elegante, pero ¿qué sucede si el sistema de archivos se llena? ¿Qué sucede cuando el demonio muere debido a algún proceso fuera de control que se comió la memoria RAM y el intercambio del sistema? ¿Qué sucede si algo más de lo que cualquiera de estas dos cosas depende solo de arriba y deja de trabajar? Es muy probable que termines con un servidor al que tendrás que acceder físicamente. Eso podría terminar siendo más costoso de lo que es razonable, especialmente si está a más de unas pocas decenas de kilómetros de distancia del servidor y no tiene a nadie a quien pueda llamar para llegar rápidamente.

Una cosa que puedo decir es que no es "seguridad a través de la oscuridad". La detonación de puertos es una forma de autenticación, y como cualquier sistema de autenticación, puede ser tan simple o complejo como se desee. Se puede hacer algo tan simple como "knock on port 10,000 + realPortNumber", lo que equivaldría a una ruptura trivial, o el mismo knockping del puerto podría usarse para transmitir alguna forma de autenticación real (por ejemplo, 1 bloque de datos codificados AES dado un Clave derivada por algún otro método). Sin embargo, no sería factible utilizar la función de detonación de puertos para transmitir grandes cantidades de datos, ya que tomaría mucho más tiempo que solo enviar un único paquete, y si el paquete está sobre TCP, se puede saber si se recibió con éxito. o encontré alguna forma de error.

Sin embargo, una pregunta interesante que se plantea es cómo administrar los archivos de registro: las implementaciones de los usuarios en su mayoría requieren los archivos de registro para determinar si se ha enviado o no una detonación, y qué sucede si esos registros se filtran? Los datos de autenticación se conocen, y eso obviamente no es algo muy bueno.

No puedo decirte si usar o no el puerto en tu configuración. Todavía no lo estoy, y no estoy 100% seguro de que alguna vez lo esté. Para mí, tiene más sentido utilizar sistemas de autenticación sólidos basados en criptografía sólida (como una infraestructura PKI) que hacer que los puertos no funcionen. Además, agregar de todos modos un punto único de falla para acceder a la infraestructura crítica, me parece una mala idea y es mucho más difícil de respaldar adecuadamente con cualquier tipo de garantía. Sin embargo, una vez más, esto se basa en la noción de que el software de eliminación de puertos no está integrado con el cortafuegos en el nivel del kernel del sistema operativo; si eso cambia alguna vez, también puedo cambiar lo que siento al usarlo.

El bloqueo de puertos no es solo otra contraseña de texto simple, al menos cuando se usa para proteger servicios que escuchan en un puerto TCP como SSH. La detonación de puertos implica que el descubrimiento de servicios con nmap ya no es posible debido al uso de una política de cortafuegos predeterminada. SSHD también ha tenido vulnerabilidades que se pueden explotar de forma remota, y éstas no tienen nada que ver con contraseñas débiles. No quiero que nadie pueda activar nmap y ver que tengo SSHD escuchando.

También, hay una variante más fuerte de la eliminación de puertos llamada "Autorización de paquete único", pero también es un esquema de autenticación completamente pasivo, por lo que conserva los beneficios de la activación de puertos pero resuelve sus limitaciones (los ataques de repetición son fáciles, los ataques DoS fácil, etc.).

Es un hecho fácilmente verificable que todos los servicios de Internet tienen vulnerabilidades de seguridad con relativa frecuencia: servicios como SSH, OpenSSL, etc. / p>

La detonación de puertos, en mi opinión, tiene el propósito de mantener alejados a estos atacantes aleatorios de Internet, que buscan vulnerabilidades genéricas. Es decir, se supone que no debe alejar a un atacante dedicado ni formar parte de la seguridad real de los servicios. El beneficio de las detonaciones en los puertos debería ser que, en realidad, sería lo suficientemente simple como para que no sea probable que haya errores explotables, nunca.

Este uso significa que la detonación de puertos puede ser tan laxa como sea posible, siempre que mantenga a la mayoría de los atacantes. puede ser solo seguridad por oscuridad, pero una mejor manera es tenerlo como una forma débil de autenticación de "contraseña".

Por lo tanto, el "mejor" servicio de detonación de puertos sería uno contra el que es inconcebible imaginar cualquier ataque contra, pero sería lo suficientemente trivial para que cualquier usuario legítimo lo use desde cualquier tipo de máquina cliente.

La detonación de puertos no es seguridad a través de la oscuridad. Es defensa en profundidad. Es como estacionar el auto junto a un auto con mayor capacidad de sellado: no hará mucho para evitar un ataque dirigido, pero podría enviar a los oportunistas que miren en la otra dirección.

Según mis comentarios en otros lugares, aunque hay muchas implementaciones que usan todo tipo de trucos especiales para responder a la llamada, puede implementarse puramente utilizando iptables en un sistema Linux. es decir, esto es efectivamente una implementación de eliminación de puertos basada en el kernel

Dado que la detonación es visible en la red, el uso de secuencias de más de 3 detonaciones ofrece poco beneficio. Recomiendo el uso de TCP: aunque será más lento, tiene mejores garantías de que se envió la llamada.

Sin embargo, aunque se basa en programas de espacio de usuario, mi preferencia es para fail2ban ya que no requiere más Los pasos / software para conectar, se ejecutan de manera confiable, y si fallara, no me impediría acceder a los servidores.

Me sorprende que haya tan poca adopción de identidades encriptadas, aunque RFC1413 simplemente menciona este posible enfoque utilizando el protocolo en lugar de definir cómo debería funcionar.

Pero, por supuesto, debe asegurarse de que haya restringido el acceso tanto como sea posible independientemente de esto (es decir, que no haya un inicio de sesión de root, que restrinja el acceso al grupo designado, si es práctico, que requiera pares de claves). SSH está diseñado para ser seguro, e históricamente ha habido relativamente pocas vulnerabilidades en las implementaciones principales. La razón por la cual los ataques son exitosos generalmente se debe a una combinación de nombres de usuario contables, contraseñas simples y ataques de fuerza bruta o ingeniería social. Tenga en cuenta que no estoy recomendando que aplique una validación de frase de contraseña compleja (que no sea la longitud mínima) ni que requiera que los usuarios cambien sus contraseñas, existen mejores enfoques (por ejemplo, dos factores), pero desafortunadamente hay muy pocas implementaciones.

No he implementado la detonación de puertos en varios años, sin embargo, sospecho que, en principio, no ha cambiado significativamente. Otros comentarios contienen muchos puntos válidos y no los repetiré aquí simplemente.

Uno de los aspectos de las detonaciones de puertos que siempre implementé es basar la secuencia de detonaciones en un valor pseudoaleatorio pero repetible, como la fecha y la hora actuales. Esta estrategia no elimina por completo el peligro de un ataque de repetición, sin embargo, limita la exposición de una secuencia de detonación dada. Obviamente, para que esto tenga éxito, se requiere una hora sincronizada, en mi ejemplo, la fuente sería necesaria para la coherencia.

Port Knocking es solo otra contraseña de texto sin formato. Puede ser forzado, descubierto, capturado y reproducido como cualquier otra contraseña de texto sin formato. ¿Por qué reinventar los inicios de sesión de telnet?

Tienes que confiar en algo. Entonces asumamos que confía en la pila de redes de su sistema operativo y confía en sshd cuando se ejecuta con compresión diferida, separación de privilegios y solo permite alguna forma razonable de autenticación de dos factores (por ejemplo, basada en clave).

Puede usar servicios "simples" como sshd que invoca authpf para proteger sus servicios más complejos y vulnerables.

authpf le permite modificar sus conjuntos de reglas de firewalls en función de quién se autentica correctamente contra sshd, por lo que solo las direcciones IP que logran iniciar sesión en sus puertas de enlace ssh pueden conectarse a su compilación / compute / conjunto de bases de datos.