¿Es HTTPS tan seguro o más seguro que SSH si ambos tienen una dirección IP en la lista blanca?

Question

¿Es HTTPS tan seguro o más seguro que SSH si ambos tienen una dirección IP en la lista blanca?

Navega tus respuestas

#1 de dr jimbob (5 votos)
#2 de munkeyoto (1 votos)

2

Me pregunto si un punto final de API HTTPS sería tan seguro o más seguro que SSH.

API Endpoint

El punto final de la API requeriría HTTPS
La autenticación de API usaría una clave de API POST'd.
La longitud mínima requerida de la clave API básicamente podría ser arbitrariamente larga
El punto final de la API solo aceptaría conexiones de direcciones IP incluidas en la lista blanca.
La URL del punto final de la API no estaría disponible públicamente o enlazada desde cualquier lugar. Solo la aplicación cliente sabría lo que era.
La aplicación cliente que se conecta al punto final no aceptará cifrados SSL débiles.

Conexión SSH

Para los propósitos de esta pregunta, haremos las siguientes suposiciones acerca de la conexión SSH con la que nos estamos comparando.

La longitud mínima requerida de la contraseña es de 8 caracteres con mayúsculas, minúsculas y el número requerido.
El dominio al que se conecta es el dominio público (es decir, para enlace se conecta mediante ssh domain.com)

Consideraciones

Algunas consideraciones que he pensado que pueden afectar si una es más segura que la otra son:

¿Es la detección de la dirección IP de HTTPS tan confiable como SSH? Supongo que los dos solo miran lo que el cliente les envía y, por lo tanto, no se puede confiar al 100%, pero sin embargo proporcionan cierto nivel de seguridad.
Creo que SSH tiene un mecanismo incorporado para evitar intentos de reintento rápidos. Sé que el HTTPS por sí solo no lo hace, pero en muchos casos donde la seguridad es primordial que se incorporó en la capa de servicio web.

Mi corazonada

Mi corazonada sería que el punto final de la API sería en realidad más seguro que SSH por las siguientes razones, pero no soy un experto en seguridad, por lo que me encantaría obtener una respuesta sólida:

Con SSH, el atacante potencial sabe a qué dominio apuntar (es decir, ssh domain.com). Pero con la API, la URL no se conocería, por lo que incluso para comenzar a atacarla, primero tendrían que averiguar cuál era la URL.
La fuerza de la contraseña de la API es mayor

Context

La razón por la que estoy preguntando esto es porque estoy considerando crear un punto final de API que permita a un usuario confiable y autenticado acceder a una gran cantidad de datos potencialmente confidenciales. Sería una herramienta poderosa que permitiría que la lógica de negocios de aplicaciones bien desacopladas se escribiera muy rápidamente.

El motivo por el que pregunto si es tan seguro como SSH es porque supongo que los posibles usuarios de esta aplicación tienen SSH habilitado con, como máximo, una lista blanca de direcciones IP como una capa adicional de seguridad.

Por lo que es decir, las capacidades de este punto final de API ya están presentes a través de SSH. Si el punto final no presentara un riesgo adicional por encima del riesgo que está presente con SSH, entonces consideraría que es un nivel de riesgo aceptable. Pero si fuera menos seguro, probablemente no lo consideraría aceptable.

ACTUALIZACIÓN: Se agregó una nota acerca de los cifrados débiles al punto final de la API.

tls http ssh

pregunta kalenjordan 16.05.2014 - 05:49

fuente

2 respuestas

Lea otras preguntas en las etiquetas tls http ssh

Solución de almacenamiento de HDD a largo plazo Confiando en SSL y la cadena de confianza

score 5 · Answer 1

¿La detección de la dirección IP de HTTPS es tan confiable como SSH?

Ambos son protocolos sobre TCP, donde verifica la dirección IP cuando se completa el protocolo TCP. (Con una dirección IP completamente falsa, es probable que los paquetes no sean enrutados a usted, por lo que no podría completar el protocolo de enlace TCP (o, más precisamente, tiene una posibilidad entre 4 mil millones de adivinarlo) que requiere una respuesta con un 32- número de secuencia de bits que el servidor le dirigió). Un poderoso adversario que tiene control sobre un servidor en la red entre el cliente y el servidor puede falsificar su dirección IP y recolectar y no reenviar paquetes destinados a una dirección IP falsificada, pero requiere que tengan el control total de un servidor en la ruta real elegido a través de la red.

Creo que SSH tiene un mecanismo incorporado para evitar los intentos rápidos de reintento

En realidad no es así, realmente necesitas configurar fail2ban para hacer esto. (Sí, hay algunas opciones para insertar retrasos en intentos de contraseña repetidos dentro de una sesión ssh, pero no son tan buenos).

Todavía no entiendo la configuración. Tanto SSH como HTTPS abarcan una amplia variedad de configuraciones. Por ejemplo, el uso de una conexión HTTPS autofirmada en la que no verifique los certificados que no son de confianza será vulnerable a los ataques del hombre en el medio (al menos con SSH, se advierte en voz alta cuando cambian los certificados de host). De manera similar, hay algunos protocolos HTTPS débiles, no debes usar SSLv2 o cifrados débiles.

¿La conexión HTTPS / SSH utiliza certificados de un cliente? ¿No se supone que esto sea automatizado?

Si tiene una API que debe ejecutarse desde un servidor web, hacerlo de forma segura con HTTPS es la ruta natural. SSH está diseñado para conectarse remotamente a otra línea de comandos de computadoras. Sí, puede usarlo para otras cosas como la ejecución remota de comandos o el tráfico de la red de túneles, pero si desea ofrecer una API segura basada en la web, tiene mucho más sentido utilizar TLS para verificar los certificados de cliente y servidor (incluso si son autofirmado).

score 1 · Answer 2

Intentaré ofrecer algunos punteros / contrapuntos:

The API endpoint would require HTTPS

Que puede ser MITM'd si su red no es segura. Creo que necesitas mirar el diseño de la red antes de la capa de aplicación / presentación.

La autenticación de API usaría una clave de API POST. El mínimo la longitud requerida de la clave API básicamente podría ser arbitrariamente larga

Si su red no es segura, una clave de API podría ser detectada, modificada, etc., por lo que si crea una clave de 200 caracteres, ¿de qué sirve si está visible en texto claro porque su red es vulnerable? ?

El punto final de la API solo aceptaría conexiones de IP en la lista blanca direcciones.

La lista blanca / lista negra no funciona, ya que los atacantes pueden obligar a los activadores a obtener una lista negra en las listas negras. Voy a elaborar sobre esto con su comentario fail2ban.

La URL del punto final de la API no estaría disponible públicamente o enlazada de donde sea. Solo la aplicación cliente sabría lo que era.

Ahora todo lo que tiene que preocuparse es asegurarse de que su aplicación cliente no esté en una máquina vulnerable.

La longitud mínima requerida de la contraseña es de 8 caracteres con mayúscula caso, minúscula y número requerido.

SSH no es la solución de seguridad de "fin de todo" donde, solo porque la está ejecutando, no se lo atacará ni se verá comprometido. Las contraseñas seguras, aunque son útiles, harán poco en contra de un usuario cuya máquina está infectada con un registrador de pulsaciones de teclas que hace que cualquier contraseña sea inútil.

¿La detección de la dirección IP de HTTPS es tan confiable como SSH? Supongo que ambos miran lo que el cliente les envía y por lo tanto, no se puede confiar al 100%

Una IP es una IP es una IP nauseam. La búsqueda se realiza en el nivel de la red y es allí donde desea cambiar su enfoque. Así que sin ir línea por línea:

En un escenario fail2ban: lo que está haciendo aquí es decir: " Mire, vaya a mis archivos de registro, vea si algo sospechoso está sucediendo, si es así, entonces debe agregar la dirección de los delincuentes a una lista negra porque quiero detenerlo. "

Escenario: "Como atacante, genero ruido usando netcat. Escaneo su servidor usando la dirección falsificada de 0.0.0.0 que ahora bloquea el mundo. Como el mismo atacante, genero previamente paquetes que lo escanean como su ruta predeterminada. .. Su socio comercial que obtuve de comunicados de prensa en su sitio ... Direcciones aleatorias ". Estos ahora están todos bloqueados. Por no mencionar, cuantas más reglas tenga en su firewall, más tiempo llevará procesar los paquetes. Para entender más esto, lea " Failed2Ban "

Tu BEST es crear BLOQUEAR TODO y PERMITIR EN ESPECÍFICOS > De esta forma, no tiene que preocuparse por los errores (direcciones falsificadas, etc.)

En la instancia que describió, está intentando realizar tareas que deberían estar en la capa de red, está tratando de obtener responsabilidades de una capa diferente para abordar las fallas. No funcionará.

Si fuera yo en el lado de diseño de la ecuación, apuntaría a una conexión basada en VPN si es posible.

Client --> send data --> only using a tunnel --> server Connection established/made --> decrypt data from the tunnel, give it to the right application

En este caso (túnel VPN IPSEC), tiene un poco más de protección contra los ataques de repetición (si usa AH), por lo que es más difícil para MITM que los ataques a SSL. Con SSL, agrega la sobrecarga para los "errores de certificado" (que la mayoría de las personas ignorarán, etc.).

Lo que me hace preguntar, esta conexión es para clientes dedicados, el mundo, etc., pregunto porque este tipo de configuración (túneles VPN) no funcionará para conexiones dinámicas. Por ejemplo, usted obtiene un nuevo cliente aleatorio que se inscribió, ahora necesita un túnel * 100,000 clientes nuevos, en lugar de que usted cree 24 túneles para clientes dedicados.

Debes poner mucho pensamiento en tu escenario, pero en su mayor parte, esto es lo que te vino a la mente al leer tu pregunta.