Come posso spiegare al cliente che i checksum TCP MD5 di rfc2385 non possono essere attivati per i server web linux?

Question

Come posso spiegare al cliente che i checksum TCP MD5 di rfc2385 non possono essere attivati per i server web linux?

#1 da (2 voti)
#2 da (1 voti)
#3 da (1 voti)

11

Ho avuto una lunga conversazione con un cliente in cui eseguono una scansione di sicurezza Rapid7 che poi avverte riguardo ai checksum TCP MD5 mancanti sulla porta 80. Questo è quello che penso di sapere:

RFC 2385 è stato progettato per proteggere BGP , e per estensione protocolli di tipo BGP (ovvero connessioni TCP a lunga esecuzione).
BGP utilizza connessioni TCP di lunga durata, HTTP no.
Encryption / IPSec ha sostituito RFC 2385 per proteggere BGP.
L'attacco RST TCP è contro connessioni TCP a lunga esecuzione perché l'attacco si basa sulla probabilità.
L'impatto sulla reimpostazione di una connessione keep-alive HTTP è che la richiesta successiva lo riavvierà.
La maggior parte delle connessioni trasferisce i dati in millisecondi, la finestra di attacco è troppo piccola per consentire a HTTP di mirare in modo efficace. L'attacco dipende dalle dimensioni della finestra e dalla larghezza di banda dell'aggressore contro il server e sembra richiedere alcuni secondi anche in buone condizioni, in base alla pagina 25 di Scivolando nella finestra: TCP resetta gli attacchi )
Una visualizzazione web è in genere costituita da più connessioni per ciascun client connesso che rende questo tipo di denial of service poco attraente rispetto alle alternative.
Linux (in particolare RHEL o Debian) ha il supporto per rfc2385 ma non può essere globalmente abilitato.
NGINX e Apache non dispongono di opzioni di configurazione per aprire socket con checksum tcp-md5 abilitati.
Anche se rfc2385 era attivo per HTTP, non risolveva un problema, ma aumentava il carico sul server. Che è solo un piccolo punto laterale.

Ho cercato di spiegare che rfc2385 non è rilevante per i server web, ma stanno dicendo che è un problema con TCP che, pur vero, semplifica che si tratti di un attacco contro una specifica natura del Connessione TCP.

Ho cercato di spiegare che né Apache né Nginx possono abilitare ciò che stanno chiedendo. Continuano a inviarmi documenti della knowledge base che menzionano Windows, Cisco, NetBSD, BGP, ma mai nulla che si riferisca ad apache né a nginx.

Oltre ai documenti collegati, li ho inviati LWN spiegandoli:

It would be hard to use this technique to shut down a web server; HTTP connections tend to be short-lived to begin with.

C'è una patch disponibile su Windows che corregge l'avviso che stanno inviando come suggerimento, ma chiaramente non ha nulla a che fare con linux.

Sto parlando di sciocchezze? Quale sarebbe il tuo suggerimento di convincere il cliente a rispettare la sicurezza a preoccuparsi di entrare nella mia stessa pagina?

apache tcp nginx security-theater

posta Kit Sunde 23.10.2014 - 09:33

fonte

3 risposte

Leggi altre domande sui tag apache tcp nginx security-theater

Come viene calcolata (o stimata) l'entropia disponibile in / dev / random? Ripristina l'archivio dei certificati attendibili di Windows ai valori predefiniti

score 2 · Answer 1

L'uso di MD5 per il controllo della coerenza è una chiara violazione di CWE-327: Uso di un algoritmo crittografico danneggiato o rischioso . Qualsiasi protezione fornita da RFC-2387 viene annullata dall'uso di un algoritmo obsoleto e non sicuro.

Rapid7 sta rendendo Internet meno sicuro con questa raccomandazione. Questa "vulnerabilità" di BS è un rumore più inutile che soffoca i risultati reali. La cieca raccomandazione di Rapid7 di RFC-2385 rende più difficile l'elaborazione della richiesta HTTP, rendendo quindi il server Web più vulnerabile agli attacchi DDoS.

Mi lamenterei con Rapid7 e li incoraggio a riconsiderare seriamente questa raccomandazione sulla sicurezza del culto del carico . Solo perché è facile da testare, non significa che sia rilevante. Chiedi a Rapid7 di dire al tuo cliente che questa non è una preoccupazione.

score 1 · Answer 2

La mia risposta sarebbe una versione attenuata di questo: "Stanno suggerendo di utilizzare uno schema di autenticazione della chiave condivisa non criptato progettato per un altro caso d'uso.Il loro consiglio è bizzarro e inutile.Non ci sono browser Web che sono in grado di generare l'hash con chiave necessario per ogni segmento TCP. "

score 1 · Answer 3

La tua profonda esperienza con gli scanner di vulnerabilità è senza dubbio molto al di là del mio, e la tua esperienza con le complessità di TCP lo è ancora di più. Ma forse posso condividere il mio metodo generale di trattare con i clienti che guardano un risultato della scansione di vulnerabilità, vedere un'icona gialla / arancione / rossa accanto a un oggetto e avere una reazione di grande preoccupazione senza rendersi conto che non esiste alcun vero problema.

Spiega che mentre gli scanner di vulnerabilità a volte possono essere notevoli nel rilevare problemi sottili ma vitali, a volte possono anche essere assolutamente idioti nel vedere problemi che non sono supportati da alcun rischio sostanziale.
Spiega perché in questo caso non vi è alcun sostanziale rischio addizionale di sicurezza causato da questo articolo. (Nota: l'intera faccenda ovviamente presuppone che non ci sia, ovviamente.) In altre parole, spiega perché lo scanner ha torto di prestare attenzione ad esso.
O (a) spiega come continuerai comunque a correggere il non-problema in modo che possano sentirsi a proprio agio nell'ottenere una bolletta (apparente) pulita dallo scanner, o (b) se non è pratico, spiega sia perché il problema non può essere praticamente "riparato" e come possono documentare (per gli adempimenti, i loro capi, chiunque / qualunque cosa) che dopo aver investigato & la contemplazione sono fiduciosi che il problema è fondamentalmente solo una sorta di falso positivo.

Sembra che tu abbia un "Ma ... ma ... lo strumento costoso dice che c'è una vulnerabilità lì!" cliente. Forse provate una tattica per enfatizzare che anche se poteste implementare questo comportamento di checksum in un modo che lo scanner vorrebbe, ci vorrebbe un bel po 'del vostro tempo (ad esempio il loro denaro) e potenzialmente anche richiedere alcuni tempi di inattività per il server. Nella mia esperienza, menzionare queste considerazioni è in qualche modo abbastanza spesso da far acquisire a un cliente un nuovo senso di accettazione riguardo alla convivenza con una vulnerabilità di non vulnerabilità. I miei due centesimi, comunque.