Esporre porte o nasconderle dietro proxy

Questo dipende principalmente da come stai facendo il proxy. Se stai semplicemente utilizzando mod_rewrite in Apache o Nginx per reindirizzare da 80 a 8090 ... non c'è alcuna sicurezza ottenuta. Questo è l'equivalente di mettere una nota appiccicosa sulla porta di casa tua dicendo "per favore usa la porta nella parte posteriore". Chiunque può leggere l'appiccicoso, e anche se non c'è qualcuno che lo appiccica, potrebbe aprire la casa e trovare la porta sul retro per essere aperta (alias port scan your host).

Se hai bisogno di un servizio web accessibile solo da alcune persone, uno dei modi migliori per farlo è di ospitare il servizio su localhost o 127.0.0.1 ... questo significa che la porta non essere accessibile fuori dagli schemi. Quindi, per arrivare al servizio, porta ssh forward:

ssh -L 80:127.0.0.1:8090 example.com -i ~/.ssh/id_rsa

Quanto sopra è come ottenere il port forwarding ssh in Linux, tuttavia è anche disponibile tramite strumenti come puTTY .

L'uso di un tunnel ssh per accedere al tuo servizio aumenta il livello di sicurezza di:

• crittografia della comunicazione tra client e server
• protezione del servizio dietro l'autenticazione pubkey (o password) utilizzata da ssh
• nessuna porta esterna da scansionare

Se non vuoi configurare il tunnel SSH un'altra opzione è bussare alla porta .

Un modello abbastanza comune è quello di avere un proxy heavy-duty come apache o nginx che fa tutto il pesante sollevamento http e si occupa della terminazione di https (ad esempio gestisce SSL per te). La tua applicazione è nascosta dietro quella.

Tale impostazione ha alcuni vantaggi:

1. Rende il tuo server delle applicazioni molto più semplice, perché non devi preoccuparti della memorizzazione nella cache, della crittografia SSL e di molti dettagli che Apache e Nginx sono in grado di gestire. Si noti che se il server delle applicazioni esegue lo stesso SSL, un proxy che si trova di fronte ad esso non sarà in grado di memorizzare nella cache nulla, quindi dal punto di vista delle prestazioni, ha senso non lasciare che il server delle applicazioni si occupi di SSL.
2. Lasciare che apache / nginx gestiscano le richieste del client prima dirigerà prima qualsiasi attacco su apache / nginx, e sono ben collaudati e temprati contro gli attacchi, il che probabilmente non è vero per il server delle applicazioni.
3. Apache e nginx sono probabilmente più performanti del tuo server delle applicazioni. In questo modo è possibile fare in modo che vengano pubblicati contenuti statici e allo stesso tempo farli fronteggiare tutte le implicazioni di sicurezza che consentono ad un server di accedere al file system del server. Le probabilità sono che bloccare apache e nginx sia più facile che assicurarsi che il server delle applicazioni non abbia buchi di sicurezza nel codice per servire file statici (questo è un esempio specifico del punto 2).

Tuttavia, ottieni questi benefici di sicurezza solo se non rendi accessibile al pubblico il tuo application server. Quindi devi farlo solo per ascoltare su localhost, o avere il tuo firewall per chiudere le porte rilevanti.

Questo significa anche che l'uso di reindirizzamenti HTTP per avere reindirizzamenti apache / nginx alla porta del server delle applicazioni non funzionerà più (e in effetti non dovrebbe, perché l'uso dei reindirizzamenti HTTP non aiuterà a nascondere il server delle applicazioni da l'internet pubblico a tutti). Invece, dovrai configurare apache / nginx per fungere da proxy usando le loro direttive proxy.