Porte bloccate

Quale porta viene bloccata?

Una porta di rete è un numero utilizzato per distinguere i servizi presso un indirizzo di rete. Lo stesso server può accettare connessioni web su una porta e connessioni a un’altra applicazione su una porta diversa. Un’applicazione necessita dell’indirizzo del server, della porta corretta e del trasporto utilizzato: TCP o UDP.

Una connessione proxy ha due destinazioni separate. Prima la tua applicazione si collega al proxy all’indirizzo e alla porta forniti dal fornitore. Poi chiede al proxy di raggiungere il server di destinazione al relativo indirizzo e porta. La porta nelle impostazioni proxy appartiene al primo passaggio; una restrizione sulla porta di destinazione si applica al secondo.

Per esempio, un programma può collegarsi a proxy.example:1080 e richiedere portal.example:443. Lo stesso punto di ingresso del proxy può ricevere anche una richiesta per mail.example:587. Se il fornitore consente la prima porta di destinazione e blocca la seconda, la connessione web può riuscire mentre quella di posta viene rifiutata.

Queste restrizioni riguardano le connessioni in uscita dal proxy verso servizi esterni. Consentire una connessione di questo tipo non fornisce a un’applicazione sul tuo computer una porta in ingresso raggiungibile dagli altri utenti Internet. L’inoltro di porte in ingresso è una funzione separata.

Perché i fornitori limitano le porte

Il motivo più evidente è prevenire l’abuso di un determinato servizio. L’accesso diretto ai server di posta può essere utilizzato per campagne di spam. Le segnalazioni e gli elenchi di blocco dei mittenti interessano gli indirizzi IP che trasportano il traffico, quindi le conseguenze possono estendersi oltre il cliente che ha inviato i messaggi. Un fornitore può ridurre questo rischio rifiutando le connessioni alle porte utilizzate per inviare email prima che venga trasmesso qualsiasi messaggio.

Considerazioni simili possono applicarsi ai servizi di amministrazione remota, condivisione di file o database. Un fornitore può limitare l’accesso alle porte associate a quei servizi per ridurre tentativi di accesso non autorizzato e altri attacchi. La restrizione si applica alla connessione stessa: anche un amministratore legittimo potrebbe non riuscire a raggiungere il proprio server attraverso quel prodotto.

La regola non proviene sempre dal venditore di proxy. Una società di hosting o un operatore di rete può filtrare le connessioni in uscita dall’infrastruttura utilizzata dal proxy. Un permesso nel software del proxy non può superare una restrizione imposta più avanti lungo il percorso.

Un filtro sulle porte è una misura ampia. Può fermare traffico indesiderato senza esaminare ogni messaggio o decidere se ogni singola operazione sia legittima, ma limita anche applicazioni utili che necessitano della stessa porta. Questo compromesso spiega perché un fornitore può mantenere una porta chiusa anche per un cliente pagante con un’attività ragionevole.

Come funzionano le regole di accesso alle porte

Esistono due approcci di base. Un elenco di blocco indica le porte che i clienti non possono usare; le altre connessioni vengono valutate secondo le regole rimanenti del servizio. Un elenco di porte consentite funziona nel senso opposto: il fornitore permette un insieme specificato di porte e rifiuta tutte le altre. Nel secondo modello, una normale applicazione web su una porta non standard può essere indisponibile semplicemente perché la sua porta non rientra nell’insieme consentito.

Una regola può coprire una porta su ogni indirizzo esterno oppure combinare la porta con una destinazione specifica. I fornitori possono inoltre applicare regole diverse a prodotti o utilizzi approvati diversi. L’accesso attraverso una rete non dimostra quindi i permessi di un altro prodotto venduto dalla stessa azienda.

Il proxy non deve decifrare il traffico dell’applicazione per applicare una regola sulla porta di destinazione. In una richiesta HTTP CONNECT, il client fornisce host e porta di destinazione. Anche SOCKS5 trasporta la destinazione richiesta nella propria richiesta di connessione. Il proxy può rifiutarla prima che inizi una sessione protetta con il server di destinazione.

Il traffico TCP e UDP che utilizza lo stesso numero di porta può essere consentito o bloccato separatamente. Una connessione riuscita alla porta TCP 443 non dimostra che sia disponibile la porta UDP 443. Esiste anche un’altra possibilità: il prodotto proxy selezionato potrebbe non trasportare affatto UDP. In quel caso il limite riguarda il trasporto, non una determinata porta UDP.

Un numero di porta da solo non dimostra neppure che cosa stia facendo un’applicazione. I servizi possono funzionare su porte non standard e un numero consentito non rende accettabile qualsiasi utilizzo. I fornitori possono combinare i filtri sulle porte con restrizioni sulle destinazioni e regole che disciplinano l’attività stessa.

Che cosa cambia per le applicazioni

Le applicazioni utilizzano connessioni per funzioni specifiche. Una prova nel browser verifica la connessione web effettuata; non esercita ogni connessione che potrebbe servire a un altro programma. Gli esempi seguenti mostrano come una restrizione di porta può influire su un servizio altrimenti funzionante.

La posta elettronica illustra particolarmente bene la distinzione. Un’applicazione di posta invia i messaggi in uscita a un server di posta, comunemente sulla porta 587 o 465. La porta 465 inizia con la cifratura TLS; la porta 587 utilizza comunemente STARTTLS per stabilire la cifratura. Una restrizione di porta può impedire entrambe le connessioni prima dell’invio del messaggio. La cifratura protegge lo scambio, ma non elimina la regola di accesso del fornitore.

In un’interfaccia webmail, il browser comunica con un sito tramite HTTPS e il servizio di posta gestisce la consegna. Il browser non chiede al proxy di stabilire quella stessa connessione SMTP. Una casella di posta web può quindi rimanere utilizzabile mentre l’accesso SMTP è bloccato. Ricevere posta in un’applicazione separata è un’altra connessione ancora: l’accesso IMAP o POP va considerato separatamente dall’invio.

FTP mostra perché verificare soltanto l’accesso può non rilevare un problema. In modalità passiva il client invia prima comandi tramite una connessione, poi si collega a una porta specificata dal server per trasferire i dati. Se la seconda connessione è limitata, l’autenticazione può funzionare mentre l’elenco dei file o il download fallisce. Le applicazioni con connessioni separate per accesso, voce o scambio di file possono presentare errori parziali simili.

Perché modificare le impostazioni proxy può non aiutare

Cambiare la porta di ingresso nelle impostazioni proxy modifica il punto in cui l’applicazione contatta il proxy. Non cambia la porta di destinazione richiesta per il servizio esterno. Se il fornitore offre un punto di ingresso sulla porta 443, collegarsi lì lascia comunque la richiesta per la porta 587 del server di posta soggetta alla restrizione sulle porte di posta.

Passare da un proxy HTTP a SOCKS5 può risolvere un problema di compatibilità quando l’applicazione necessita di una funzione supportata dal nuovo metodo di connessione. Non annulla di per sé le regole del fornitore. SOCKS5 definisce come richiedere connessioni TCP e inoltro UDP; il servizio decide quali di queste richieste accettare.

Sostituire un IP di uscita lascia inoltre in vigore una restrizione applicata all’intero prodotto. Un percorso diverso può comportarsi diversamente quando l’errore è causato da una specifica rete esterna, ma la rotazione non elimina una regola che si applica a tutto il prodotto. Neppure più IP o una quota di traffico maggiore cambiano quel permesso.

Come identificare una restrizione di porta

La prova più utile è una risposta esplicita del fornitore che indica che la porta di destinazione richiesta non è consentita. Un messaggio generico di accesso negato è meno preciso. Per esempio, la risposta SOCKS5 a una richiesta rifiutata dall’insieme di regole identifica un rifiuto dovuto alle regole, ma non indica quale lo abbia causato. Un timeout o un reset della connessione, da soli, sono prove ancora più deboli.

Il server di destinazione potrebbe non avere alcun servizio in ascolto su quella porta, accettare soltanto determinati indirizzi di origine oppure essere temporaneamente indisponibile. L’applicazione potrebbe inoltre utilizzare il protocollo sbagliato o inviare parte del traffico al di fuori del proxy configurato. Verificare una richiesta web riuscita non permette di distinguere queste cause da una restrizione che interessa un’altra connessione.

Per una richiesta di assistenza utile, fornisci il prodotto proxy, il nome host o l’IP di destinazione, la relativa porta, TCP o UDP, l’applicazione e l’errore esatto con l’orario del tentativo. Questi dettagli consentono all’assistenza di verificare la connessione pertinente anziché limitarsi a confermare che il proxy è online. Per un acquisto previsto, le stesse informazioni aiutano a stabilire se il prodotto supporta l’attività.

Quando il fornitore consente eccezioni, l’approvazione dovrebbe identificare la destinazione e l’utilizzo richiesti. Alcune restrizioni rimangono permanenti oppure provengono da un’infrastruttura che il fornitore non controlla. La domanda utile è se la connessione specifica possa essere supportata secondo le regole del servizio; una richiesta di «aprire tutte le porte» lascia poco chiari sia il requisito sia i limiti.