Filtraggio della porta 3306 e apertura solo in caso di necessità - La massima difesa da DB hacking? (la domanda aveva un aggiornamento importante)

2

Non sono del settore IS e voglio chiederlo: possiamo concludere che il filtraggio della porta 3306 e il solo unfiltering nei momenti di bisogno è la difesa definitiva da DB hacking?

Supponiamo di svuotare la porta per 2-3 ore in un anno, solo per apportare alcune modifiche al DB ( dire, con Workbench , o in un modo un po 'meno sicuro, PHPmyadmin) e quindi filtrare di nuovo per alcuni lunghi mesi.

Nel mio caso, ad esempio, non posso utilizzare una whitelist IP (principalmente a causa di restrizioni di viaggio), quindi mi sembra la soluzione migliore che ho al momento.

Possiamo dire che finché la porta 3306 (o una porta sostitutiva) viene filtrata, sono completamente protetto dai BFA o dalle iniezioni SQL sul DB (dato che il Firewall non ha violazioni) a meno che qualcuno non freni nel PC stesso e facendo cambiato da lì?

Aggiornamento - Mi sembra di aver avuto un difetto nella domanda:

Il fraseggio originale della domanda è sopra e alcuni rispondono, ma sembra che abbia confuso l'accesso al DB in corso tramite la porta 3306, con l'accesso interntal da PHPmyadmin (PMA), come pure il problema dei BFA, con il problema delle iniezioni SQL.

Sottolineerò il problema di BFA di seguito:

So che, anche se filtrerei la porta con CSF e non la sviterei più in seguito - che da una mano, sarei ancora esposto al knock-out della porta (che è un caso da solo) , e dall'altra parte, sarebbe ancora in grado di utilizzare PMA dall'URL, qualcosa che potrei proteggere in uno dei seguenti due modi (o una combinazione di essi):

  1. Installazione e disinstallazione di PMA ogni volta di nuovo, in modo automatico con uno script che contiene il timeout di disinstallazione, dopo 2 ore.

  2. Accesso a PMA in https (tls).

posta JohnDoea 23.12.2016 - 10:27
fonte

2 risposte

1

La difesa principale nella gestione del database sta configurando un'autenticazione avanzata del database. La tua connessione al database deve essere crittografata (ad esempio SSH, TLS, VPN) e il database dovrebbe autenticarti con una password sicura e preferibilmente con un certificato client.

La difesa del database periferico è per proteggere l'accesso usando VPN, Firewall, whitelist IP.

Sia che si usi Workbench o PHPMyAdmin ha poco a che fare con la protezione dell'accesso al proprio database. Entrambi possono essere configurati per una strong sicurezza, ed entrambi possono rovinarti.

    
risposta data 23.12.2016 - 13:28
fonte
4

tl; dr : assolutamente no.

Ci vuole meno di 3 ore prima che qualcuno possa distruggere completamente il tuo Database. Lo dirò di nuovo: la tua idea nella sua forma attuale è una pratica terribile e NON è un sostituto per l'igienizzazione dell'input

~~ Anche se avessi detto "Metteremo il DB dietro un firewall e gli IP della whitelist, potrebbe essere stata un'idea migliore. ~~ - Vedo che hai aggiornato il tuo post e non posso farlo.

Ecco un paio di motivi per cui ritengo che non sia fattibile:

Scenario : sono una persona cattiva che osserva la tua rete per qualsiasi tipo di debolezza. Sono molto, molto paziente.

Che cosa succede: dici di non essere in grado di utilizzare una whitelist IP. Ciò significa che ora posso attaccare il tuo server in una moltitudine di modi e non preoccuparti di dover spoofare la mia posizione. Come lo farei?

  • Configura uno script per scansionare il tuo sito ogni, ad esempio, prova a risolvere / phpmyadmin e osserva se si risolve. Se lo fa, comincio la mia bruteforce intelligente. Non molto pulito e molto rumoroso, ma ehi - funziona quasi sempre.

  • Nessuna delle soluzioni attuali mi impedirà di interrompere il tuo sito nelle operazioni quotidiane: l'iniezione SQL non viene eseguita solo su una pagina, funzionerà ovunque nel tuo sito dove non ti sei preoccupato di disinfettare i tuoi input e stai chiamando o spingendo i dati sul tuo DB. Inizierò metodicamente l'attacco a ciascuna di queste aree durante tutto l'anno.

Questo dovrebbe darti un'idea abbastanza precisa del perché questo non è fattibile.

2nd tl; dr : non farlo.

    
risposta data 23.12.2016 - 10:33
fonte

Leggi altre domande sui tag