La idea errónea que tienes es que la seguridad a través de la oscuridad es mala. En realidad no lo es, la seguridad solo a través de la oscuridad es terrible.

Ponlo de esta manera. Desea que su sistema esté completamente seguro si alguien supiera su funcionamiento completo, además del componente secreto clave que usted controla. La criptografía es un ejemplo perfecto de esto. Si confías en que "no veas tu algoritmo" utilizando algo como un cifrado ROT13 es terrible. Por otro lado, si pueden ver exactamente el algoritmo utilizado pero aún no pueden hacer prácticamente nada, vemos la situación de seguridad ideal.

Lo que hay que tener en cuenta es que nunca quieres contar con la oscuridad pero ciertamente nunca duele . ¿Debo proteger con contraseña / usar claves para mi conexión SSH? Absolutamente. ¿Debo confiar en cambiar el servidor del 22 al puerto 2222 para mantener segura mi conexión? Absolutamente no. ¿Es malo cambiar mi servidor SSH al puerto 2222 mientras también utilizo una contraseña? No, en todo caso esta es la mejor solución. Cambiar ("oscurecer") el puerto simplemente reducirá un montón de escáneres de exploits automáticos que buscan puertos normales. Obtenemos una ventaja de seguridad a través de la oscuridad que es buena, pero no estamos contando en la oscuridad. Si lo encontraron todavía tienen que descifrar la contraseña.

TL; DR: solo contar con la oscuridad es malo. Desea que su sistema esté seguro con el atacante sabiendo que funciona completamente aparte de información secreta específicamente controlable (es decir, contraseñas). La oscuridad en sí misma, sin embargo, no es mala, y en realidad puede ser algo bueno.

Editar: para responder de manera más precisa a tu pregunta de probabilidad, sí, de una manera que puedas verla así, y al mismo tiempo apreciar las diferencias. Los puertos van desde 1-65535 y se pueden revisar rápidamente en 1 minuto con un escáner como nmap. "Adivinar" una contraseña aleatoria de 10 dígitos de todos los caracteres ascii es 1 / 1.8446744e + 19 y llevaría 5,8 millones de años adivinando 100,000 contraseñas por segundo.

Edit 2: Para abordar el comentario a continuación. Se pueden generar claves con suficiente entropía para que se consideren verdaderamente aleatorias ( enlace ). Si no, es una falla con la implementación en lugar de la filosofía. Tienes razón al decir que todo depende de que los atacantes no conozcan información (contraseñas) y que la definición de oscuridad del diccionario sea "El estado de ser desconocido", por lo que puedes decir correctamente que todo cuenta con un nivel de oscuridad.

Una vez más, aunque el valor se reduce a la seguridad práctica dada la información que puedes controlar, permanece desconocido. Las claves, ya sean contraseñas o certificados, etc., son (relativamente) simples de mantener en secreto. Los algoritmos y otros métodos fáciles de verificar son difíciles de mantener en secreto. "Vale la pena" se reduce a determinar qué es posible mantener desconocido, y juzgar la posibilidad de un compromiso basado en esa información desconocida.

Los secretos son difíciles de mantener en secreto. Cuanto más grande sea un secreto y cuantas más personas lo conozcan, más rápido es probable que se filtre.

Los buenos secretos son:

• Pequeño.
• Conocido solo por una persona.
• Fácil de cambiar.

Cuando acusamos a alguien de seguridad a través de la oscuridad , lo que realmente decimos es que creemos que su secreto podría ser más pequeño, conocido por menos personas y / o más fácil de cambiar .

Los algoritmos, los números de puerto y las contraseñas compartidas fallan en el segundo y tercer puntos anteriores. Los algoritmos también fallan el primer punto.

La distinción entre cuando algo es un secreto apropiado y simplemente oscuro es si conocemos una manera de lograr el mismo nivel de seguridad con un secreto más pequeño que sea más fácil de cambiar y que sea menos conocido gente.

No estoy de acuerdo con la afirmación de que la oscuridad adicional nunca duele.

En el caso de los números de puerto SSH, se requiere una pequeña cantidad de tiempo extra para escribir -p 1234 cada vez que use SSH. Esto es solo uno o dos segundos, pero con la cantidad de veces que uso SSH, esto terminaría siendo significativo. Existe la sobrecarga de recordar que este cliente es ligeramente diferente y de enseñar lo mismo a los nuevos empleados. Existe el caso en el que se olvida de que este cliente se encuentra en un puerto extraño y pierde minutos en busca de configuraciones de firewall y monitores de tiempo de actividad tratando de averiguar por qué no puede conectarse.

Dado que los números de puerto son tan fáciles de descubrir con un escaneo de puertos, también tendrá que implementar un IPS que detecte el escaneo de puertos e impida que el puerto correcto responda cuando se verifique o implemente algo así como la detonación de puertos. Ambos métodos pueden superarse y no añaden nada más que más oscuridad, pero toman su tiempo jugando al gato y al mouse con su atacante.

La misma cantidad de tiempo empleado en desactivar los inicios de sesión y las contraseñas de root y cambiar las claves tendrá un mejor impacto en la seguridad. Perder tiempo en ocultar detalles le quita a las medidas de seguridad reales.

En el caso de un algoritmo secreto, el algoritmo pierde el escrutinio adicional que muchos investigadores de seguridad pueden proporcionar. Es probable que la oscuridad (o el secreto) del algoritmo haga que sea menos seguro.

Seguridad por oscuridad es donde confías en algún hecho que esperas que un atacante no conozca. Un problema importante con esto es que una vez que se revela el hecho, el esquema de seguridad se vuelve inútil.

  

Sin embargo, todo lo que está haciendo SSH es ocultar información. Se basa en la esperanza de que un atacante no piense en adivinar la clave criptográfica correcta.

Cuando se discute la frase " Seguridad por oscuridad ", a menudo se refiere a los procesos involucrados, en lugar de información secreta. Lo que pasa con SSH es que, como un proceso , se ha examinado en gran medida para garantizar que lo único que necesita mantener en secreto es la clave criptográfica. Esto no es posible en principio para que el atacante "piense y adivine", porque el espacio en el que viven las claves criptográficas es vasto .

Bruce Schneier demostró que para forzar una clave AES de 256 bits necesitaría como mínimo , a captura la producción de energía de todo el sol durante 32 años (!). No importa qué tan rápido es tu computadora. Eso es solo un resultado teórico de la información que se mantiene independientemente de la computadora que use (a pesar de la computación cuántica).

Esto es totalmente impráctico con la tecnología actual. Eso no quiere decir que SSH use AES, pero es uno de los principios de la buena criptografía.

Un ejemplo podría ser cuando se descubre un error en una pieza de software donde un usuario (confiable) encuentra que una entrada específica permite una omisión de autenticación. Un administrador deficiente podría decir "ah, pero es realmente improbable que algún usuario que no sea de confianza lo descubra alguna vez, por qué molestarse en solucionarlo". Esto es seguridad por oscuridad.

Ha sido mencionado en varias otras respuestas, pero hay tres piezas en este rompecabezas.

1. Mecanismos
2. Implementación / Configuración
3. datos

Un ejemplo de un mecanismo sería AES, o SHA-1, o para su ejemplo, SSH.
Un ejemplo de una implementación / configuración sería qué puerto SSH está escuchando, o qué algoritmo de cifrado ha elegido para cifrar los datos de su aplicación. Un ejemplo de datos es una clave privada o una contraseña.

Un mecanismo nunca debe ser oscuro. "Es seguro porque no sabes cómo funciona" no es seguridad. Debe poder examinarse minuciosamente sin que las implementaciones puedan explotarse en ausencia de datos secretos.

Una implementación puede o no estar oculta. En general, no duele ni ayuda materialmente a la seguridad cuando haces esto. Es posible que vea menos exploraciones de puertos que identifiquen su puerto SSH, o que pueda ocultar el algoritmo de cifrado utilizado para un texto cifrado en particular, pero no importa si se trata de un mecanismo seguro sin datos secretos. El mecanismo aún debe ser inexplotable. Hay un argumento de que hay un beneficio de seguridad marginal aquí, y un daño marginal a la usabilidad. Su kilometraje puede variar.

Los datos secretos deben siempre ser oscuros. Si alguien obtiene sus claves o contraseñas privadas, las revoca, crea nuevos datos secretos y promete protegerlos mejor la próxima vez.

La seguridad a la oscuridad se aplica a todo lo relacionado con no corregir la debilidad particular en el nivel de código / fuente en lugar de encontrar una solución para cubrir sus agujeros. Cuando se elimina esa capa de protección, la vulnerabilidad está abierta para ser explotada.

Un ejemplo de este tipo es el programa-ganchos que ofrece a los desarrolladores el tipo de medios ocultos para conectarse a las aplicaciones en el entorno de producción. Esto es ciertamente una amenaza, un mito de seguridad; pero se ve empañada rápidamente por alguien que tiene el conocimiento suficiente para realizar ingeniería inversa y, a veces, simplemente olfateando la red.

Por lo general, la principal razón por la que estas amenazas escapan a la naturaleza cuando se pierden en la fase SDLC del diseño del sistema / aplicación; luego, cuando va al entorno de producción, es demasiado costoso para las cosas reparar a partir de ese momento. Es allí donde comienzan a surgir soluciones alternativas o encubrimientos.

Otro ejemplo Las personas escriben su contraseña en pedazos de papel y la colocan debajo del teclado.

También como factor de mercado , debe saber que estas prácticas son seguidas normalmente por la comunidad / proveedores de código cerrado; para un proyecto de código abierto, este concepto no aplica ningún propósito práctico, ya que el código se publica al público en general para su revisión y casi cualquier persona puede abordar las inquietudes a través de técnicas como las revisiones de códigos. La mejor y más confiable manera de atraparlo.

Vencer la seguridad de SSH a través de conceptos prácticos de concepto de oscuridad

1. La ejecución de nessus scan en la red de destino le brindará los servicios vulnerables y los puertos asignados
2. Ejecutar el escaneo de nmap en la red de destino para servicios abiertos.

La seguridad a través de la oscuridad es que no hay seguridad, tal vez se declare con más precisión como "Un sistema de seguridad es tan seguro como sus secretos son difíciles de adivinar". Realmente, cuando se llega a eso, se puede argumentar que el cifrado es seguro a través de la oscuridad, ya que la clave de cifrado es oscura. La diferencia es que es tan oscuro que es matemáticamente imposible de encontrar y, por lo tanto, seguro.

En cualquier sistema de seguridad basado en el secreto, desea que el secreto sea lo más limitado posible y tan difícil de adivinar como sea posible. Cuanto más complejo sea un secreto, más probable es que haya un defecto en él. Además, limitar la cantidad que debe mantenerse en secreto hace que sea más fácil mantenerlo en secreto.

La afirmación de "seguridad a través de la oscuridad no es seguridad" se deriva de la idea de que muchas ideas "inteligentes" simplemente están ideando formas complicadas de hacer algo para tratar de hacer que sea más difícil para un atacante descubrir algo, pero a menudo Un detalle de esos enfoques impactará otros detalles de otros pasos, por lo que es imposible decir qué tan difícil será para un atacante con conocimiento parcial de un algoritmo secreto para determinar el resto del algoritmo.

Las claves, por otro lado, deben ser aleatorias, ya que conocer algunos bits de una clave criptográfica, por ejemplo, no debería ayudarlo a descubrir los otros bits de la clave. Del mismo modo, la dificultad para descubrir la clave se comprende bastante bien. Dado que la seguridad relativa del algoritmo no se ve afectada significativamente (o no se puede cuantificar de manera confiable) por el secreto del algoritmo, no agrega seguridad estadísticamente significativa.

Lo que hace un impacto estadísticamente significativo en la seguridad de un algoritmo es cualquier problema con el algoritmo. En general, los algoritmos publicados se han examinado mucho más a fondo para detectar cualquier defecto que los rompa y, por lo tanto, en general proporcionarán una mayor confianza en la seguridad que brindan.

Para cerrar, la mayor parte de la seguridad implica cierto nivel de oscuridad, pero el truco es minimizar la cantidad y maximizar la facilidad de proteger esos secretos al mismo tiempo que intenta asegurarse de que no haya fallas no detectadas que hagan que el sistema se comporte mal. y revelar los secretos.

En cada algoritmo de cifrado, en cada solicitud de inicio de sesión, "seguridad por oscuridad" es un componente importante. Siempre se basa en algún tipo de conocimiento secreto (con la excepción de la autenticación de dos factores).

La diferencia entre la buena seguridad y la mala seguridad está conectada a las propiedades de conocimiento secreto : ¿Se mantiene en secreto?

Un mal ejemplo es un sistema en el que puede obtener información sobre este secreto de otros canales. Digamos que usted inventó su propio algoritmo de cifrado, por ejemplo, "zip a continuación, XOR con su clave". Un atacante investiga su sistema y puede determinar el algoritmo de compresión desde el momento en que su esquema de cifrado tarda en codificar diferentes mensajes de texto sin formato. El atacante adquirió conocimiento sobre su sistema, conoce los elementos internos del algoritmo zip y podría utilizar estos datos para determinar su clave. Desde el exterior, este parece un algoritmo perfectamente bueno, los datos comprimidos y xorados se verán bastante aleatorios, pero solo supondrán un pequeño desafío para un atacante sofisticado. Su clave puede ser muy larga, pero eso no le ayuda a distinguir entre la oscuridad mala y la buena. Usted insertó accidentalmente una ruta para obtener conocimiento sobre su clave secreta en el algoritmo:

El contraejemplo es el cifrado de clave pública RSA. Aquí la clave secreta es un número primo grande. La clave pública es el producto de la clave secreta y otro número primo grande. Ahora, incluso con el algoritmo RSA bien conocido, puedo darle mi clave pública, puede codificar cualquier información que desee con ella, pero no filtra ninguna información sobre la clave secreta .

Tan importante para distinguir entre buena y mala seguridad es la cantidad de tiempo que alguien necesita para acceder a sus datos. En su ejemplo específico, desde el puerto 22 hasta el 2222, hay otra información que el atacante necesita, por lo que es un plus de seguridad. Como esto es fácil de resolver en poco tiempo, solo agrega una cantidad muy pequeña pero no filtra nada acerca de su llave. Dado que este escaneo de puertos es trivial y solo cuesta una vez, la cantidad total de información necesaria para conocer su clave secreta se mantiene constante, es por eso que no se considera que mejore la seguridad total, por lo tanto El dicho común de que "la seguridad por la oscuridad" no ayuda.

"Oscuridad" es sobre suposiciones

Creo que "seguridad por oscuridad" en realidad se trata de suposiciones erróneas.

Por ejemplo, si uso ingenuamente mi propio cifrado enrollado a mano, pienso que "nadie sabrá cómo romperlo porque es único":

• Lo sé puede ser roto por alguien que tenga la llave.
• Supongo que no se puede romper por otros medios. Esto es probablemente falso.

Si utilizo un método de cifrado probado:

• Lo sé puede ser roto por alguien que tenga la llave.
• Tengo buena evidencia de que no se puede romper por otros medios.

Todavía confío en la "oscuridad" de mi clave. Pero eso es lo único que tengo que proteger.

Entonces, para detectar "seguridad por oscuridad", desafíe las suposiciones. Si alguien dice "nadie puede adivinar o detectar que estamos haciendo X", la respuesta correcta es ¿cuántas pruebas tiene? El estándar en seguridad es muy, muy alto.

Lo formularía de esta manera:

'Seguridad a través de la oscuridad' se refiere a una situación en la que a un atacante se le proporciona deliberadamente con todos los medios / información necesarios para romper el mecanismo de seguridad, esperando o asumiendo que el atacante no realizará el esfuerzo para revelarlo.

En ocasiones, se puede observar que algunos programas intentan lograr la seguridad mediante algún esquema de encriptado "automático", donde al final, además del algoritmo de encriptación, la clave de encriptación se encuentra en algún lugar del programa. El programa en sí no necesitará más información para poder descifrar sus datos "secretos"; y tampoco ningún atacante.

La seguridad 'real' intentará asegurarse de que un atacante nunca tendrá todos la información necesaria para romperla. Cuando se usa el cifrado, básicamente no importa si el atacante tiene acceso tanto al mensaje de cifrado como a el algoritmo para crearlo siempre que no se le revele el cifrado clave . . De esta manera, se le niega la información crítica y no puede, debido a la información que tiene simplemente eludir el mecanismo de seguridad.

Puedes usar lo que quieras para la "clave secreta", pero los puertos son una mala elección; solo hay 2 ^ 16 de ellos, pueden ser rastreados, y son (generalmente) estáticos mientras dura la conexión.

Sin embargo, se han utilizado como (parte de) la clave secreta en el pasado, cuando no hay otra buena opción. En particular, se utilizó la asignación aleatoria de puertos para contrarrestar el ataque de envenenamiento del caché de DNS de Kaminsky de hace unos años. Combinado con la asignación aleatoria de la ID de consulta de 16 bits, esto nos brinda 32 bits de seguridad, lo cual es más que suficiente para protegernos por la duración de una consulta de DNS típica (~ 0.1 segundos). La clave secreta aún puede ser detectada, pero se considera "no es un gran problema" ya que el DNS siempre ha sido vulnerable a los ataques MITM de todos modos. C'est la vie.

Por lo tanto, si su ejemplo es "seguridad por oscuridad" o no depende realmente del contexto.

Si tiene un conjunto completo de mecanismos de protección, podría decir que cualquiera de esos mecanismos de protección es solo "seguridad a través de la oscuridad", pero es más importante considerar la seguridad del sistema como un todo.

Individualmente, un mecanismo de protección se considera "seguridad a través de la oscuridad" si ese mecanismo de protección depende de que un atacante no espere algo, o si ese mecanismo de protección depende de que sea inusual y no criptográficamente fuerte. En otras palabras, poner SSH en el puerto 2222 es seguridad a través de la oscuridad porque un atacante no esperaría que estuviera allí (no sería su primera estimación), y porque ese no es el puerto normal. Sin embargo, la protección de SSH con una contraseña de alta resistencia es una seguridad real porque está destinada a ser criptográficamente sólida. Además, cambiar su nombre de usuario de "raíz" a algo que no se puede adivinar fácilmente es también una seguridad real porque existe una medida de la fuerza criptográfica: si el atacante no puede averiguar el nombre de usuario, no puede ingresar al sistema incluso si Obtienen la contraseña correcta.

Por oscuridad, entiendo que su seguridad se basa en el hecho de que un pirata informático no conoce su algoritmo de cifrado. Simplemente revertirá los caracteres en sus palabras, como PASS - > SAPP, o hacer una ofuscación más compleja, y puede comunicarse siempre que nadie detecte el algoritmo. Si la revelación del algoritmo de encriptación rompe toda su seguridad, entonces es oscuridad, no seguridad. La seguridad real comienza cuando el pirata informático no podrá descifrar su mensaje, dados los algoritmos de cifrado y descifrado.

La seguridad se realiza al autenticar que usted es el destinatario o usuario deseado. Hay 3 factores de autenticación

• Algo que el usuario sabe (por ejemplo, contraseña, PIN, patrón)
• Algo que el usuario tiene (por ejemplo, tarjeta de cajero automático, tarjeta inteligente)
• Algo que el usuario es (por ejemplo, característica biométrica, como un huella digital)

La mayoría de las medidas de seguridad usan autenticación de factor único. Por ejemplo, SSH requiere conocer una contraseña o tener una clave privada (supongo que podría decir que requerir una contraseña para la clave sería una autenticación de dos factores).

La autenticación de dos factores es algo que ha sido implementado últimamente por muchos proveedores de servicios y software. Esto requiere cualquiera de los dos factores mencionados anteriormente, generalmente una contraseña y un número de teléfono. Con la autenticación de dos factores, un atacante puede obtener acceso a cualquiera de las credenciales de seguridad y no poder acceder al sistema seguro.

La seguridad a través de la oscuridad es una autenticación de factor cero. No está obligado a conocer ningún secreto, poseer nada o ser una persona en particular. Sin autenticación no hay autenticación y por lo tanto no hay seguridad real.

La oscuridad solo puede lastimarte si crees que te brinda verdadera seguridad y adopta prácticas débiles. Sin embargo, la oscuridad puede ayudar un poco, ya que le ahorra tiempo a futuras vulnerabilidades desconocidas, si intenta mantener las mejores prácticas (frases de contraseña seguras, aplicar actualizaciones de seguridad, usar algoritmos y protocolos de seguridad, etc.). La oscuridad no previene un ataque de alguien que te ha atacado si tu sistema es vulnerable, pero tampoco anuncia que eres vulnerable a todo el mundo.

Si tenía una aplicación Ruby On Rails y anunciaba que estaba fuera de vacaciones en enero pasado, la gente podría haber ejecutado comandos arbitrarios en su servidor web. De hecho, el anuncio permitiría que los atacantes lo encontraran mucho más rápido que si tuvieran que adivinar aleatoriamente qué tipo de pila de tecnología estaba ejecutando y probar cada sitio web aleatorio.

O digamos que hay una debilidad de día cero en SSH; Algo así como el problema de generación de claves de Debian SSH de hace unos años. La gente comenzará a escanear aleatoriamente para encontrar ssh ejecutándose en el puerto 22 en direcciones IP aleatorias y luego ejecutará el exploit. Seguro que podrían hacer un escaneo de puerto primero para buscar ssh, pero los atacantes primero buscarán la fruta baja. Una búsqueda completa haría su escaneo más de 10000 veces más lento. Esperemos que para entonces haya solucionado el problema. La mayoría de las direcciones IP aleatorias no van a tener ssh o cualquier otra cosa que se ejecute en ellas, por lo que tiene sentido que los atacantes dejen de escanear después del puerto 22 (y tal vez un par de otras 222 y 2222 y 22222 también). Si su servidor doméstico no responde a los pings y deja caer todos los paquetes a los puertos, pero aparte de los 39325, es probable que se muevan antes de encontrar su servidor ssh. Eso es la oscuridad ayudándote. Sí, un interlocutor de la red podría encontrar trivialmente su puerto escuchando en una conexión ssh. Pero para la gran mayoría de los atacantes que te atacaron al azar, no habrán observado una conexión ssh escuchando el tráfico de tu red. Además, incluso para esos atacantes, el 99.9% del tiempo usted espera que su configuración ssh sea segura y no tenga vulnerabilidades.

Y para la molestia adicional de escribir ssh -p 39325 -Y [email protected] , cualquiera que use ssh con frecuencia configura un archivo ~/.ssh/config (junto con authorized_keys y id_rsa.pub / id_rsa ) para que solo puedan escribir ssh foo para conectarse después de escribir sus claves privadas frase de contraseña. Ahora su archivo de configuración recuerda el nombre de dominio completo, su nombre de usuario, el puerto (si no es el 22) y cualquier otra marca. Para ssh, cambiaré los puertos si es internet y solo lo uso (mi máquina doméstica, mi VPS) como una molestia para que todos usen el mismo puerto que tú. Para las cosas internas de múltiples usuarios en el trabajo, lo mantengo conectado a Internet externo y requiero acceso externo para pasar a través de una VPN.

Para el registro, mi VPS solía tener ssh ejecutándose en el puerto 22 y tenía aproximadamente ~ 10000 / día intentos de autenticación erróneos (todos con nombres de usuario inexistentes) registrados en los archivos de registro. En los últimos tres meses de archivos de registro, obtuve exactamente cero ejecutándose en un puerto diferente.

Supongo que esa oscuridad se puede medir comparando su valor de seguridad con cuánto complicará el uso del medio protegido. Alguien ya mencionó que el cambio de puerto SSH aumentará un poco su seguridad, pero al mismo tiempo complicará mucho el uso del shell, porque tendrá que recordar en qué puerto está, enseñar a todos los nuevos empleados esta seguridad. mida, y eventualmente terminará como una nota adhesiva adjunta a las pantallas del usuario o scripts automáticos con el puerto codificado, anulando así su valor de seguridad.

Del mismo modo, puede ofuscar el código fuente para protegerlo. Pero si alguien accede a él, es solo cuestión de tiempo antes de que restaure el significado original de las funciones y variables (por ejemplo, mediante una depuración cuidadosa) haciendo que la ofuscación no tenga sentido. Por otro lado, debes recordar ejecutar un programa especial antes de compilar el código o (lo que es aún peor, pero lo vi) solo funciona en el código con una convención de nombres extraños.

En mi opinión, pierdes más de lo que ganas al usar la oscuridad y es por eso que la seguridad por oscuridad se considera una mala práctica.