Duplicati upgrade - "The host header sent by the client is not allowed"

Hi there,

I’m probably missing something really obvious here - I just upgraded from 2.0.3.3 to 2.0.4.4 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?

Many thanks

James

1 Like

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.

2 Likes

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 2.0.3.3 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 2.0.4.4. 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.

Cache is supposed to be refreshed on upgrade, but there are some issue with it. It’s being discussed here Cache busting for new versions · Issue #3481 · duplicati/duplicati · GitHub

It’s not really related to the hostname validation, but it certainly didn’t reduce confusion :slight_smile:

Bumping this in case it affects anyone else.

I ran into this issue when upgrading from 2.0.3.3 to 2.0.4.5 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.

3 Likes

To prevent various DNS based attacks…

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.

The server responds with a flash or javascript payload. This payload probes the DNS until it returns attack.example.com127.0.0.1.
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.

More info:

What if we grand father them in and then prompt them in the UI to declare the value? Like how we prompt for password login.

The core issue is that we’re essentially breaking the software for existing users when upgrading. It’s more secure, but turning off their machine is also more secure.

Yes, sounds like a smart solution. We assume that the user has the WebUI open when they upgrade?

Do you want to prompt during the update?
I was thinking to just prompt on startup unless the setting is defined. Then if they want they can opt out with the ‘*’ setting if they really want to.

Thanks for the reply about DNS rebinding… I understand now. :slight_smile:

Where would I find those settings in text on a linux (Ubuntu) install? I have CLI-only access to one machine, I want to just edit it in.

I started the server with this command and was able to access the Web-GUI:

duplicati-server --webservice-interface=any --webservice-port=8200 --webservice-allowed-hostnames=*

3 Likes

Thanks! I backup my headless Linux boxes, and updating without reading the changelog resulted in this. Updating my /etc/default/duplicati file with these restored my access.

Thanks. This saved me some time.

Simply, you can use IP instead of DNS. Then you can parameter the option to accept connections on authorized DNS hosts. By default, only localhost and IP are authorized.