È sicuro servire HTTP / HTTPS su porte 8080/8443


9

A causa di una limitazione dell'infrastruttura, una delle soluzioni proposte per servire un servizio HTTP nel mondo è offrirlo attraverso le porte 8080 e 8443.

La mia preoccupazione è che alcuni utenti potrebbero non essere in grado di accedere a questi servizi perché non sono in esecuzione su porte standard e il contenuto potrebbe essere filtrato (ad esempio) come parte della politica di rete aziendale.

Quindi ... quanto è probabile che un utente da Internet in generale non sia in grado di accedere a questi servizi?


non puoi delegare l'indirizzo alla porta 80 e 443?
Froggiz,

1
Stiamo usando ruoli Web e di lavoro nei servizi di Azure Cloud. Per quanto ne so, non è possibile puntare un secondo VIP su una macchina diversa a meno che non passiamo alle macchine virtuali di Azure. Altre opzioni includono la sostituzione dell'intero server Web front-end con un proxy, ma ovviamente l'utilizzo di porte diverse risolverebbe questo problema con minori spese.
spender il


2
Vorrei affrontare una preoccupazione che sembra mancare qui. Il fatto che non è possibile utilizzare le porte 80o 443potrebbe suggerire di essere in esecuzione su un server condiviso. In tal caso, esiste la possibilità che un altro utente potrebbe legarsi a queste porte se il vostro mai smesso di funzionare . Quell'utente potrebbe quindi impersonare il tuo sito Web (sebbene SSL possa aiutare a mitigarlo).
Nathan Osman,

@NathanOsman, penso che sia preoccupato per l'accesso degli utenti e dei firewall degli utenti.
Pacerier,

Risposte:


7

Le reti aziendali saranno generalmente impostate su regole come questa:

deny all; allow 80; allow 443; allow 21; allow 22; etc...

È molto più semplice configurarlo in questo modo piuttosto che negare esplicitamente il 99% delle 65.535 porte disponibili.

Detto questo, ho rilevato un portale lato client che utilizzava una porta non standard a causa delle limitazioni della rete; Non conosco i dettagli NAT. In ogni caso, ciò ha reso impossibile per circa il 50% dei nostri utenti / visitatori l'accesso al sito e ogni volta che ci chiamavano per segnalare questo problema, dovevamo coordinarci con il loro IT inesistente per cercare di ottenere una regola di autorizzazione.


Non conosco i dettagli dei limiti della tua infrastruttura ma immagino che qualcos'altro sia in esecuzione su 80/443

In tal caso, l'unica possibilità potrebbe essere quella di utilizzare un proxy interno o aggiornare il passaggio a qualcosa con funzionalità NAT più avanzate in grado di indirizzare le richieste in modo appropriato.


TL; DR

Non utilizzare una porta non standard per i servizi pubblici che dispongono già di una porta standard.


1
"È molto più semplice configurare in questo modo piuttosto che negare esplicitamente il 99% delle 65.535 porte disponibili." - anche se negassero esplicitamente il 99% delle porte avrebbe lo stesso effetto.
user253751

Abbiamo finito per utilizzare il server web principale per inviare le richieste ai servizi offerti su altre porte. Poiché gli altri servizi devono scalare per una potenza di elaborazione aggiuntiva piuttosto che perché raggiungono i limiti della rete e la dimensione delle richieste e delle risposte è relativamente bassa, questa disposizione funziona molto bene con il sito Web con bilanciamento del carico principale che assorbe facilmente il costo del proxy.
spender il

@spender Sono felice di sapere che siete stati in grado di risolverlo senza usare porte non standard rivolte al cliente :)
MonkeyZeus,

6

È molto probabile che vengano bloccati, specialmente nelle reti aziendali o sul wifi pubblico. Meno probabile su una normale connessione Internet domestica.

Sarebbe sicuramente bloccato sulla mia rete di lavoro.

Inoltre, le persone dovranno ricordare di digitare il numero di porta per raggiungere il tuo sito, che è un ulteriore mal di testa che non vuoi affrontare. Per i siti interni o privati ​​non è un grosso problema, ma se questo è per il grande pubblico avrai molto più successo usando le porte standard.


I servizi in questione non vengono mai digitati nel browser ... piuttosto vengono indicati dalle risorse servite sulle porte normali. Sembra, tuttavia, che le mie preoccupazioni sull'affidabilità del mio approccio siano ben giustificate.
spender il

puoi spiegare perché sarebbe bloccato? ho usato la porta 800 per molto tempo senza problemi anche con strumenti SEO di Google e referenziamento ..
Froggiz

1
Uno dei miei lavori è la gestione di un sito Web che indicizza i flussi di shoutcast ed è una lamentela comune che alcuni utenti dietro le reti aziendali non possono ascoltare i flussi in esecuzione su porte non standard. Tuttavia, 8080 e 8443 sembrano essere un po ' speciali, ma probabilmente non abbastanza speciali. Direi che l'esecuzione di un servizio su 800 è particolarmente rischiosa perché rientra in porte "ben note" che hanno molte più probabilità di essere bloccate.
spender il

Una soluzione semplice è quella di lasciare il server in esecuzione sulla porta 8080/8443 e sul firewall le porte NAT / forward da 80/443 a 8080/8443.
SnakeDoc,

1
@SnakeDoc D'accordo, ho coperto l'opzione proxy nella mia risposta :-)
MonkeyZeus

2

Non è difficile far sì che il tuo browser colpisca la parola http://example.com:8080/index.html , ma quando parli di politiche aziendali che bloccano le porte non standard sembra molto difficile.

Se si dispone di una sorta di bilanciamento del carico impostato, è comunque possibile configurare le applicazioni per l'esecuzione su una porta standard e avere la porta del bilanciamento del carico in avanti verso la porta dispari internamente. Anche se non si dispone del bilanciamento del carico, sono sicuro che è possibile trovare un modo per il port forwarding a una porta interna non standard.

Internamente, gli utenti possono accedere su una porta dispari (se non parte della politica aziendale da bloccare), esternamente vedono http://example.com .

Esistono molti modi per farlo, dovrai diventare un po 'creativo a seconda dei tipi di blocchi stradali che incontri. È sempre una sfida!

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.