Connessioni database MySQL (non SSL) protette tramite IP di origine / destinazione, quanto sono pericolose?

0

Sto testando una soluzione MySQL Amazon RDS: il database è fornito da Amazon RDS ma la logica dell'applicazione (script php) che accede ai dati è ospitata in un altro server diverso (non amazon).

Supponiamo che per qualche ragione non possa usare le connessioni SSL MySQL e mi baso solo sulla sicurezza fornita dalle politiche di origine / destinazione che puoi impostare su Amazon VPC: posso dire che l'istanza MySQL può accettare SOLO traffico da un IP specifico (l'IP del mio server Web) e può inviare SOLO traffico ad un IP specifico (di nuovo, l'IP del mio server Web).

Quanto è pericolosa questa soluzione? So che la domanda sembra troppo vaga, ma ci sono alcuni dettagli specifici che vorrei chiarire; proviamo a vedere cosa può succedere:

1) I dati (comprese le credenziali MySQL) vengono inviati in chiaro su Internet, quindi se si tratta di dati sensibili, potrebbe essere visto da una parte esterna. Quanto è facile questo attacco? Il fatto che stiamo usando IP e non i nomi di dominio nella politica rende un attacco man-in-the-middle più difficile da eseguire?

2) Supponiamo che un utente malintenzionato riesca a sottrarre le credenziali MySQL usando 1), quanto sarebbe facile eseguire query arbitrarie sull'istanza MySQL? L'autore dell'attacco deve fingere di avere l'IP del mio server web, operazione che dovrebbe essere più difficile in "modalità di ricezione" piuttosto che in "modalità di invio". Quindi immagino ci siano due diverse categorie di domande che dovremmo considerare separatamente:

A: query SELECT arbitrarie (in generale, query che richiedono il ritorno di alcuni tipi di dati)

B: DELETE arbitrato, UPDATE, INSERT, ... (in generale, query che non richiedono una risposta)

Direi che le query B sono più facili da eseguire ma ciò potrebbe dipendere da altri fattori come il protocollo specifico usato da MySQL.

    
posta Eugenio 10.05.2016 - 16:44
fonte

1 risposta

3

Hai ragione a essere preoccupato per gli scenari che hai presentato:

  1. Se si verifica un attacco MITM, non può essere contrastato a meno che non si utilizzi SSL. Il filtro IP non sarà di aiuto perché l'attacco è già "nel mezzo" della connessione, quindi tutto il traffico lo attraverserà in testo normale. Una volta che l'utente / pass è stato afferrato, l'attaccante può fare tutto ciò che le credenziali consentono. L'utente malintenzionato potrebbe persino spoofare l'IP e dirottare la connessione senza consentire il ritorno del traffico all'IP originale, se lo desidera.
  2. Per gli attacchi che non sono MITM, il filtro IP aiuta un bel po ', perché anche lo spoofing IP consente solo i messaggi di essere inviati, ma non ricevuti, e anche in questo caso dovrebbero ancora prima capire le credenziali. Se avessero in qualche modo scoperto le credenziali potevano spoofare il loro IP originario e inviare comandi come eliminare, aggiornare, inserire, ecc., Ma sarebbe piuttosto difficile sapere se stava producendo o meno effetti, quindi sarebbe inutile loro da provare (Come lanciare sassi in un lago e chiedersi se stai colpendo un pesce durante la discesa.)

La soluzione migliore è utilizzare SSL o almeno spostare l'applicazione e il DB nella stessa rete. Se non puoi assolutamente farlo, il MITM è l'attacco più realistico di cui dovresti preoccuparti, ma anche quelli sono piuttosto rari, rispetto ad altri tipi di attacchi che verrebbero tentati. Probabilmente è più probabile che uno sviluppatore perderà accidentalmente le credenziali piuttosto che eseguire un MITM contro di te.

    
risposta data 10.05.2016 - 18:28
fonte

Leggi altre domande sui tag