Proteggi il traffico TCP per la comunicazione tra processi

Se si desidera limitare la comunicazione tra processi su una macchina, suggerirei di eliminare TCP e utilizzare invece il socket di dominio Unix. Il socket di dominio Unix può essere utilizzato esattamente allo stesso modo di TCP (è un socket bidirezionale), ma crea un file socket invece di ascoltare su una porta TCP. È possibile controllare l'autorizzazione sul file socket utilizzando le autorizzazioni standard del filesystem. Twisted supporta il socket dominio Unix.

Se davvero devi usare TCP, allora puoi usare SSL senza crittografia . Per impostazione predefinita, il codice eNULL e l'autenticazione aNULL non sono consentiti in OpenSSL, ma è possibile richiederlo esplicitamente. Personalmente non lo consiglierei.

Potresti anche avere un po 'di fortuna nel definire regola iptable che limita il modo in cui i processi può connettersi ad alcune porte TCP.

Nel complesso, cercare di difendersi da qualcuno con accesso root / fisico illimitato alla tua macchina è uno sforzo inutile, e la crittografia per la comunicazione tra processi all'interno della stessa macchina è piuttosto sciocca ma è abbastanza innocua.

L'ascolto sul traffico di localhost è possibile anche su Windows e Linux.

In Linux tcpdump -i lo .

Devi prendere in considerazione almeno la codifica con algoritmo speciale della tua comunicazione e anche considerare di proteggere il processo del broker da dumping, debug o reverse-engineering.

Le comunicazioni tra questi processi possono sempre essere intercettate da un utente malintenzionato con accesso privilegiato al sistema.

Con l'accesso root alla casella, l'utente malintenzionato possiede il sistema e può aggirare qualsiasi cosa e tutto ciò che si implementa (per la maggior parte). Traffico crittografato? Le funzioni che elaborano le chiavi di crittografia possono essere agganciate o la memoria di processo può essere scaricata. L'anti-reverse engineering è una possibilità, ma può essere sempre aggirato da qualcuno abbastanza abile. Il modo più efficace e sicuro per farlo sarebbe scrivere un LKM che imponga la sicurezza dei tuoi processi a livello di kernel; questo richiede una grande esperienza nella programmazione del kernel ed è estremamente difficile da fare correttamente (oserei dire impossibile ?!) - qualcuno troverà sempre una scappatoia, anche se è qualcosa da considerare.

Inoltre, gli utenti non root non possono creare socket grezzi, che sono necessari per sniffare i pacchetti (il che significa che un utente malintenzionato avrà bisogno dell'accesso di root al sistema per intercettare le comunicazioni tra i processi).

La protezione delle informazioni su un sistema da parte di un utente malintenzionato che già la possiede non è un'attività banale. Puoi rendere più difficile l'accesso a tali informazioni, ma non puoi mai proteggerle completamente.