Sono completamente confuso, però. Qual è il vantaggio per la sicurezza qui?

Niente. Lo scenario più probabile è che qualcosa di intermedio interrompa la connessione dopo 5 minuti per risparmiare risorse. Potrebbe essere un firewall, un acceleratore WAN, un acceleratore SSL, ecc. Oppure potrebbe essere solo una cattiva impostazione predefinita. Chi lo sa?

Gli amministratori di rete hanno spesso preoccupazioni diverse da tutti gli altri, che spesso possono entrare in conflitto con gli altri. Lavoriamo in un mondo a compartimenti stagni in cui l'immagine olistica non viene presa in considerazione.

Non dare per scontato che ci sia una ragione particolarmente valida per ogni impostazione, ma lascia spazio alla possibilità che il timeout di 5 minuti sia stato una soluzione rapida per qualche altro problema che stanno avendo e il problema dell'applicazione è stato un contraccolpo .

Questo sembra un buon esempio di "culto del carico" della sicurezza. Un controllo di sicurezza è stato implementato alla cieca senza comprendere il contesto coinvolto o addirittura implementarlo correttamente.

In generale nella sicurezza il punto di un timeout di inattività per ridurre il rischio di situazioni in cui una macchina client viene lasciata incustodita e un utente malintenzionato raggiunge la macchina ed esegue comandi non autorizzati su di essa. L'equilibrio in questi timeout tende ad essere quello dell'usabilità (che favorisce timeout più lunghi o meno) e della sicurezza (che favorisce timeout più brevi).

A volte puoi individuare il culto del carico di sicurezza esattamente con ciò che hai menzionato, ovvero che gli operatori del sistema ti stanno effettivamente aiutando a bypassare il controllo nominale (nel tuo caso raccomandando l'uso di keep-alive)

Sono completamente confuso, però. Qual è il vantaggio per la sicurezza qui?

Potrebbe non essere una questione di sicurezza ma avere una ragione diversa. Sfortunatamente la tua domanda offre solo la tua visione, quindi possiamo solo ipotizzare quale potrebbe essere la vera ragione.

Una spiegazione potrebbe essere che esiste un semplice filtro di pacchetti con stato in cui gli stati scadono dopo 120 secondi di inattività. Ciò significa che tutti i dati trasferiti dopo questa inattività verranno bloccati perché non esiste più uno stato aperto. La ragione di ciò potrebbe essere un dispositivo che ha solo risorse molto limitate e quindi non può mantenere aperti troppi stati allo stesso tempo, ad esempio un firewall progettato pensando a 10 utenti ma ora utilizzato da 100 utenti.

Ovviamente potrebbe anche essere che un BOFH stia eseguendo il sistema che probabilmente è più la tua opinione sul problema :) Ma questo è difficile da dire senza avere maggiori informazioni sul sistema reale .

Come avrai notato, questo non ha nulla a che fare con la sicurezza. Invece, la pratica di eliminare le connessioni TCP dormienti di lunga durata ha a che fare con i bug: è una soluzione per il software difettoso.

Uno degli esempi più famosi di software che lascia sospese le sessioni TCP è Internet Explorer ( almeno fino alla versione 7). IE aveva l'abitudine di non terminare correttamente le sessioni TCP, quindi mentre sul PC / laptop / telefono client il socket è considerato chiuso, il server vede ancora la connessione come aperta. E IE è solo uno degli esempi più noti. Ci sono molti software difettosi là fuori.

Allora perché dovrebbe interessare un server? Perché ogni socket aperto è anche un descrittore di file aperto. Non gestire questa situazione fa sì che il server esaurisca il descrittore di file. In teoria il server può anche esaurire l'ID del socket, ma quel numero è molto, molto più alto del numero di descrittori di file aperti che un sistema operativo può gestire.

Per questo motivo, varie implementazioni dello stack TCP includono un timeout su prese morte. Su alcuni sistemi operativi è possibile configurare questo timeout.

Hai quasi sempre un timeout su una sessione TCP inattiva implementata in router, switch e tutti quei macchinari di rete di basso livello. Ha poco a che fare con la sicurezza nel senso di protezione contro un attacco deliberato, ma cerca solo di non esaurire le risorse a causa del software difettoso che non riesce a chiudere la connessione o di altri errori hardware nella rete esterna che impediscono al pacchetto di chiusura di raggiungere la sua destinazione.

A causa di questi possibili guasti transitori, un dispositivo di rete (normalmente mai ripristinato a meno che non venga interrotto) che non interrompa mai la connessione inattiva finirebbe con la carenza di risorse e genererà esso stesso un rifiuto del servizio ...

Il peggio è che spesso sono sistemi con poche risorse (a basso costo) e per questo motivo, gli amministratori di rete si sforzano di ridurre il rischio che la loro parte si blocchi sotto carico e come tali tendono a utilizzare timeout aggressivi. Questo è il motivo per cui si utilizza la connessione TCP keep alive (se il pacchetto keep alive passa c'è qualcosa dall'altra parte) combinato con brevi timeout di rete.

Ma il vero problema qui è che gli sviluppatori di applicazioni sanno poco di low usi di rete di livello e che gli amministratori di rete non si preoccupano molto delle applicazioni di alto livello. La vita è così ...