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