¿Ventajas de matar sesiones después de 5 minutos?

Esto parece un buen ejemplo de un seguridad "cargo culto" . Se ha implementado un control de seguridad a ciegas sin comprender el contexto involucrado o, de hecho, implementarlo correctamente.

En términos generales, en términos de seguridad, el punto de un tiempo de espera inactivo es para reducir el riesgo de situaciones en las que una máquina cliente queda desatendida y un usuario malintencionado llega a la máquina y ejecuta comandos no autorizados en ella. El saldo en estos tiempos de espera tiende a ser uno de usabilidad (que favorece un tiempo de espera más largo o no) y de seguridad (que favorece tiempos de espera más cortos).

A veces puede detectar el cultivo de la carga de seguridad exactamente con lo que mencionó, es decir, los operadores del sistema realmente lo están ayudando a evitar el control nominal (en su caso, recomendando el uso de keep-alives)

  

Estoy completamente confundido, sin embargo. ¿Cuál es el beneficio de seguridad aquí?

Nada. El escenario más probable es que algo intermedio sea el tiempo de espera de la conexión después de 5 minutos para conservar los recursos. Eso podría ser un firewall, un acelerador de WAN, un acelerador de SSL, etc. O podría ser simplemente una mala configuración predeterminada. ¿Quién sabe?

Los administradores de red a menudo tienen preocupaciones diferentes a las de los demás, ya que muchas veces pueden entrar en conflicto con otros. Trabajamos en un mundo de silo donde no se toma en cuenta la imagen holística.

No asuma que hay una razón particularmente buena para cada configuración, pero deje espacio para la posibilidad de que el tiempo de espera de 5 minutos sea una solución rápida para algún otro problema que tengan, y el problema de su aplicación fue de retroceso.

  

Estoy completamente confundido, sin embargo. ¿Cuál es el beneficio de seguridad aquí?

Puede que no sea una cuestión de seguridad, sino que tenga una razón diferente. Desafortunadamente, su pregunta solo ofrece su opinión, por lo que solo podemos especular sobre cuál podría ser la verdadera razón.

Una explicación podría ser que hay un filtro de paquetes con estado simple donde los estados se agotan después de 120 segundos de inactividad. Esto significa que cualquier dato transferido después de esta inactividad será bloqueado porque ya no hay un estado abierto. La razón de esto podría ser un dispositivo que solo tiene recursos muy limitados y, por lo tanto, no puede mantener demasiados estados abiertos al mismo tiempo, por ejemplo, un firewall que fue diseñado con 10 usuarios en mente, pero ahora es usado por 100 usuarios.

Por supuesto, también puede ser que un BOFH esté ejecutando el sistema, que probablemente sea más su opinión ante el problema: ) Pero es difícil saberlo sin tener más información sobre el sistema real.

Como puede haber notado, esto no tiene nada que ver con la seguridad en absoluto. En cambio, la práctica de matar conexiones TCP inactivas de larga duración tiene que ver con errores: es una solución alternativa para el software con errores.

Uno de los ejemplos más famosos de software que deja colgadas las sesiones de TCP es Internet Explorer (al menos hasta la versión 7). IE tenía el hábito de no finalizar las sesiones TCP correctamente, por lo que mientras el PC / laptop / teléfono cliente se considera cerrado, el servidor todavía ve la conexión como abierta. Y IE es solo uno de los ejemplos más conocidos. Hay un montón de software de buggy por ahí.

Entonces, ¿por qué debería importarle un servidor? Porque cada socket abierto es también un descriptor de archivo abierto. No manejar esta situación hace que el servidor se quede sin descriptor de archivos. En teoría, el servidor también puede quedarse sin ID de socket, pero ese número es mucho más alto que el número de descriptores de archivos abiertos que un sistema operativo puede manejar.

Debido a esto, varias implementaciones de la pila TCP incluyen un tiempo de espera en sockets muertos. En algunos sistemas operativos puede configurar este tiempo de espera.

Casi siempre se ha agotado el tiempo de espera en la sesión TCP inactiva implementada en enrutadores, conmutadores y toda esa maquinaria de red de bajo nivel. Tiene poco que ver con la seguridad en el sentido de protección contra un ataque deliberado, pero simplemente trate de no agotar los recursos debido a que el software defectuoso no puede cerrar la conexión u otros errores de hardware en la red externa que impiden que el paquete final llegue a su destino.

Debido a esas posibles fallas trascendentales, un equipo de red (que normalmente nunca se reinicia a menos que esté roto) que nunca se desconectaría de la conexión inactiva terminaría en la falta de recursos y generará un rechazo del servicio ...

Lo peor, es que a menudo son sistemas de bajos recursos (bajo costo) y, por ese motivo, los administradores de red se esfuerzan por reducir el riesgo de que su parte se bloquee bajo carga y, como tal, tienden a utilizar tiempos de espera agresivos. Esa es la razón por la que se usa la conexión TCP viva (si hay algo en el otro extremo) combinado con tiempos de espera de red cortos.

Pero el verdadero problema aquí es que los desarrolladores de aplicaciones saben poco sobre los usos de red de bajo nivel, y que a los administradores de red no les importa mucho las aplicaciones de alto nivel. La vida es así ...