Come potrei tunnelare tutte le azioni che faccio nel mio VPS dal mio browser (come le azioni PHPmyadmin)?

Naviga le tue risposte
1

Non sono del settore della sicurezza delle informazioni così dispiaciuto se qualcosa che ho scritto qui sotto ti sembra patetico.

Devo difendere il DB del mio server e per questo ho filtrato la porta 3306 con CSF-LFD e ora controllo il mio DB solo internamente tramite la porta 80, principalmente tramite PHPmyadmin (PMA) per 2 ore ogni volta (ho fatto installare PMA) e cancellato automaticamente dopo 2 ore da uno script).

Queste 2 azioni (bloccando la porta e utilizzando PMA temporanei) sono considerate abbastanza sicure, ma c'è un'ultima cosa che voglio fare per garantire una protezione extra:

Mi è stato detto che potrei rendere cifrata ogni transizione di dati basata su port-80 tra il mio PC e il mio VPS.

Ho pensato di farlo con un tunnel tramite OpenSSH quindi inizialmente ho provato un comando simile al seguente, con il mio utente, ip e chiave privata. L'esecuzione mi ha portato nel mio VPS e ho potuto gestirlo bene, ma non c'era alcuna crittografia per le azioni che ho fatto dal mio browser web: 

ssh [email protected] -L 22:localhost:22 -L 80:localhost:80 -i ~/.ssh/user_private_key

Poiché il comando apparentemente non ha risposto al mio bisogno, mi sono rivolto alla società di hosting e un consulente dell'assistenza mi ha detto che è ovvio perché utilizzo già OpenSSH per accedere al mio VPS stesso e qualsiasi altra crittografia che faccio con esso è sempre solo una sessione (CLI) basato piuttosto che basato su GUI quindi non influenzerà la transizione dei dati eseguita dal browser (devo dire che mi sembra illogico - Se scavalchiamo un percorso tra una porta e l'altra, come 80-80, quindi tutto ciò che lo attraversa se da CLI o GUI deve essere crittografato).

Ho imparato che potrei usare il proxy SOCKS. SOCKS è davvero l'unico modo per me di raggiungere questa crittografia. Non posso davvero usare OpenSSH?

Grazie,

Aggiornamento per Xiong Chaimov:

Xiong mi ha chiesto nei commenti qui sotto:

What lead you to the conclusion that actions you took were not encrypted?

Due cose mi hanno portato a credere che non ci fosse tunnel tra i due lati della porta 80:

0,1. Comando errore (come è): 

bind: Address already in use
channel_setup_fwd_listener: cannot listen to port: 22
bind: Address already in use

0,2. Netstat I / O: 

netstat -n --protocol inet | grep ':22':

tcp        0     2.2.2.2:22         1.1.1.1:49214     ESTABLISHED

- 

netstat -n --protocol inet | grep ':80'

No output...
    
posta JohnDoea 28.12.2016 - 04:13
fonte

4 risposte

2

Poiché si tratta di port forwarding SSH, dovrebbe essere crittografato. Esiste anche una soluzione in cui non si utilizza il server Web sottostante o phpmyadmin, per inoltrare semplicemente la porta mysql, ad esempio -L 3306:localhost:3306 e connettersi al database utilizzando un client come MySQL workbench (o la maggior parte degli IDE hanno comunque integrato simile) .

    
risposta data 28.12.2016 - 10:32
fonte
1

Per una corretta crittografia puoi anche usare HTTPS (è anche più corretto), ma per una soluzione come la tua, devi eseguire il tunneling di una porta localhost sul tuo server OpenSSH e connetterti tramite le impostazioni proxy SOCKS come descritto in questo articolo DigitalOcean .

    
risposta data 28.12.2016 - 06:24
fonte
0

In generale, è necessario configurare il server del database per ascoltare la connessione al database su un socket di dominio Unix o per ascoltare solo su localhost. MySQL non deve essere configurato per l'ascolto su un indirizzo IP esterno o, peggio, per l'ascolto su tutti gli indirizzi, a meno che l'utente regolare del database (di solito un'applicazione Web) non sia in esecuzione sulla stessa macchina. E se l'applicazione è remota, ci sono un certo numero di cose che devi considerare.

Il modo in cui lo fai è impostare la configurazione dell'indirizzo di bind sull'indirizzo di loopback (127.0.0.1). Se lo fai, nessuno può connettersi a MySQL da remoto, a meno che non abbiano già una connessione al server (ad esempio SSH) e crei una connessione "locale" da lì. In questo caso, ti affidi a SSH per eseguire la crittografia e l'autenticazione e il sistema operativo non instradare i pacchetti remoti che arrivano all'indirizzo di loopback all'applicazione. Inoltre, è possibile configurare MySQL in modo che richieda password / autenticazione, per impedire agli utenti locali e non privilegiati di connettersi al database. Si noti che non è possibile limitare gli utenti privilegiati (root e qualcuno con accesso fisico non limitato). Inoltre, è possibile configurare un firewall host (ad esempio iptable in Linux) per limitare ulteriormente le porte aperte sul sistema.

È possibile eseguire l'amministrazione remota utilizzando l'inoltro locale SSH. Configurerai Workbench per la connessione alla porta locale della tua macchina locale e SSH inoltrerà tale connessione alla porta MySQL sul server.

Un altro modo per eseguire l'amministrazione remota è configurare PHPMyAdmin per l'ascolto su una porta HTTPS pubblica. In questa configurazione, ti affidi a PHPMyAdmin per eseguire l'autenticazione e HTTPS per la crittografia. Si noti che l'utilizzo di PHPMyAdmin tramite HTTP non crittografato non è sicuro, è necessario utilizzare HTTPS, anche PHPMyAdmin, sebbene conveniente, esponga una superficie di attacco di grandi dimensioni in quanto è un'applicazione PHP complessa. Ad esempio, potrebbe essere vulnerabile a CSRF o XSS.

Puoi proteggere ulteriormente PHPMyAdmin configurando il tuo webserver (ad esempio Apache) per richiedere un "certificato client TLS" per accedere all'applicazione PHPMyAdmin. In questa configurazione, ti baserai su Apache per l'autenticazione e HTTPS per la crittografia. Dovresti usarlo in combinazione con il meccanismo di autenticazione di PHPMyAdmin.

Se l'applicazione non è in esecuzione sulla stessa macchina del database (comune nei database con un numero elevato di utenti o condivisa da più applicazioni), è possibile consentire a MySQL di collegarsi all'indirizzo IP di una rete privilegiata. In questo modello di sicurezza, chiunque sia connesso alla rete privilegiata e sia autorizzato dall'amministratore di rete a inviare pacchetti IP al server di database è considerato affidabile. In questo caso, dipenderete dall'amministratore di rete del server. A meno che tu non abbia esperienza con il networking e si fidi di chiunque abbia configurato l'amministratore di rete e la configurazione del firewall, non lo consiglierei. L'amministrazione remota, in questo caso, verrebbe eseguita collegandosi alla rete privilegiata tramite una VPN. È necessario un firewall di rete che impedisca che le connessioni esterne alla rete privilegiata vengano indirizzate al server di database. In questa configurazione, l'autenticazione viene eseguita dal server VPN e dai router che impongono la tabella di routing LAN.

Inoltre, puoi configurare MySQL per richiedere un client TLS certificato . Con questa configurazione, anche il server MySQL esegue l'autenticazione. Questo può essere usato se non ti fidi completamente dell'amministratore di rete o se non ti fidi di tutti gli utenti della rete che possono connettersi al computer del database.

Infine, puoi esporre MySQL per associare a un indirizzo IP pubblico. Non lo consiglio, poiché MySQL non è un'applicazione progettata per essere esposta su una porta pubblica (anche se MySQL può richiedere il certificato client TLS). Apache, sshd e gateway VPN, d'altra parte, sono progettati in modo che possano essere configurati per essere esposti in un indirizzo pubblico in modo sicuro.

Se non sai di averne bisogno, ti consiglio di non configurare MySQL per l'ascolto su un indirizzo non di loopback. E non vi è alcun motivo valido per esporre deliberatamente un server di database su un indirizzo IP pubblico per un certo periodo di tempo. Questo può essere considerato solo errata configurazione o incompetenza.

Non dovresti aver bisogno di SOCKS (OpenSSH Dynamic forwarding). SOCKS è utile solo se si dispone di un numero elevato di computer di destinazione e non si desidera configurare quale porta locale va dove. In questo caso, hai una macchina target specifica, che è il tuo server database sulla porta del database, quindi devi solo inoltrarla.

    
risposta data 28.12.2016 - 15:49
fonte
0

Non hai bisogno di calze, anzi è un'ulteriore complicazione che non vuoi davvero ora. Il port forwarding su ssh fornisce la crittografia indipendentemente dal client.

Il comando che stai usando con ssh non ha alcun senso. Con questo modello di tunneling si dice a ssh di ascoltare su una porta locale e di inoltrare la connessione a un sistema remoto. SSH non può ascoltare onaport che è già in uso. È necessario dedicare molto più tempo a imparare le basi e meno tempo su schemi bizantini come le installazioni temporanee di pma.

Il folowing (eseguito dal tuo PC) renderà disponibili i dbms su 127.0.0.1 su pirt 3307 (nota che i client mysql di solito assumono che le connessioni a 'localhost' dovrebbero usare un socket per filesystem) 

ssh -L 3307:localhost:3306 $yourvps

Tuttavia, dare al sistema remoto un indirizzo IP a cui connettersi (e definire le regole di rete in giro) è molto più flessibile: personalmente mi piacerebbe andare su una VPN ssh come questo

    
risposta data 28.12.2016 - 15:21
fonte

Leggi altre domande sui tag

Quali sono i rischi nel mettere i dettagli del conto bancario su un sito web? La coppia di chiavi SSH funziona in Putty ma non in OpenSSH all'interno della sessione Putty [closed]