Is there any major vulnerability in doing this?

Dipende dal modello di configurazione / minaccia / ecc. Ci sono un sacco di variabili da considerare.

Can someone else see the daemon command running?

Sì, chiunque abbia accesso a una delle due macchine può vederlo, inclusi tutti i parametri.

Linux:

ps -aux | grep -i 'ssh'

MacOS:

ps -Aj | grep -i 'ssh'

Ecco un esempio:

$ ps -aux | grep -i 'ssh'
root      444  0.0  0.0  37588  5692 ?        Ss   13:20   0:00
/usr/local/bin/ssh -L XXX:127.0.0.1:XXX -p XXXX root@[ipaddress] 

But even if that was possible, wouldn't they need the SSH key to have access to the server?

Bene, sì e no. Ci sono alcuni fattori da considerare:

• Se qualcuno è in grado di compromettere il tuo server per qualsiasi motivo, potresti causare la compromissione del server di database remoto in base alla configurazione e alle autorizzazioni.

• Se il server SSH consente l'autenticazione basata su password, questo potrebbe presentare un problema se rilevano credenziali sul proprio sistema.

• Se il tuo server SSH accetta chiavi, ma la tua chiave non richiede una passphrase, ciò può portare a compromissione del server del database.

  • È necessario assicurarsi che esista una passphrase significativamente strong per utilizzare la chiave SSH (best practice) per impedire a un utente malintenzionato di compromettere immediatamente il server database dopo aver acquisito la chiave.

• Se un utente malintenzionato compromette il server del database, potrebbe essere in grado di compromettere altri server nella rete. Potresti aprire una scatola enorme di vermi qui.

Difesa in profondità

Come per ogni aspetto della sicurezza, è importante considerare il modello di minaccia e la stratificazione. La difesa in profondità è il processo di creazione di una serie di diversi livelli di sicurezza per prevenire il maggior compromesso possibile.

Chiediti: "Che cosa ho e cosa sto cercando di proteggere?" Questo è il punto di partenza per l'ingegneria della sicurezza.

In questo scenario ti consiglierei qualcosa di simile (assumendo che tu sia il proprietario del DB):

1. Assicurati che le applicazioni web siano sufficientemente resistenti per prevenire l'esecuzione di codice in modalità remota, sql injection, ssrf, lfi, rfi e altre vulnerabilità.

2. Assicurati che il server web esponga solo le porte necessarie come 80/443.

3. Assicurarsi che il server del database stesso comunichi solo con la tua app Web tramite SSH. Per impostazione predefinita, negherà tutto eccetto ciò che è necessario per eseguire e consentirà l'indirizzo IP della tua app Web sulla porta 22. A seconda della scala e della complessità, potresti comunicarlo solo con il servizio di bilanciamento del carico che lo distribuirà su altri web istanze di app, ma è fuori ambito qui.

4. Assicurati che la tua chiave SSH richieda una passphrase. Uno molto strong.

5. Assicurati che il database non disponga di capacità di I / O di file, se non è necessario.

6. Assicurarsi che il server di database non possa, per impostazione predefinita, creare alcuna connessione in uscita tranne che sulle porte richieste. Questo assicura che se qualcuno sfrutta il tuo database attraverso una sorta di iniezione o exploit (Attacker - > Web App - > SSH Richiesta inoltra - > DB Exploit), non consente all'hacker di restituire (facilmente) una shell inversa al loro sistema (abbiamo coperto SQLi in # 1, ma ancora - ecco un altro strato fastidioso).

7. Assicurarsi che né il server di app Web né il database siano eseguiti come root.

8. Assicurati che le autorizzazioni per il tuo pivot SSH siano così basse come possono essere per gestirlo. Ad esempio, puoi configurare gli utenti nella configurazione del database.

9. Se possibile, assicurati che il server di database sia sul proprio VPC / VLAN.

10. Infine, se davvero hai bisogno di seguire questa strada, non ci dovrebbero essere motivi per collegarti come root. Dovresti connetterti come utente standard e digitare una password complessa. Una VPN sarebbe un'idea migliore.

Questa non è una lista completa, solo qualcosa di veloce per iniziare.

TLDR: principio del privilegio minimo.

Primo problema lampante: ssh root @

Non farlo. Non eseguire ssh come root . Mai. SSH come root è una cattiva pratica, è peggio di sudo su - . Se la tua password o chiave è compromessa in qualche modo, l'intero server DB è sparito. Separazione dei privilegi, autorizzazioni severe, crittografia completa del disco ... tutto inutile.

Se qualcuno ottiene una shell sul server delle applicazioni, può connettersi al servizio di database (servizio, non server) senza bisogno delle chiavi SSH. Perché? È un tunnel TCP! Possono connettersi direttamente al database utilizzando la porta locale. Non hanno nemmeno bisogno di scoprire che stai facendo un tunnel, basta guardare le porte aperte con netstat . O guardando i tuoi file di configurazione. E cos'altro ci sarà nei file di configurazione? Le credenziali del database.

Se le chiavi SSH non sono protette da password, possono accedere all'intero server come root. Avevano già le credenziali del database, ora anche loro hanno accesso root.

Vorrei utilizzare Wireguard o un altro servizio VPN per le richieste di tunnel e configurare il firewall sul server di database per consentire solo le connessioni dalla VPN alla porta del database.

E cambierei la porta predefinita SSH 22 in qualcos'altro, e mettere un honeypot sulla porta 22, qualcosa come SSH-Pot : Un server ssh che non si autentica mai . Questo fa sì che i robot di scansione casuale non si accorgano del tuo server.

E come diceva Mark, indurimento e privilegio minimo. Disabilitare il più possibile. Se non hai bisogno di e-mail, disabilita l'email. Disabilita tutti i servizi che puoi, finché il servizio non smette di funzionare. Configurare il firewall sul server di database per non consentire alcuna connessione in entrata, ad eccezione del servizio VPN stesso e della porta DB all'interno della VPN e non consentire le connessioni in uscita. Fare lo stesso sul server delle applicazioni: consentire le porte 22, 80, 443 e la nuova porta ssh (l'hai modificata, vero?) E non consentire le connessioni in uscita ad eccezione del servizio VPN sul server DB e del servizio DB .