1

We are looking at an app that requires a local DNS entry for my.site.com with IP address 127.0.0.1. Our proxy is blocking this URL whenever the app attempts to use it. The app support says it's (my.site.com) is all internal communication but still needs to be whitelisted on proxy and firewall.

So the questions are: 1. What are the security implications of allowing 127.0.0.1 access to the internet? 2. Any idea why an app would be dependent on this type of configuration (I am not a developer)?

Thanks for the help!

closed as off-topic by CaffeineAddiction, forest, kasperd, Rory Alsop Dec 9 '18 at 21:14

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "This question does not appear to be about Information security within the scope defined in the help center." – Rory Alsop
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    What are the security implications of allowing 127.0.0.1 access to the internet? None. 127.0.0.1 is a special purpose IP address referring to the host itself (i.e. localhost or loopback). It shouldn't be routed outside the host and certainly won't get routed on the Internet. – YLearn Dec 7 '18 at 6:12
  • 1
    This question isnt security related, rather it is a misunderstanding of how networking works. I propose this question be moved to a more appropriate SE. – CaffeineAddiction Dec 7 '18 at 6:19
  • YLean Thanks I am aware of 127.0.0.1 purpose and it's not routable. The issue is the app support say 127.0.0.1 or my.site.com needs to be whitelisted on all internet facing security appliances. They can not give me a logical explanation why a non-routable IP address needs to be whitelist on internet facing appliances. It would appear to me to be a security hole by whitelisteing 127.0.0.1 on a security appliance. Possibly allowing a reverse shell to be created? – bcarney Dec 7 '18 at 6:35
  • @bcarney, if you understand the purpose and that it is not routable, then you should understand it isn't routable so it won't go go anywhere. There is no security risk to a destination that can never be reachable from anywhere. Traffic that is sent to 127.0.0.1 may be processed by an application/service on the localhost, that application/service may send the traffic elsewhere, but it won't be to 127.0.0.1 if it wants to get to the Internet. – YLearn Dec 7 '18 at 7:02
  • YLearn understood. But why would any app be dependant on 127.0.0.1 being allowed on an internet facing appliance? If 127.0.0.1 is blocked at the egress to the internet the app is broken. Not blocked works fine. That is what is baffling me. – bcarney Dec 7 '18 at 7:18
1

TL;DR: It looks like the app is designed without taking into account that there are things like explicit proxies where the DNS resolution is done on the proxy. The "solution" suggested by the app support will not work. They need instead rethink the design of their app.

Given the description it looks like that the app is using a public domain name and that the DNS for this domain returns an IP local to the host - for example a lookup to localhost.example.com returns 127.0.0.1. This kind of setups is typically used to allow a public SSL certificate for a server at the local machine (bad idea since often all clients share the same private key for the certificate this way) or that some application on the internet can share cookies with the local application (i.e. www.example.com on the internet and localhost.example.com share the same cookie domain example.com).

The problem with this approach is that it does not work with setups where the hostname is not resolved at the local host but at some proxy (typically HTTP proxy or SOCKS5 proxy). In this case 127.0.0.1 does not mean the local machine where the browser runs and the local server runs and where the request is originating. Instead 127.0.0.1 is the proxy machine where the hostname is resolved to an IP address and then the traffic is forwarded to this IP.

The "solution" suggested by the app support was to allow access to the domain on the proxy. This will not help since it does not solve the problem that 127.0.0.1 from the perspective of the proxy is not the clients system but the proxy system itself. This means it will typically simply not work to access the expected local server. But in the worst case it can also introduce a security issue since often a local administrative interface is running on the proxy which might allow unauthorized access from localhost since the local system is considered trusted.

This kind of broken setup is for example done by Spotify to make access to a local web server possible from the internet, i.e. whatever.spotilocal.com returns 127.0.0.1 - see also What is the advantage of having a domain name (spotilocal) that resolves to 127.0.0.1?. And sure enough, they are running into problems with proxies - spotify blocked by squid.

  • THANK You! This is the direction I was aiming for. If you have additional thoughts please provide when you have time. You have confirmed what I am seeing to a T. The proxy resolves the URL and see it's pointed at 127.0.0.1 and fails. I am not a programmer and all there support people are programmers with what appears to be little understanding of security best practices or IP. First question is Do you have a firewall or proxy? Have my.site.com or 127.0.0.1 been whitelisted on them? EVERY single time. I am calling out the 500LB gorilla and want to make sure I am not missing something. – bcarney Dec 7 '18 at 7:11
  • @bcarney: The security issue actually only comes second. As I said: from the perspective of the proxy 127.0.0.1 is the proxy itself and not the clients system where the local server is running. Thus, connecting to 127.0.0.1 on the proxy will simply not reach the expected server on the clients system but will try to reach a server on the proxy. Whitelisting on the proxy will therefore not help. The only way would be to whitelist in the local browser so that requests to this domain are not forwarded to the proxy at all. And even this will not work with restrictive DNS servers. – Steffen Ullrich Dec 7 '18 at 7:17
  • Dang! You solved the Spotify issue I've been setting on months since it's low to no priority. – bcarney Dec 7 '18 at 7:29
0

Simply set up your application and the runtime environment correctly and ensure that traffic for both localhost, 127.0.0.1 and the URL the application uses to refer back to itself does not get sent to your proxy server in the first place and all your problems will solved without white listing and firewall changes...

Depending on your OS look for a proxy exclude list, set a no_proxy environment variable or similar

  • Thanks for the input. The vendor set up the app and says it is correctly configured including the DNS entries. Yet the app constantly tries to use the URL my.site.com which is being blocked by the proxy and firewall. Support says either 127.0.0.1 or my.site.com needs to be whitelisted on all internet facing security appliances. – bcarney Dec 7 '18 at 6:29
0

Imagine you are passing notes in grade school. You send the following message:

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

You pass this message to the person next to you, and they pass it on ... and the message eventually gets to Jeff. Jeff is now very confused, because he is pretty sure he just sent himself a message about fighting himself by the flag pole after school ... but doesn't remember sending it ... and if he attempts to reply he will get even more confused and eventually just drop the note on the floor and forget it ever happens.

To a computer 127.0.0.1 is essentially Me specifically used for computer talking to itself (eg. inter process communication). While this may not seem useful at first pass ... it is actually used quite a bit for port forwarding in SSH as well as testing server applications during development.

  • I understand 127.0.0.1 is the local machine. The issue I am trying to understand is why is it hitting the proxy and firewall when the app is used. Why does app support say it has to be whitelisted in internet facing security appliances. When the 127.0.0.1 is blocked the app breaks. We've tested it. Bypass security works fine. – bcarney Dec 7 '18 at 6:43
  • It is possible to run a proxy server on your local machine, in which case you would set your browser to use 127.0.0.1 on some random port specified by the proxy server. It is also possible for your local computer's firewall to block 127.0.0.1 to prevent inter-process communication. – CaffeineAddiction Dec 7 '18 at 6:47
  • CaffeineAddition Thanks I realize they need 127.0.0.1 for inter-process communication for the app and may apps use this. I was looking for more techical information on why allowing 127.0.0.1 on internet facing security makes no sense\bad idea. Support stands behind it's got to be whitelisted. I want to make sure I am not missing something. In 30 years I've never run into a app\situation like this. – bcarney Dec 7 '18 at 7:25
  • 127.0.0.1 can't be internet facing – CaffeineAddiction Dec 7 '18 at 7:27
  • You hit the nail on the head. Why would an application support person tell customers it has to be whitelisted on internet facing appliances. – bcarney Dec 7 '18 at 7:31
0

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

None. For decades 127.0.0.0/8 has been defined as only usable within the host. It is not a valid IP address for any use in any place on any network.

RFC 5735 says this about the range:

   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.

The reference from RFC 1122 is even more explicit:

        (g)  { 127, <any> }

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

RFC 1122 is now over 29 years old. Every correct implementation of IP in any router or Internet facing appliance is going to follow this behavior.

The only way packets addressed to this IP could move around in a network is if the implementation of the IP protocol was severely broken in the first place.

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

There is no valid consideration for this configuration. None. Zero. Zilch. Nor should you consider making configuration changes to allow such traffic.

If the application developer is telling you to do this, then either (a) they don't know what they are talking about or (b) they are trying to do something so severely broken that they have proven (a).

The only use for sending traffic to 127.0.0.1 is if the traffic is being sent to an application or service running on the host itself (i.e. like a locally hosted proxy server, tunnels of any variety, etc ). That application or service may process the traffic and try to send it to some other destination, but if it is trying to send traffic for another host to 127.0.0.1 then it is broken. Period.

Not the answer you're looking for? Browse other questions tagged or ask your own question.