6 ms·

I renewed the domain local.computer and set it and all subdomains to 127.0.0.1

9 points by skwashd 10y ago

greenyoda 10y ago
Every computer already defines the domain "localhost" for this purpose, which never expires and can't be hijacked. Why would someone want to use this risky alternative? Also, localhost will work if your machine is disconnected from the internet, while local.computer, which relies on a remote DNS server, will not.
- jonpugh 10y ago
  It's really just for convenience. I build a lot of drupal sites and often need to run a lot of them at once locally. Instead of putting each one on it's own port (hard to remember) or starting and stopping VMs or containers (tedious), I just use a subdomain like http://projectname.local.computer http://projectname.local.computer). I'm a contributor to Aegir, and created the aegir docker containers, which default to aegir.local.computer for easy testing. When I create sites in aegir, I don't have to set any DNS if I use a subdomain of aegir.local.computer, I can just visit node/add/site and fill in the form and get a site. Great for Aegir development. See https://hub.docker.com/r/aegir/hostmaster/ https://hub.docker.com/r/aegir/hostmaster/ I'm also creator of devshop, a more "cloud-y" version of aegir which gives each site a domain automatically, so local.computer is really great for developing devshop as well. http://ENVIRONMENT.PROJECT.devshop.local.computer http://ENVIRONMENT.PROJECT.devshop.local.computer I've also got a CLI tool for launching drupal sites locally in docker containers called Terra. It uses jwilder/nginx-proxy to route requests for domains to the right container, and makes dynamic domains like devshop. So *.local.computer is useful there too. https://github.com/terra-ops/terra-cli https://github.com/terra-ops/terra-cli https://github.com/opendevshop/devshop https://github.com/opendevshop/devshop
  - smt88 10y ago
    This is still a pointless security risk. Just use projectname.whatever (something that isn't on a public TLD).
    - jonpugh 10y ago
      I still can't quite put my finger on the security risk for others, can you help explain what makes it one? Here's the only scenario I can think of: Say you are a web developer and you use mybusiness.local.computer for developing your client's website. You use it every day, you are used to loading up the URL and seeing your website. One day I, owner of local.computer turn the dark side. I decide that I want to attack you, this one person who I know uses mybusiness.local.computer, and change mybusiness.local.computer to redirect to my nefarious server. When I do that, when you come to work, you load up mybusiness.local.computer and expect to see the site you've been working on. Because I know my victim, I know exactly what website to spoof, so I have my spoof up and running on my nefarious server. Then, when the victim goes to visit mybusiness.local.computer, thinking they are visiting a copy of their website, it's actually being served from my server. Hopefully, you then input some information, like their username and password, which I then capture in my spoof website. This is the only way I can imagine using this domain against someone. It involves quite a few assumptions: - The one in control of DNS is the attacker. - The attacker has one specific victim in mind, because they can only spoof one website. - The attacker already knows what site the victim is expecting to load at a .local.computer domain. This requires personal knowledge of the victim's site because the DNS for .local.computer goes straight to 127.0.0.1. Requests are not proxied or logged. (Ok, after writing this, I realize I could change the local.computer to go through my servers then redirect the user to 127.0.0.1 enabling me to at least learn what subdomains are being requested. Still, I have no idea what that site is supposed to be.) - The attacker is able to spoof that website well enough that the victim (a developer of the website) is able to be fooled into giving up information. Is there another way this could be abused? I seriously would like to know. Thanks!
      - smt88 10y ago
        As the owner of local.computer, you are in a position to intercept anything a developer is sending to her server via HTTP request. This could be username/password, yes. You also then know the public IP address and public domain of a development server, which may allow you to access the server and learn secrets, steal stack traces, etc. It's a small security risk, but it's a non-zero risk with zero benefit. Just use fake, never-to-be-public domains. There's no downside. If you need to interact with something like Twilio (which you never need to do while developing), you can wait until you're ready to push to staging.
  - greenyoda 10y ago
    This seems like a good reason for you to use that domain. But if someone else wants to do the same thing, it might be better for them to register their own domain that resolves to localhost rather than use yours - that way, they at least have control of how long their domain will be in existence and know that they control the IP address it resolves to.
- jerf 10y ago
  "Why would someone want to use this risky alternative?" Well, you can have some fun jamming this into various text fields that might block 127.0.0.1 and "localhost", but don't successfully block everything else that leads to local access, thus allowing you to use $SOME_NETWORK_SERVICE to probe its own internal services. It can also be fun to jam something like 127.3.22.99 into things that only block 127.0.0.1; the whole 127.0.0.0/8 is "localhost". Try it with ping sometime.
Mike_D_Brooks 10y ago
It's not a bad idea, but if you use Vagrant for virtual machines then you can always use the hosts updater plugin. It would be cool if Docker had this as well. Come to think of it, maybe someone needs to make a program which you can just type an ip and hostname in to and it will add it in for you...

9 points by skwashd 10y ago

Every computer already defines the domain "localhost" for this purpose, which never expires and can't be hijacked. Why would someone want to use this risky alternative? Also, localhost will work if your machine is disconnected from the internet, while local.computer, which relies on a remote DNS server, will not.

jonpugh 10y ago
It's really just for convenience. I build a lot of drupal sites and often need to run a lot of them at once locally. Instead of putting each one on it's own port (hard to remember) or starting and stopping VMs or containers (tedious), I just use a subdomain like http://projectname.local.computer http://projectname.local.computer). I'm a contributor to Aegir, and created the aegir docker containers, which default to aegir.local.computer for easy testing. When I create sites in aegir, I don't have to set any DNS if I use a subdomain of aegir.local.computer, I can just visit node/add/site and fill in the form and get a site. Great for Aegir development. See https://hub.docker.com/r/aegir/hostmaster/ https://hub.docker.com/r/aegir/hostmaster/ I'm also creator of devshop, a more "cloud-y" version of aegir which gives each site a domain automatically, so local.computer is really great for developing devshop as well. http://ENVIRONMENT.PROJECT.devshop.local.computer http://ENVIRONMENT.PROJECT.devshop.local.computer I've also got a CLI tool for launching drupal sites locally in docker containers called Terra. It uses jwilder/nginx-proxy to route requests for domains to the right container, and makes dynamic domains like devshop. So *.local.computer is useful there too. https://github.com/terra-ops/terra-cli https://github.com/terra-ops/terra-cli https://github.com/opendevshop/devshop https://github.com/opendevshop/devshop
- smt88 10y ago
  This is still a pointless security risk. Just use projectname.whatever (something that isn't on a public TLD).
  - jonpugh 10y ago
    I still can't quite put my finger on the security risk for others, can you help explain what makes it one? Here's the only scenario I can think of: Say you are a web developer and you use mybusiness.local.computer for developing your client's website. You use it every day, you are used to loading up the URL and seeing your website. One day I, owner of local.computer turn the dark side. I decide that I want to attack you, this one person who I know uses mybusiness.local.computer, and change mybusiness.local.computer to redirect to my nefarious server. When I do that, when you come to work, you load up mybusiness.local.computer and expect to see the site you've been working on. Because I know my victim, I know exactly what website to spoof, so I have my spoof up and running on my nefarious server. Then, when the victim goes to visit mybusiness.local.computer, thinking they are visiting a copy of their website, it's actually being served from my server. Hopefully, you then input some information, like their username and password, which I then capture in my spoof website. This is the only way I can imagine using this domain against someone. It involves quite a few assumptions: - The one in control of DNS is the attacker. - The attacker has one specific victim in mind, because they can only spoof one website. - The attacker already knows what site the victim is expecting to load at a .local.computer domain. This requires personal knowledge of the victim's site because the DNS for .local.computer goes straight to 127.0.0.1. Requests are not proxied or logged. (Ok, after writing this, I realize I could change the local.computer to go through my servers then redirect the user to 127.0.0.1 enabling me to at least learn what subdomains are being requested. Still, I have no idea what that site is supposed to be.) - The attacker is able to spoof that website well enough that the victim (a developer of the website) is able to be fooled into giving up information. Is there another way this could be abused? I seriously would like to know. Thanks!
    - smt88 10y ago
      As the owner of local.computer, you are in a position to intercept anything a developer is sending to her server via HTTP request. This could be username/password, yes. You also then know the public IP address and public domain of a development server, which may allow you to access the server and learn secrets, steal stack traces, etc. It's a small security risk, but it's a non-zero risk with zero benefit. Just use fake, never-to-be-public domains. There's no downside. If you need to interact with something like Twilio (which you never need to do while developing), you can wait until you're ready to push to staging.
- greenyoda 10y ago
  This seems like a good reason for you to use that domain. But if someone else wants to do the same thing, it might be better for them to register their own domain that resolves to localhost rather than use yours - that way, they at least have control of how long their domain will be in existence and know that they control the IP address it resolves to.
jerf 10y ago
"Why would someone want to use this risky alternative?" Well, you can have some fun jamming this into various text fields that might block 127.0.0.1 and "localhost", but don't successfully block everything else that leads to local access, thus allowing you to use $SOME_NETWORK_SERVICE to probe its own internal services. It can also be fun to jam something like 127.3.22.99 into things that only block 127.0.0.1; the whole 127.0.0.0/8 is "localhost". Try it with ping sometime.

Mike_D_Brooks 10y ago

It's not a bad idea, but if you use Vagrant for virtual machines then you can always use the hosts updater plugin. It would be cool if Docker had this as well. Come to think of it, maybe someone needs to make a program which you can just type an ip and hostname in to and it will add it in for you...