I’m probably missing something really obvious here - I just upgraded from 184.108.40.206 to 220.127.116.11 but I now cannot log in remotely. The GUI loads and the process is listening on 0.0.0.0:8200 to remote access is still enabled from the earlier configuration - but somehow I cannot now load the login page.
I saw reference to this issue on a thread for the release notes to an earlier version, but I cannot work out how to apply the described fix (set hosts to *, or preferably use the full hostname).
Could someone help me work out how to restore remote access please?
You’ll need to access the web ui from the local host. Either through ssh/rdp or through port forwarding.
Then one you’re there you edit the settings page to specify “*” or the full host name.
@kenkendk I think we’ll have to address this upgrade issue before pushing out a new beta. We’ll see a lot of issues opened by beta upgrades otherwise.
Easiest solution is probably to grandfather them in by defaulting to “*” on existing installations and then only restrict by default on fresh installations.
Ahhh I see. I appear to be having a problem with caching of browser pages - I was not seeing the updated Settings page which was why I couldn’t figure it out - there was no field in his to enter “" or hostnames. In fact I’ve now entered "” using my VNC client to the actual machine and loaded the Web UI on a remote machine (FF63.0.1) and I’m seeing exactly the same - I had previously accessed 18.104.22.168 from this very same remote machine earlier in the day. Now when I log in, the logo has changed to “Duplicati Canary” and if I navigate to the About page, I see version 22.214.171.124. Yet when I load the Settings page I see this:
As you can see, it’s the old Settings page and there’s no Hostnames field.
I’d be in favour of grandfathering existing installations as you said - that way it continues to work as I “understood” it to work. However I’m not sure if you can add no-cache tags to that page also? It’s very confusing to be presented with an old version of the page when a new setting is required. If I go away and leave it for an hour or so, the cache expires and I can load the new version (can’t quote the exact time - I just know I walked away from the VNC session after making the intial forum post, and then when I came back to the VNC session I had the new copy of the page).
If you want me to test anything else I’d be happy to.
I ran into this issue when upgrading from 126.96.36.199 to 188.8.131.52 on my headless Linux box. I only access it remotely, so it wasn’t working after the upgrade. Had to use the IP address then enter the hostname into the settings field as mentioned above.
Can someone explain the rationale with this change? DNS-based attacks?
Why would someone bother setting up a rogue DNS record to connect to your duplicati web interface? They would already have to know the IP, and this block does nothing to prevent them from connecting by IP anyway.
That would open them up to the very problem the change adresses.
Basically you set up a DNS to handle attack.example.com, then send a phising email to the victim.
When the victim accesses attack.example.com the DNS resolves to whatever IP the attacker uses, say 172.x.x.x.
Now the malicious script is running in the browser and using “same origin” as localhost, and can thus access any http-based resource on your machine, including Duplicati run on localhost only.
The attack script can of course show whatever contents while it is working in the background, luring the user to wait until the attack completes.
By forcing the hostname to be explictly validated, the attacker needs to first guess what this is (if any are allowed) and seize control over that before the attack works.
Browsers are working to mitigate this issue by rejecting the low ttl setting, such that the IP for a hostname is fixed for the duration of the session after a lookup.