I protocolli di commutazione sono una misura di sicurezza che vale la pena implementare?

Question

I protocolli di commutazione sono una misura di sicurezza che vale la pena implementare?

#1 da (5 voti)
#2 da (0 voti)

3

Distribuiamo le nostre applicazioni internet in più vlans e c'è una regola che parla da un vlan al successivo deve essere fatto in un altro protocollo o in un'altra implementazione del protocollo.

es.

[Internet] --https-> [apache@VLAN1] --ajp--> [tomcat@VLAN2] --jdbc--> [pgsql@VLAN3]

Vs.

[Internet] --https-> [apache@VLAN1] --https--> [apache@VLAN2] --https--> [apache@VLAN3]

Vs.

[Internet] --https-> [apache@VLAN1] --https--> [tomcat@VLAN2] --https--> [nginx@VLAN3]

Il motivo è che se c'è un exploit in una delle implementazioni del protocollo non è possibile utilizzare lo stesso exploit per entrare nell'host nella prossima VLAN.

A volte questo è difficile da ottenere se tutti i servizi forniscono API REST.

C'è qualche letteratura in cui potrei leggere su questo? O approcci che ottengono la stessa protezione.

rest http vlans

posta n3utrino 17.04.2018 - 16:29

fonte

2 risposte

Leggi altre domande sui tag rest http vlans

Ricerca del proprietario di un nome di rete Wi-Fi che potrebbe essere una minaccia Ha senso crittografare il database per conformarsi a GDPR?

score 5 · Answer 1

Il passaggio dei protocolli come descritto essenzialmente richiede l'analisi della sintassi e della semantica dei dati trasferiti per tradurre i dati in un nuovo protocollo. Significa anche che devi avere una semantica chiaramente definita, in primo luogo. Avere una semantica chiaramente definita può già migliorare la sicurezza. E che questa semantica viene implicitamente applicata quando si traducono i dati in un nuovo protocollo, inoltre diminuisce la capacità di un utente malintenzionato di sfruttare il destinatario.

La definizione e l'applicazione della semantica potrebbe anche essere eseguita senza tradurre in un nuovo protocollo. Ma per tradurre in un protocollo diverso è necessaria una definizione più stretta di sintassi e semantica ed è più difficile fare scorciatoie per saltare alcuni controlli. Pertanto, richiedere la commutazione dei protocolli è una buona idea per assicurarsi che gli sviluppatori sappiano in realtà come dovrebbero apparire i dati in primo luogo e che li applicano anche.

Naturalmente, questo funziona solo se è necessaria una traduzione reale. Questo sarebbe nel tuo esempio tra HTTP e JDBC ma non tra HTTPS e HTTP. Poiché HTTPS è solo HTTP su TLS e sarebbe sufficiente rimuovere il livello TLS anziché applicare la semantica del protocollo.

score 0 · Answer 2

Questo è pensato per essere un commento. Vorrei poter commentare (non ancora del tutto), ma basandomi su l'esempio sopra , direi che non sembra esserci un gran vantaggio andando da un protocollo crittografato (https) a un altro protocollo di testo semplice (http) all'interno della rete a uno (possibilmente) non crittografato (jdbc). Che è criptato per iniziare se è buono! lol. E non è sempre possibile forzare i protocolli. Potresti essere bloccato con JDBC.

Ma se craccano qualsiasi parte della catena alimentare lì, ottengono i dati, anche se ogni segmento è crittografato in modo diverso, come se fosse la VLAN1 in realtà è un sistema di bilanciamento del carico che sta facendo offload SSL e la connessione è ancora Da HTTPS a VLAN2, ma chiavi diverse e sessione SSL, quindi crittografato dal livello dell'app con un JDBC sicuro (che dal livello App non è probabilmente un'intera scelta per i protocolli).

Encrypted end to end, sì. Sempre desiderabile, ma mi chiedo se è quello che intendevano invece.

[Internet] --https offload- > [VLAN1] --https new session - > [VLAN2] --secure jdbc - > [VLAN3]

Questo fermerebbe mitm.