I vantaggi di uccidere le sessioni dopo 5 minuti?

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

Generalmente parlando in sicurezza il punto di un timeout inattivo per ridurre il rischio di situazioni in cui un computer client viene lasciato incustodito e un utente malintenzionato accede alla macchina ed esegue comandi non autorizzati su di esso. Il saldo in questi timeout tende ad essere uno di usabilità (che favorisce un timeout più lungo o nullo) e la sicurezza (che favorisce i timeout più brevi).

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

I'm completely confused, though. What is the security benefit here?

Niente. Lo scenario più probabile è che una via di mezzo stia temporizzando la connessione dopo 5 minuti per risparmiare risorse. Potrebbe trattarsi di 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 i tempi possono entrare in conflitto con gli altri. Lavoriamo in un mondo siloed dove non viene preso in considerazione il quadro olistico.

Non dare per scontato che ci sia una ragione particolarmente buona per ogni impostazione, ma lascia spazio al potenziale che il timeout di 5 minuti sia una soluzione rapida per qualche altro problema che stanno avendo e il problema dell'applicazione è stato di ritorno.

I'm completely confused, though. What is the security benefit here?

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

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

Naturalmente potrebbe anche succedere che un BOFH stia eseguendo il sistema che probabilmente è più la tua opinione al problema: ) Ma questo è difficile da dire senza avere più informazioni sul sistema attuale.

Come avrai notato, questo non ha nulla a che fare con la sicurezza. Invece, la pratica di uccidere connessioni TCP dormienti di lunga durata ha a che fare con bug: è un modo per aggirare il software buggy.

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

Quindi perché dovrebbe preoccuparsi un server? Perché ogni socket aperto è anche un descrittore di file aperto. La mancata gestione di questa situazione causa l'esaurimento del descrittore di file del server. In teoria il server può anche funzionare senza ID 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 sui socket morti. In alcuni sistemi operativi è possibile configurare questo timeout.

Si ha quasi sempre il timeout sulla sessione TCP inattiva implementata su router, switch e su tutti i macchinari di rete di basso livello. Ha poco a che fare con la sicurezza nel senso di protezione contro un attacco intenzionale, ma cerca solo di non esaurire le risorse a causa del malfunzionamento del software buggy o di altri errori hardware nella rete esterna che impediscono al pacchetto di chiusura di raggiungere la sua destinazione. / p>

A causa di questi possibili errori transitori, un equipaggiamento di rete (normalmente mai reimpostato se non interrotto) che non interromperebbe mai la connessione inattiva finirebbe con l'inattività delle risorse e genererebbe una negazione del servizio ...

Il peggio è che spesso sono sistemi a basso costo (a basso costo) e per questo motivo, gli amministratori di rete si sforzano di ridurre il rischio che la loro parte si blocchi in seguito a carico e tende a utilizzare timeout aggressivi. Questo è il motivo per cui utilizzi la connessione TCP keep alive (se il keep-alive esegue il wrapping passa c'è qualcosa all'estremità) combinato con brevi timeout di rete.

Ma il vero problema qui è che gli sviluppatori di applicazioni sanno poco sugli usi di rete di basso livello e che agli amministratori di rete non interessa molto le applicazioni di alto livello. La vita è così ...