Nextcloud 27.0.0 not logging 'Trusted domain' errors in log

[DavidMndz]

Nextcloud version: 27.0.0
Operating system and version: Debian 12
Apache or nginx version: Apache 2.4.57
PHP version: 8.2

The issue you are facing:

Is this the first time you’ve seen this error? (Y/N): Yes

Steps to replicate it:

1. Try to log in your Nextcloud instance using a name / IP that connects to it, but it is not part of trusted domains in the configuration file.
2. Check the nextcloud.log

The only log where I can see something is in the /var/log/apache2/access.log:

XX.XX.XX.XXX - - [18/Jul/2023:19:19:06 +0200] "GET /apps/theming/css/default.css?v=34e90de1-0 HTTP/2.0" 200 1549 "-" "Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/115.0.0.0 Mobile Safari/537.36"
XX.XX.XX.XXX - - [18/Jul/2023:19:19:06 +0200] "GET /core/css/guest.css?v=5e811f91-0 HTTP/2.0" 200 5019 "-" "Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/115.0.0.0 Mobile Safari/537.36"
XX.XX.XX.XXX - - [18/Jul/2023:19:19:06 +0200] "GET /core/css/server.css?v=5e811f91-0 HTTP/2.0" 200 17371 "-" "Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/115.0.0.0 Mobile Safari/537.36"

Summary:

Until now, when an access was attempted using the IP it was logged as an error in the nextcloud log stating it was not using a valid ‘trusted domain’; I only have in the configuration the FQDN as a trusted domain.

Currently, I was checking if in Nextcloud 27 there was any update in the hardening part, related to the fail2ban configuration and while reviewing the logs I realised the log might not be working as expected, so I forced few attempts manually. The message is properly displayed in the browser but the “rejection” is not logged at all in the nextcloud.log. In the web admin page, in Logging, nothing is showed either even with Debug mode marked.

In the other hand, other errors, including the ‘failed login’ attempts are being logged properly.

Before opening a ticket in GitHub, I wanted to check here, just in case anyone else is able to reproduce the error to verify it is not only on my installation. Any idea about what else to check?

Thanks all!

Edit: I tested it in a test environment I have, running Nextcloud 26.0.3 and I see the same behaviour.

[jtr]

Intriguing. I checked on my test instances (all the way back to NC24) and verified that these events aren’t getting logged. Which surprised me because I see the code there.

That code path is definitely being executed because the template that triggers the untrustedDomain (the one that spits out “Access through untrusted domain” in the browswer) - which is working - is right there with the logging:

nextcloud/server/blob/af6bb98b144d0d333cb29fdd9370ed4465f4ba6e/lib/base.php#L836-L850

EDIT: Follow-up: I must have been tired the last time I looked at the code (above). It logs at info level (e.g. 'loglevel' => 1) just fine.

Info: Trusted domain error. "192.168.a.b" tried to access using "nc-ZZZZZZ.XXX.org:YYYY" as host.

GET /apps/theming/favicon?v=11b0ab82
from 192.168.a.b at 2023-12-29T02:01:40+00:00

[ernolf]

@jtr

I must have been tired the last time I looked at the code (above). It logs at info level (e.g. 'loglevel' => 1) just fine.

exactly. It logs it as a very unimportant event: as information.

@DavidMndz:

You have various possibilities now:

Add Catch-All VirtualHosts to Apache

(my favourite)

<VirtualHost *:80>
  ServerName null
  ServerAlias *
  Redirect 307 / http://your_honey.pott
</VirtualHost>

<VirtualHost *:443>
  ServerName null
  ServerAlias *
  Redirect 307 / https://your_honey.pott
</VirtualHost>

This will prevent the client on the other side, to get the information that there is a nextcloud server under that IP and it will be redirected to any place you want. If you have a honeypott host, you can redirect it to there like in the example but you can redirect to 404 :

  Redirect 404 /

… or to a blank page or whatever.
Now you can use the logentries in the apache2 log for fail2ban

---

Change loglevel

You can of course use the nextcloud log as well but you will have to switch loglevel to 1, which has the downside, that it produces hughe masses of logentries without important information at all.
You can change the loglevel in the servercode, so that it is not more loged as info but as warning. All you have to do to achieve that, is:

find out in what line of the file (in this case the file is lib/base.php) this is defined:

declare NC_DIR="var/www/nextcloud" # change this to your needs

grep -nC 1 '>info' $NC_DIR/lib/base.php

In this case it will give you this echo:

833-                            http_response_code(400);
834:                            Server::get(LoggerInterface::class)->info(
835-                                    'Trusted domain error. "{remoteAddress}" tried to access using "{host}" as host.',

As you can see, it is the line number 834 where the loglevel is defined.

Add this function to your .bash_aliases or to your .bash_functions or whatever file you use for that purpose:

declare NC_DIR="var/www/nextcloud" # change this to your needs

# change anoying or insufficient loglevel. Example:
# nc_loglevel error2info lib/private/Files/Node/Root.php 365
nc_loglevel(){ local file=$2 line_number=$3
    case "$1" in
        error2info) sed -i "${line_number}s|error|info|" $NC_DIR/$file ;;
        info2error) sed -i "${line_number}s|info|error|" $NC_DIR/$file ;;
        warn2info) sed -i "${line_number}s|warning|info|" $NC_DIR/$file ;;
        info2warn) sed -i "${line_number}s|info|warning|" $NC_DIR/$file ;;
    esac
}

and now you can simply change the loglevel with

nc_loglevel info2warn lib/base.php 834

That step must be done after every update. If you get complaints about integrity, you should revert the change (therefore it is important that you have a server diary where you writes down all such kind of changes), run

occ integrity:check-core

and then you can change it again as above.

---

Much luck,
ernolf

[DavidMndz]

Hello,

first of all, thank you all very much for all the details, I really appreciate your time and efforts providing new approaches to review this.

I tested it changing to log level 1 and even to debug mode in the Nextcloud log mode, but even in those cases, I cannot see anything being written in the Nextcloud log about the Untrusted domain; I restarted the webserver just in case but nothing is appearing about this topic.

Any idea about how I could test it further?

Thanks!

[jtr]

@DavidMndz

I tested it changing to log level 1 and even to debug mode in the Nextcloud log mode, but even in those cases, I cannot see anything being written in the Nextcloud log about the Untrusted domain; I restarted the webserver just in case but nothing is appearing about this topic.

I guess post the output of:

grep "Trusted" data/nextcloud.log

And, if that is empty, post the output of:

occ config:list system

But I tested this last night and feel pretty confident it works.

Oh, are you merely changing the log level in the Web UI? In that case, there’s a possibility the change isn’t making it into service due to caching. Unfortunately the normal workaround for that would be to restart your app server, but that’s not useful if you’re not making the change to config.php directly.

Change your log level 1 in your config.php rather than just temporarily in the Web UI. Then restart the app server. I bet it’ll show up for you.

[DavidMndz]

It finally worked again, I was changing it in the config.php directly to log level 1, but it was not showing up anything even after reboot the web server. Later, I checked it again and it was working perfectly.

The log level 1 is fine for me as a workaround but I will review the option of logging it as log level 2 and also the other option presented about the 404 page.

Thank you all very much!