¿Las conexiones largas son una vulnerabilidad de seguridad?

1

En un breve resumen, ¿se pueden crear conexiones largas como una vulnerabilidad de seguridad? Por conexiones largas me refiero a conexiones donde durante un largo período de tiempo los datos no se envían en absoluto. Por ejemplo, ¿la conexión cliente-servidor cuando el cliente o el servidor tiene que recuperar los datos recibidos y tarda mucho tiempo? Ahora mismo estoy trabajando con un sistema donde los dispositivos se conectan a través de conexiones gprs / 3g / lte, a veces sucede que el sistema tiene que recuperar datos y lleva tiempo. Parece que la red o el dispositivo de red (enrutador, no tengo acceso a la configuración del enrutador) se ha agotado el tiempo de espera si no se han enviado datos en los últimos 5 minutos, para mí parece un período de tiempo demasiado corto. Podemos omitir el límite de 5 minutos configurando tcp_keepalive_time a un valor más bajo, pero ¿tal vez existen algunos motivos de seguridad para cerrar la conexión después de 5 minutos?

    
pregunta whd 16.02.2017 - 10:35
fuente

2 respuestas

3

Desde un punto de vista infosec, se necesitan sesiones TCP caducadas para reducir la posibilidad de agotar recursos en firewalls, enrutadores y otros equipos.

Keepalives ayuda cuando los protocolos de nivel superior toman mucho tiempo entre las transmisiones, por ejemplo, al procesar información del lado del cliente.

La desventaja de keepalives, especialmente para los clientes inalámbricos, es que una conexión perfectamente válida puede terminarse si se elimina un paquete keepalive. Es decir, mientras que TCP es un protocolo con estado que normalmente se retransmite en caso de pérdida de paquete y recibo del segmento de ACK, la ausencia de una respuesta a un keepalive podría significar que el otro extremo está inactivo, o que se perdió un solo paquete.

Dependiendo de keepalives puede crear situaciones en las que los usuarios a través de conexiones no confiables tienen problemas con la aplicación que no son reproducibles.

Estos largos tiempos de espera de la sesión TCP pueden ayudar a un puñado de clientes, pero solo si los dispositivos de la puerta de enlace del cliente también tienen tiempos de espera prolongados de la sesión ... luego los usuarios domésticos, cafeterías, etc.

La mejor solución para esto es una keepalive de capa de aplicación o una devolución de llamada de URL.

    
respondido por el mgjk 16.02.2017 - 11:11
fuente
2

El único problema que puedo ver que surge de esto es: varios clientes se conectan a su servidor, por lo que consumen sus recursos y crean efectivamente una condición de denegación de servicio.

    
respondido por el thel3l 16.02.2017 - 10:50
fuente

Lea otras preguntas en las etiquetas