127.0.0.1 accesso a Internet [chiuso]

TL; DR: Sembra che l'app sia progettata senza tenere conto del fatto che ci sono cose come i proxy espliciti in cui la risoluzione DNS viene eseguita sul proxy. La "soluzione" suggerita dal supporto dell'app non funzionerà. Hanno bisogno invece di ripensare il design della loro app.

Data la descrizione, sembra che l'app stia utilizzando un nome di dominio pubblico e che il DNS per questo dominio restituisca un IP locale all'host, ad esempio una ricerca su localhost.example.com restituisce 127.0.0.1 . Questo tipo di impostazioni viene in genere utilizzato per consentire un certificato SSL pubblico per un server sul computer locale (idea errata poiché spesso tutti i client condividono la stessa chiave privata per il certificato in questo modo) o che alcune applicazioni su Internet possono condividere cookie con il applicazione locale (cioè www.example.com su Internet e localhost.example.com condividono lo stesso dominio cookie example.com ).

Il problema con questo approccio è che non funziona con le configurazioni in cui il nome host non viene risolto nell'host locale ma con qualche proxy (in genere proxy HTTP o proxy SOCKS5). In questo caso 127.0.0.1 non indica la macchina locale in cui il browser viene eseguito e il server locale viene eseguito e dove la richiesta è originata. Invece 127.0.0.1 è la macchina proxy in cui il nome host viene risolto in un indirizzo IP e quindi il traffico viene inoltrato a questo IP.

La "soluzione" suggerita dal supporto dell'app era quella di consentire l'accesso al dominio sul proxy. Questo non aiuterà poiché non risolve il problema che 127.0.0.1 dal punto di vista del proxy non è il sistema dei client ma il sistema proxy stesso. Ciò significa che in genere non funzionerà per accedere al server locale previsto. Ma nel peggiore dei casi può anche introdurre un problema di sicurezza poiché spesso sul proxy è in esecuzione un'interfaccia amministrativa locale che potrebbe consentire l'accesso non autorizzato da localhost poiché il sistema locale è considerato affidabile.

Questo tipo di configurazione interrotta è ad esempio eseguita da Spotify per rendere possibile l'accesso a un server Web locale da Internet, ovvero whatever.spotilocal.com restituisce 127.0.0.1 - vedi anche Qual è il vantaggio di avere un nome di dominio (spotilocal) che risolve a 127.0.0.1? . E abbastanza sicuro, stanno incontrando problemi con i proxy - spotify bloccato da calamaro .

È sufficiente configurare correttamente l'applicazione e l'ambiente di runtime e assicurarsi che il traffico sia per localhost, 127.0.0.1 che per l'URL utilizzato dall'applicazione per riferirsi a se stesso non venga inviato al server proxy in primo luogo e tutto il i problemi si risolvono senza elenchi bianchi e modifiche al firewall ...

A seconda del tuo sistema operativo, cerca un elenco di esclusione proxy, imposta una variabile di ambiente no_proxy o simile

Immagina di passare appunti alla scuola elementare. Si invia il seguente messaggio:

From: Me
To: Jeff
Message: I want to fight you by the flag pole after school

Passi questo messaggio alla persona che ti sta accanto, e loro lo trasmettono ... e il messaggio arriva infine a Jeff. Jeff è ora molto confuso, perché è abbastanza sicuro che si sia appena inviato un messaggio su come combattere se stesso con il palo della bandiera dopo la scuola ... ma non ricorda di averlo mandato ... e se tenta di rispondere otterrà ancora di più confuso e alla fine basta rilasciare la nota sul pavimento e dimenticarlo accadrà mai.

Per un computer 127.0.0.1 è essenzialmente Me specificamente utilizzato per il computer che parla a se stesso (ad esempio comunicazione tra processi). Anche se questo potrebbe non sembrare utile al primo passaggio ... in realtà è usato un po 'per il port forwarding in SSH e per testare le applicazioni server durante lo sviluppo.

What are the security implications of allowing 127.0.0.1 access to the internet?

Nessuno. Per decenni 127.0.0.0/8 è stato definito come utilizzabile solo all'interno dell'host. Non è un indirizzo IP valido per qualsiasi utilizzo in qualsiasi luogo su qualsiasi rete.

RFC 5735 dice questo sulla gamma:

   127.0.0.0/8 - This block is assigned for use as the Internet host
   loopback address.  A datagram sent by a higher-level protocol to an
   address anywhere within this block loops back inside the host.  This
   is ordinarily implemented using only 127.0.0.1/32 for loopback.  As
   described in [RFC1122], Section 3.2.1.3, addresses within the entire
   127.0.0.0/8 block do not legitimately appear on any network anywhere.

Il riferimento da RFC 1122 è ancora più esplicito:

        (g)  { 127, <any> }

             Internal host loopback address.  Addresses of this form
             MUST NOT appear outside a host.

RFC 1122 ha ora più di 29 anni. Ogni corretta implementazione dell'IP in qualsiasi router o appliance che fronteggia Internet seguirà questo comportamento.

L'unico modo in cui i pacchetti indirizzati a questo IP possono spostarsi in una rete è se l'implementazione del protocollo IP è stata gravemente danneggiata in primo luogo.

Any idea why an app would be dependent on this type of configuration (I am not a developer)?

Non ci sono considerazioni valide per questa configurazione. Nessuna. Zero. Zilch. Né dovresti considerare di apportare modifiche alla configurazione per consentire tale traffico.

Se lo sviluppatore dell'applicazione ti sta dicendo di farlo, allora (a) non sanno di cosa stanno parlando o (b) stanno cercando di fare qualcosa di così gravemente rotto da provarlo (a).

L'unico utilizzo per l'invio del traffico a 127.0.0.1 è se il traffico viene inviato a un'applicazione oa un servizio in esecuzione sull'host stesso (ad esempio un server proxy ospitato localmente, tunnel di qualsiasi varietà, ecc.). Tale applicazione o servizio può elaborare il traffico e provare a inviarlo ad un'altra destinazione, ma se sta cercando di inviare il traffico per un altro host a 127.0.0.1, allora è rotto. Periodo.