Linux does, so this will probably work for the majority of users here, but, I believe, it will not work for FreeBSD, for example (I'm on an iPad and don't have an SSH client at the moment so I can't verify). In those cases, however, you can add "aliases" to the loopback interface, with specific IP addresses in the 127/8 subnet, and then use them.
sudo ifconfig lo0 alias 127.1.2.3 0xff000000
sudo ifconfig lo0 -alias 127.1.2.3
For example to add extra interfaces to lo0 on FreeBSD you may use:
ipv4_addrs_lo0="127.0.0.2-5/8"
And now those addresses are automatically assigned to lo0, the netmask will be set to 255.255.255.255 automatically for all but the first in that range (.2). Since 127.0.0.1 is unconditionally assigned to lo0, you could also use:
ipv4_addrs_lo0="127.0.0.2-5/32"
You can manage this trivially in rc.conf and then restart the netif and route services.
A web browser is a locally running program. You mean, of course, that access to the socket can be limited to programs running under a user account sufficiently privileged to read and/or write to the socket file. Can all services be made to communicate only through domain sockets?
I agree that choosing randomly from the available loopback addresses and/or ports isn't providing any real security; it surely wouldn't take the web browser very long to make a connection to every port in the 127/8 address range.
That is of course correct. I should have worded it a bit more technical, I guess :-)
Support of unix domain sockets depends on the program, so not all support that, but Redis and memcache do. At least for those you can prevent the browser from connecting to them using TCP.
I guess another option would be to just limit what ports a browser can access. Some ports a blocked by default, but I feel like a whitelist instead of a blacklist makes more sense and I'm fairly certain that most of my daily browser usage would still work if only 80, 443 and maybe 8080 would be whitelisted. Is there a way to archive this (in chrome/Firefox) without reverting to some outside sandbox?
After briefly looking into this:-
- there doesn't seem to be a way to configure firefox with a whitelist of ports it may connect to
- AppArmor doesn't appear to yet be capable of constraining network access at the level of IP address or port number
- The good news is that it should be possible to use linux network namespaces along with iptables - I've not attempted it
They might mean instead that browsers can’t access domain sockets.
How do I do that? Iptables? (Sorry if this is a dumb question.)
It's pretty much always a command line flag or config file parameter.
If you're running with docker, it's even more standard. When you expose a port, just use `-p 127.12.12.3:11211:11211` (with your chosen IP address, of course), and docker will set up the forwarding for you, only for that address.
>>> import ipaddress
>>> import random
>>> ipaddress.IPv4Address('127.0.0.1') + random.randrange(2**24 - 2)
IPv4Address('127.23.181.175')Bear in mind, I'm a front end developer, so this is absolutely not my forte. Thanks for the help.
The point is that the most commonly used IP is 127.0.0.1 but we can as well use 127.120.99.12 because the entire subnet is the loopback address.
https://github.com/thewhitetulip/web-dev-golang-anti-textboo... For an example in Go.
I thought he said use 127.3.99.7 or something of that sort to avoid using the default localhost
Fortunately, the whole 127.0.0.0/8 block is automatically added to the loopback interface (edit: on Linux at least), so you can bind away to your heart's content.
How will your PC know how to resolve 3.0.0.0/8?
The birthday paradox means that you're probably going to spend a lot less time than that, but it's certainly going to buy me a lot longer than 1 minute that I get if I'm using 127.0.0.1. The chances I stay on any random website longer than 15 minutes are pretty slim, and you've got really poor odds of finding the right IP in that time.
1. I roll 1 die. What are the odds of getting a 3? (Assuming the die is evenly distributed 1-n, and n >= 3, the answer is 1/n )
2. I roll 100 dice. What are the odds of getting, among those dice, at least one result of 3? ( 1 - [(n-1)/n]^100 )
3. I roll 2 dice. What are the odds of those dice matching each other? ( 1/n )
4. I roll 100 dice. What are the odds of there being, among those 100 dice, any 2 dice that rolled the same result?
The birthday paradox provides the answer to problems of type (4).
a) attacking multiple targets all using independent random IPs for their services
b) Users running multiple services, each on a separate random loopback IP
And if I'm correct there, then this would presumably extend to generic DNS rebinding attacks; the greater the number of IPs in a subnet, the greater the birthday attack advantage the attacker gains. (right?)
Your (b) is similar, but even more helpful to the attacker in that the loopback IPs are constrained not to overlap with each other, which makes searching for "any hit, I don't care which" easier.
It's a birthday attack if you generate a lot of values and hope for two of those values -- all of which you generated -- to be equal to each other. If you're generating values and hoping for one of those values to be equal to some externally-defined value, it's not a birthday attack, it's a guessing attack.
Right, but that assumes a new DNS record is created each time. An attacker might simply have records for the entire 127.0.0.0/8 range and would iterate over them.
It would still take a long time to make an exhaustive search, but it will be faster than waiting for a 1 minute TTL between each try.
The DNS rebinding is a workaround so that you can read the reply of a message.
Enumerating a list of services that are running is something you could do as a precursor to using the dns rebinding attack to attack it. I am not familiar with javascript networking enough to say what kind of rate limiting you would incur, but in theory at least you should be able to probe many IPs at once.
The real solution is for tools to not assume local host connections are secure.
The entire 127.0.0.0/8 block is dedicated to the loopback interface [1]. That's 2^24 - 2 unique IP addresses you can choose at random. This basically eliminates the feasibility of the DNS rebinding component, as it would take prohibitively long to find the actual loopback address that your services have bound to.
It's important to note that this is much more effective than not using the default port. It's much faster to iterate all 2^16 ports on the same IP address than it is to wait for DNS TTL to expire so you can rebind to another IP address.
As a bonus, you don't have to worry about port collisions when nobody's allowed to listen on 0.0.0.0. Everybody can use 8080 if they want.
[1] https://tools.ietf.org/html/rfc5735#section-3