criptazione server to server

Area di discussione libera.

Moderatore: Staff

Regole del forum
1) Rispettare le idee altrui.
2) Evitare le offese dirette.
3) Leggere attentamente le risposte ricevute
4) Scrivere i messaggi con il colore di default, evitare altri colori.
5) Scrivere in Italiano o in Inglese, se possibile grammaticalmente corretto, evitate stili di scrittura poco chiari, quindi nessuna abbreviazione tipo telegramma o scrittura stile SMS o CHAT.
6) Appena registrati è consigliato presentarsi nel forum dedicato.

La non osservanza delle regole porta a provvedimenti di vari tipo da parte dello staff, in particolare la non osservanza della regola 5 porta alla cancellazione del post e alla segnalazione dell'utente. In caso di recidività l'utente rischia il ban temporaneo.
Rispondi
Avatar utente
ZeroUno
Staff
Staff
Messaggi: 5441
Iscritto il: ven 2 giu 2006, 14:52
Nome Cognome: Matteo Rossini
Slackware: current
Kernel: slack-current
Desktop: ktown-latest
Distribuzione: 01000000-current
Località: Roma / Castelli
Contatta:

criptazione server to server

Messaggio da ZeroUno »

Al lavoro mi stanno rompendo con la criptazione, come se fosse la risposta definitiva ai problemi dell'umanità :).

"qualsiasi comunicazione server to server, anche backend-backend, o sulla stessa lan, dovrebbe avvenire in maniera criptata".

L'idea è che sempre pià spesso gli attacchi avvengono dall'interno e quindi ok che anche l'accesso a tool interni deve avvenire in https e che gli accessi solo in ssh con privilegi separati, cioè ognuno deve entrare solo nei server di competenza e in questa fare solo ciò che gli spetta, e tracciare come si deve gli accessi.

Ma la paranoia a me pare una esagerazione che rischia di sfociare in falsa sicurezza.

Tecnicamente ci si dovrebbe proteggere da un men-in-the-middle interno, anche sulla stessa lan.
Cioè se buco un server sulla stessa lan e snoopo il traffico degli altri non devo poter leggere i dati che transitano.

Però alcuni flussi/protocolli/servizi/software vanno riscritti da zero.
Comunicazioni con oracle: si, oracle consente la criptazione delle connessioni, ma tanti driver non sono pronti o l'applicativo non li sfrutta appieno. Idem con mysql.
Io gestisco mailserver e webserver; la maggior parte dei webserver hanno apache in frontend che inoltrano poi su tomcat di backend; si, si possono mettere i tomcat in ascolto in ssl e forwardare su quella porta (ma mi perdo le ottimizzazione di ajp e modjk); i mailserver hanno un relay in frontend in ascolto in ssl che poi inoltra in backend in smtp; anche quà potrei attivare lo starttls.
Poi la comunicazione criptata di suo non inficia sulle performance, ma l'apertura della connessione ssl si, e di tanto.
Di un servizio importante l'abbiamo fatto ed abbiamo rollbackato perchè ammazzava le cpu. E' un servizio che fa un mare di request piccole e atomiche, quindi apre una connessione nuova ad ogni request; lo scambio di certificati e generazione chiavi di criptazione sdraiava tutto (fermo restando che all'apertura della connessione ssl viene passato l'intero certificato e catena di certificazione, quindi diversi KB).

E poi ci sono software proprietari, alcuni dei quali datati o non supportati.
Per questi e per quelli che fanno connessione atomiche che ne pensate di stunell?


In generale che ne pensate di questa panoramica e che esperienza avete?


Per me prima di riuscire a farmi un men-in-the-middle in backend devi avermi già bucato vari layer, quali gli switch di rete stessi per esempio; poi quando c'è in giro la virtualizzazione non ti basta nemmeno quello.
Packages finder: slakfinder.org | Slackpkg+, per aggiungere repository a slackpkg

Codice: Seleziona tutto

1011010 1100101 1110010 1101111 - 0100000 - 1010101 1101110 1101111

Avatar utente
ponce
Iper Master
Iper Master
Messaggi: 3022
Iscritto il: mer 5 mar 2008, 16:45
Nome Cognome: Matteo Bernardini
Slackware: slackware64-current
Kernel: 6.6.16
Desktop: lxde
Località: Pisa
Contatta:

Re: criptazione server to server

Messaggio da ponce »

ZeroUno ha scritto:la maggior parte dei webserver hanno apache in frontend che inoltrano poi su tomcat di backend; si, si possono mettere i tomcat in ascolto in ssl e forwardare su quella porta
non so se ho capito male ma in realta', in questi casi, la gestione dell'handshake ssl la deve necessariamente fare il frontend, e' a lui che si connette il client: non puoi usare un reverse proxy di apache che ti rimanda su un'altro handshake ssl.

Avatar utente
ZeroUno
Staff
Staff
Messaggi: 5441
Iscritto il: ven 2 giu 2006, 14:52
Nome Cognome: Matteo Rossini
Slackware: current
Kernel: slack-current
Desktop: ktown-latest
Distribuzione: 01000000-current
Località: Roma / Castelli
Contatta:

Re: criptazione server to server

Messaggio da ZeroUno »

ponce ha scritto:non puoi usare un reverse proxy di apache che ti rimanda su un'altro handshake ssl.
Si, è supportato da mod_proxy_http. Mi è capitato di usarlo a volte per esigenze diverse da quelle di sicurezza e non come regola. Tra l'altro in collaudo solo, perché introduce un mare di entropia.
Packages finder: slakfinder.org | Slackpkg+, per aggiungere repository a slackpkg

Codice: Seleziona tutto

1011010 1100101 1110010 1101111 - 0100000 - 1010101 1101110 1101111

Avatar utente
ponce
Iper Master
Iper Master
Messaggi: 3022
Iscritto il: mer 5 mar 2008, 16:45
Nome Cognome: Matteo Bernardini
Slackware: slackware64-current
Kernel: 6.6.16
Desktop: lxde
Località: Pisa
Contatta:

Re: criptazione server to server

Messaggio da ponce »

ma e' il protocollo ssl che non lo supporta: per fortuna, aggiungo, senno' sarebbero quasi banali da implementare i man-in-the-middle su ssl :D (perche' il certificato con cui si fa l'handshake e che cripta la comunicazione deve essere necessariamente diverso da quello nel backend, riferendosi a due host diversi)

non so cosa hai provato, ma quello che ti descrivevo tramite il mod_proxy di apache ti assicuro che non funziona.

Avatar utente
ZeroUno
Staff
Staff
Messaggi: 5441
Iscritto il: ven 2 giu 2006, 14:52
Nome Cognome: Matteo Rossini
Slackware: current
Kernel: slack-current
Desktop: ktown-latest
Distribuzione: 01000000-current
Località: Roma / Castelli
Contatta:

Re: criptazione server to server

Messaggio da ZeroUno »

Non avevo capito che intendevi.
Certo, l'handshake verso il browser li fa l'apache di frontend. Verso il backend si stabilisce un nuovo handshake con nuovo certificato (che in verità può essere anche lo stesso, basta che non ti fai rubare la chiave privata).

Ma il fatto è che mentre tra fe e be c'è routing e quindi un margine relativo per implementare un men-in-the-middle, nelle comunicazioni tra due macchine sulla stessa lan come ce lo piazzi un server in mezzo? Un tcpdump di una terza macchina prende solo il traffico in broadcast (a meno che non usi i vecchi hub).
Packages finder: slakfinder.org | Slackpkg+, per aggiungere repository a slackpkg

Codice: Seleziona tutto

1011010 1100101 1110010 1101111 - 0100000 - 1010101 1101110 1101111

Avatar utente
ponce
Iper Master
Iper Master
Messaggi: 3022
Iscritto il: mer 5 mar 2008, 16:45
Nome Cognome: Matteo Bernardini
Slackware: slackware64-current
Kernel: 6.6.16
Desktop: lxde
Località: Pisa
Contatta:

Re: criptazione server to server

Messaggio da ponce »

ZeroUno ha scritto:Ma il fatto è che mentre tra fe e be c'è routing e quindi un margine relativo per implementare un men-in-the-middle, nelle comunicazioni tra due macchine sulla stessa lan come ce lo piazzi un server in mezzo? Un tcpdump di una terza macchina prende solo il traffico in broadcast (a meno che non usi i vecchi hub).
puoi fare arp spoofing, ad esempio.

Avatar utente
ZeroUno
Staff
Staff
Messaggi: 5441
Iscritto il: ven 2 giu 2006, 14:52
Nome Cognome: Matteo Rossini
Slackware: current
Kernel: slack-current
Desktop: ktown-latest
Distribuzione: 01000000-current
Località: Roma / Castelli
Contatta:

Re: criptazione server to server

Messaggio da ZeroUno »

Ne inventano una più del diavolo.
Packages finder: slakfinder.org | Slackpkg+, per aggiungere repository a slackpkg

Codice: Seleziona tutto

1011010 1100101 1110010 1101111 - 0100000 - 1010101 1101110 1101111

ilmich
Master
Master
Messaggi: 1645
Iscritto il: lun 16 lug 2007, 17:39
Slackware: 15.0 64bit
Kernel: 5.15.27
Desktop: kde
Località: Roma

Re: criptazione server to server

Messaggio da ilmich »

premesso che una volta lessi una frase che riuso spesso e che dice grosso modo che la sicurezza non è una prodotto, ma un processo ti sono vicino in quanto anche nella mia azienda si sta giustamente dando priorità a questo tipo di interventi.
Ci sto smadonnando da sviluppatore pero in quanto su alcuni sistemi abbiamo java 6 che data la sua vetustità non supporta robe tipo il tls1.2 o alcuni algoritmi di cifratura che sono spuntati nel frattempo e che vengono usati nell'handshake ssl.

quindi secondo me non si è mai sicuri solo cifrando il traffico, ma bisognerebbe unire piu' cose tipo firewall, mutua autenticazione etc etc etc

a me pero' viene una curiosità su quanto detto da ponce sull'arp spoofing.
in azienda i certificati che utilizziamo vengono emessi da una CA interna e quindi verificati di conseguenza... ammesso che io riesca a spoofare l'arp cache del server vittima dandogli il mio indirizzo ip, dovrei avere a mia volta un certificato emesso in questo modo (oppure una copia di quello che sta sul server che voglio 'clonare') per poter portare a termine l'attacco giusto?!?!? perchè diversamente l'handshake se il software non è 'liberale' non dovrebbe andare a buon fine :-k

p.s: per i servizi http per ottimizzare un pochettino la storia dell'ssl potresti usare (se supportato) la tecnica che usano i browser ovvero il keep-alive unito ad un pool di connessioni http. però chiaramente devi modificare il software chiamante.
#LiveSimple and #ProgramThings
https://github.com/ilmich
http://ilmich6502.it/

Avatar utente
ponce
Iper Master
Iper Master
Messaggi: 3022
Iscritto il: mer 5 mar 2008, 16:45
Nome Cognome: Matteo Bernardini
Slackware: slackware64-current
Kernel: 6.6.16
Desktop: lxde
Località: Pisa
Contatta:

Re: criptazione server to server

Messaggio da ponce »

miklos ha scritto:a me pero' viene una curiosità su quanto detto da ponce sull'arp spoofing.
in azienda i certificati che utilizziamo vengono emessi da una CA interna e quindi verificati di conseguenza... ammesso che io riesca a spoofare l'arp cache del server vittima dandogli il mio indirizzo ip, dovrei avere a mia volta un certificato emesso in questo modo (oppure una copia di quello che sta sul server che voglio 'clonare') per poter portare a termine l'attacco giusto?!?!? perchè diversamente l'handshake se il software non è 'liberale' non dovrebbe andare a buon fine :-k
quando fai arp spoofing e' molto difficile "sniffare" traffico ssl senza che ci sia un modo per accorgersene, in genere si preferisce redirigere le richieste https su http e poi impersonare il client verso il server, pero' il client nel suo browser si connette via http e non vede il "lucchettino" sulla sinistra dell'url nella barra dell'indirizzo (si conta sul fatto che l'utente non ci faccia caso)

http://techgenix.com/understanding-man- ... arp-part4/

se hai una copia della parte privata del certificato che sta sul server allora diventa tutto piu' facile.

Avatar utente
ZeroUno
Staff
Staff
Messaggi: 5441
Iscritto il: ven 2 giu 2006, 14:52
Nome Cognome: Matteo Rossini
Slackware: current
Kernel: slack-current
Desktop: ktown-latest
Distribuzione: 01000000-current
Località: Roma / Castelli
Contatta:

Re: criptazione server to server

Messaggio da ZeroUno »

miklos ha scritto:Ci sto smadonnando da sviluppatore
Questo è il concetto.
Io sono un sistemista; se mi chiedi di cifrare tutti i canali e non tiri fuori i soldi (e tempo) per lo sviluppo mi tocca rispondere male (e se io posso argomentare al mio capo che un tecnico, per lui è più difficile argomentare ai suoi superiori che non lo sono e sanno solo la parola criptazione e sicurezza senza conoscerle), e allora mi tocca fare i salti mortali.
a me pero' viene una curiosità su quanto detto da ponce sull'arp spoofing.
in azienda i certificati che utilizziamo vengono emessi da una CA interna e quindi verificati di conseguenza...
e questo è un caso in cui l'ssl server-to-server ti salva (a meno di non rubare la chiave o fare qualche impiccio che rischia di essere rilevato come sospetto) e il motivo per cui si spinge su quella strada

per i servizi http per ottimizzare un pochettino la storia dell'ssl potresti usare (se supportato) la tecnica che usano i browser ovvero il keep-alive unito ad un pool di connessioni http. però chiaramente devi modificare il software chiamante.
e quì si ritorna al discorso iniziale degli investimenti. Finchè posso fare qualcosa con le funzionalità preesistenti di un apache e di un tomcat che fa questo ok, ma quando il software non lo supporta ko. Mentre il caso che dicevo delle chiamate piccole e tante è la natura del servizio; sono tante chiamate completamente indipendenti tra di loro e quindi ognuna deve avere un'apertura e chiusura della connessione; l'applicazione supporta l'ssl nativamente ma la macchina non reggerebbe.

ponce ha scritto:in genere si preferisce redirigere le richieste https su http
però per questo non ti basta mettere un server al centro. Visto che non parlo di browser ma di traffico server to server, se l'applicativo client genera richieste ssl e il server è in listen in ssl, l'unico modo per prendere il traffico è rubare le chiavi o generare un certificato da una CA censita nel client.
Packages finder: slakfinder.org | Slackpkg+, per aggiungere repository a slackpkg

Codice: Seleziona tutto

1011010 1100101 1110010 1101111 - 0100000 - 1010101 1101110 1101111

Rispondi