Re: SSH inspection. Pareri?
Flavio Visentin <[email protected]> Thu, 9 May 2019 14:55:33 +0200
| Newsgroups | gmane.comp.security.italian |
|---|---|
| Message-ID | <[email protected]> |
On 07/05/19 16:05, Marco Ermini wrote: > Salve >=20 > Ci sono tool appositi che permettono di effettuare questa ispezione=20 > senza violazione della privacy o gli altri svantaggi che citi (e.g. Tec= tia). Non conosco tale prodotto ma mi informer=C3=B2 (sempre cultura in pi=C3=B9= ). Non=20 mi viene in mente per=C3=B2 come possa essere tutelata (tecnicamente) la=20 privacy nel momento in cui metto in atto un MITM sulle comunicazioni. > L'ispezione di SSH in realt=C3=A0 un senso ce l'ha eccome, dato che per= mette=20 > di tunnellizzare qualsiasi cosa, Bello e brutto del protocollo :) > ed =C3=A8 un legittimo desiderio che il=20 > protocollo sia utilizzato soltanto per quello che si =C3=A8 progettato = di=20 > fare (SFTP) bloccando tutto il resto (tunnel, esecuzione di binari,=20 > shell, X11...). > Fortinet (cos=C3=AC come Tectia) =C3=A8 in grado di fare questi=20 > filtri e rispondere a questo requisito di sicurezza. Questo per=C3=B2 =C3=A8 gestibile con la configurazione corretta del demo= ne ssh. Per esempio in questo specifico caso tutti gli utenti che devono fare=20 solo SFTP sono vincolati al solo subsystem SFTP, con impossibilit=C3=A0 d= i=20 fare tunnel o eseguire comandi (al netto di bug di openssh che comunque=20 dubito verrebbero intercettati dal firewall e che la storia riporta come=20 molto molto rari). Per gli admin, unici utenti che possono eseguire binari a scelta, non=20 vedo invece come possano essere vincolati da un tool esterno pi=C3=B9 di=20 quanto non si possa fare da configurazione ssh. Voglio dire, un semplice=20 "cat | aespipe" blocca qualsiasi possibile intercettazione essendo una=20 crittografia a s=C3=A9 stante. A meno di non bloccare qualsiasi flusso no= n=20 conosciuto (ma in tal caso blocchi i task amministrativi tout court)=20 oppure di adottare una procedura di controllo che, a posteriori, in caso=20 di rilevamento di traffico considerato anomalo alzi la bandierina (IDS)=20 e vi sia una verifica personale dell'operato (ovvero il resp sicurezza=20 non chieda conto di quel traffico all'amministratore che lo ha generato). Quest'ultimo aspetto, a cui precedentemente non avevo pensato, porta=20 effettivamente un miglioramento della sicurezza, almeno per la parte di=20 DLP, ma mi pare di difficile realizzazione in un'infrastruttura=20 mediamente complessa. Anche in questo caso per esempio se dovessi=20 realmente avere necessit=C3=A0 tanto stringenti, preferirei implementare = un=20 sistema di accesso amministrativo in cui siano richiesti=20 contemporaneamente N admin di M totali per poter accedere alla macchina=20 e quindi avere un controllo intrinseco dell'operato del singolo (quello=20 che per esempio viene fatto in alcune aziende per l'accesso fisico al=20 CED in cui un utente non pu=C3=B2 entrare da solo nella sala ma deve semp= re=20 essere accompagnato dal responsabile preposto). Nel contesto comune vedo pi=C3=B9 l'utilizzo di questa feature come "pezz= a"=20 utile per limitare certe funzionalit=C3=A0 in caso di configurazioni erra= te.=20 Ma ha senso usare questo strumento o ha forse pi=C3=B9 senso revisionare = le=20 configurazioni con un corretto processo di configuration management (che=20 rientra comunque nelle best practice di sicurezza)? > Si tratta quindi di bilanciare pro e contro e decide lo strumento adatt= o. In medio stat virtus. :) Grazie per lo spunto di riflessione. --=20 Flavio Visentin | \|||/ | @/0.0\@ | \ - / +------------------oOOo---oOOo------------------ There are only 10 types of people in this world: those who understand binary, and those who don't. GPG Key: http://www.zipman.it/gpgkey.asc ________________________________________________________ http://www.sikurezza.org - Italian Security Mailing List