Sicurezza socket server client

Question

Supponendo di avere un server S e alcuni client (C) e ogni volta che un client aggiorna un server, un database interno sul server viene aggiornato e replicato agli altri client. Tutto questo è stato fatto usando i socket in un ambiente intranet. Credo che un utente malintenzionato possa facilmente annusare questo traffico di testo normale. I miei colleghi ritengono di essere eccessivamente paranoico perché siamo dietro un firewall.

Sono eccessivamente paranoico? Sei a conoscenza di qualsiasi exploit (link per favore) che ha sfruttato una situazione come questa e cosa può essere fatto in modo diverso. I client sono stati riscritti in Java ma il server sta ancora utilizzando C++. Qualsiasi cosa nel codice può proteggere da un attacco?

Answer 1

I vostri colleghi sono na ï ve.

Un attacco di alto profilo si è verificato a Heartland Payment Systems, un processore di carta di credito che ci si aspetterebbe di essere estremamente attenti alla sicurezza. Supponendo che le comunicazioni interne dietro il loro firewall fossero sicure, non hanno usato qualcosa come SSL per garantire la loro privacy. Gli hacker sono stati in grado di intercettare quel traffico ed estrarre dati sensibili dal sistema.

Ecco another story con un po 'più descrizione dell'attacco stesso:

Descritto da Baldwin come "del tutto un sofisticato attacco ", egli dice che ha stato impegnativo per scoprire esattamente come sia successo. I team di medici legali hanno scoperto che gli hacker "prendevano i numeri con sniffer malware mentre lo superava la nostra piattaforma di elaborazione", afferma Baldwin, . "Purtroppo, siamo sicuri che i nomi dei titolari di carta e i numeri siano stati esposti." I dati, tra cui transazioni con carta inviati tramite piattaforma di elaborazione interna di Heartland, viene inviato in chiaro, ha spiega: "Per quanto l'operazione viene trattati, deve essere in in chiaro modulo per ottenere la richiesta di autorizzazione fuori".

Answer 2

Si possono fare molte cose per impedire a un uomo in mezzo all'attacco. Per la maggior parte dei dati interni, all'interno di una rete protetta da firewall/IDS, non è davvero necessario proteggerli. Tuttavia, se si desidera proteggere i dati è possibile effettuare le seguenti operazioni: crittografia

1. usare PGP per firmare e messaggi cifrare messaggi sensibili
2. Crittografare
funzioni
3. Usa hash per verificare che il messaggio inviato non ha stato modificato.

È una procedura operativa standard per proteggere tutti i dati, tuttavia la protezione dei dati ha costi molto elevati. Con i canali sicuri è necessario disporre di un'autorità di certificazione e consentire un'ulteriore elaborazione su tutte le macchine coinvolte nella comunicazione.

Answer 3

All'interno del firewall della tua azienda, sei al sicuro da attacchi diretti di hacker dall'esterno. Tuttavia, le statistiche che non cercherò di scavare sostengono che la maggior parte dei danni ai dati di un'azienda sono fatti dall'INside. La maggior parte di questo è un semplice incidente, ma ci sono varie ragioni per cui i dipendenti devono essere scontenti e non scoperti; e se i tuoi dati sono sensibili potrebbero danneggiare la tua azienda in questo modo.

Esistono anche carichi di leggi sulle imbarcazioni su come gestire i dati di identificazione personale. Se i dati che stai elaborando sono di questo tipo, trattarli con noncuranza all'interno della tua azienda potrebbero anche aprire la tua azienda al contenzioso.

La soluzione è utilizzare le connessioni SSL. Vuoi usare una libreria preconfezionata per questo. Fornisci chiavi private/pubbliche per entrambe le estremità e tieni le chiavi private ben nascoste con i soliti privilegi di accesso ai file, e il problema dello sniffing è per lo più preso in considerazione.

Answer 4

SSL fornisce sia la crittografia che l'autenticazione. Java ce l'ha built in e OpenSSL è una libreria comunemente usata per C/C++.

Answer 5

Quasi tutte le applicazioni "importanti" che ho utilizzato si basano su SSL o su qualche altra metodologia di crittografia.

Solo perché ci si trova sulla rete intranet non significa che non si possa avere codice malevolo in esecuzione su alcuni server o client che potrebbero tentare di sniffare il traffico.

Answer 6

Sei paranoico. Stai parlando di dati che si spostano attraverso una rete interna, idealmente protetta.

È possibile annusare le informazioni? Sì, può. Ma è annusato da qualcuno che ha già violato la sicurezza della rete e ottenuto all'interno del firewall. Ciò può essere fatto in innumerevoli modi.

Fondamentalmente, per la maggior parte delle aziende VAST, nessun motivo per crittografare il traffico interno. Ci sono quasi sempre modi molto più facili per ottenere informazioni, dall'interno dell'azienda, senza nemmeno avvicinarsi a "sniffare" la rete. La maggior parte di questi "attacchi" provengono da persone che sono semplicemente autorizzate a vedere i dati in primo luogo e hanno già una credenziale.

La soluzione non è quella di crittografare tutto il traffico, la soluzione è di monitorare e limitare l'accesso, in modo che se i dati sono compromessi, è più facile rilevare chi ha fatto e a cosa hanno avuto accesso.

Infine, si consideri che gli amministratori di sistema e gli amministratori di database hanno praticamente carta bianca sull'intero sistema, poiché, inevitabilmente, qualcuno ha sempre bisogno di avere quel tipo di accesso. Semplicemente non è pratico criptare tutto per tenerlo lontano da occhi indiscreti.

Infine, stai facendo un grande clamore su qualcosa che è altrettanto probabile scritto su un appiccicoso appiccicato sul fondo del monitor di qualcuno comunque.

Answer 7

Un utente malintenzionato che ha accesso a un dispositivo all'interno della rete che gli offre la possibilità di rilevare l'intero traffico o il traffico tra un client e un server è il minimo richiesto.
Ad ogni modo, se l'attaccante è già dentro, lo sniffing dovrebbe essere solo uno dei problemi che dovrete prendere in considerazione.

Non sono molte le aziende che conosco che utilizzano socket sicuri tra client e server all'interno di una intranet, principalmente a causa dei costi più elevati e delle prestazioni inferiori.

Answer 8

Avete password nei vostri database? Spero davvero che la risposta sia sì. Nessuno potrebbe credere che la password che protegge un database sia eccessivamente paranoica. Perché non avresti almeno lo stesso livello di sicurezza * sugli stessi dati che fluiscono sulla tua rete. Proprio come un DB non protetto, il flusso di dati non protetti sulla rete è vulnerabile non solo allo sniffing, ma è anche modificabile da un utente malintenzionato. È così che vorrei inquadrare la discussione.

* Per lo stesso livello di sicurezza, intendo utilizzare SSL come alcuni hanno suggerito, o semplicemente crittografare i dati utilizzando una delle tante librerie di crittografia disponibili in giro se è necessario utilizzare socket non elaborati.