[Solved] Can I remove the "Trusted domain error" from log

I read from several old posts that this warning merely indicates that someone out there is probing my server (which is very normal), no actual harm is done yet. It is safe to ignore it.

However, due to it huge volume, I would like to get rid of it (and only it).

I notice that on webgui > settings > logging, I can unclick the “Warning” at Log Level (the 3 dots on top). I am paranoid. Will this be over kill. i.e. Will I miss some other Warnings that I really need to be warned?

BTW, I’m using nextcloud 13.0.6 (waiting for notification on webgui to upgrade)

Thank you

I am not aware of an official methods to exclude specific logs.

I would try to setup e.g. fail2ban instead to ban the hosts/IPs that do the attempts. Maybe there is even a server side solution to directly block external webservers to access your Nextcloud: Somebody wants to bruteforce my Nextcloud and some Fatal errors webdav

Thanks for your reply.

Those messages I received looks something like: “Trusted domain error. “139.162.78.135” tried to access using “my-router’s-external-ip” as host.”
I place my NC server behind my router on which I port forward only 80 & 443 to it. Fail2ban may not help in my case.

Adding all attacker’s ip to iptables rules on router is not practical. I am thinking if there is any program that I can run on a raspberry pi, which is placed between my router and NC server, to do the filtering.

You can create a custom filter for fail2ban to check nextcloud.log for this error pattern and block the IP, if you want already on first attempt. But indeed, if the IPs vary much, this could end up in a very large amount of blocked IPs. Better would be indeed another solution that blocks such remote access attempts directly. Must be something possible, I means this is a remote webserver trying to access your PHP files, if I am not mistaken. There should be a way to block this directly, if not content is accessed via your own local webserver.

So far, I only use fail2ban on ssh. :stuck_out_tongue_closed_eyes:
I have do some google and find that fail2ban is powerful and simple. But still there is a learning curve. Also because it is powerful and simple, those examples I found just looks like broken pieces to me. Do you know any good tutorial?


To lower the learning curve, I am trying to apply fail2ban-client on a list of ip. I get the list (of ip that appear twice or above) by

$ sudo cat /path/to/nextcloud.log | grep “Trusted domain error” | cut -d":" -f8 | cut -d’"’ -f2 | sort | uniq -c | sort -rn | awk ‘{if ($1>1) {print $2}}’ > ip2ban.lst

But when I try applying fail2ban on a single ip

$ sudo fail2ban-client set ip2ban banip 5.8.10.202

I get

ERROR NOK: (‘ip2ban’,)
Sorry but the jail ‘ip2ban’ does not exist

I have to create something in jail.d/ but the only example I find there is defaults-debian.conf with 2 lines inside

[sshd]
enabled = true

just much too simple than I expect.

Should I fall back to use iptables -A INPUT directly? Any advice?

JUST FIND THAT EVEN “IPTABLES -A INPUT …” ON NC SERVER IS USELESS.

I have run on NC server (and double checked that this rule is active)

iptables -A INPUT -s 183.60.210.52 -j DROP

Just find again on the log

Trusted domain error. “183.60.210.52” tried to access using “my-router’s-external-ip” as host.

How comes? :open_mouth:

I am using fail2ban to lower the amount of these warnings.
My regex looks like:


failregex = ^.*\"remoteAddr\":\"\".*Trusted domain error.*$


Using this within fail2ban, you can specify easily, after how many attempts an IP should be blocked.

Thanks for your tips. But I really wonder if fail2ban is useful at all.

I am very confused because even a simple and direct iptables rule cannot block them out, how can fail2ban helps.

I adapt the statefull firewall script from Archlinux. To (test) change, I just flush the iptables, modify and re-run the script. Rules will last till next reboot. Simple, and simple is good. Right?
I have inserted at the very beginning of the script

iptables -A INPUT -s 183.60.210.52 -j DROP

but still I see 182.60.210.52 on the log afterward. @@

I am running out of idea. :weary:

Because I find that quite some ip addresses keep trying to knock my door from time to time, I am not dare to ignore it.

Instead of fail2ban, I find that ipset is more suitable for me because

  1. my nc server is put behind router/firewall, volume of such traffic is relatively small.
  2. for each ip I block, I block it forever.

To do it, I use a script to get the ip2ban list

sudo cat /path/to/nextcloud.log | grep “Trusted domain error” | cut -d":" -f8 | cut -d’"’ -f2 | sort | uniq -c | sort -rn | awk ‘{if ($1>1) {print $2}}’> /path/to/ip2ban.lst

after installed ipset, I use another script to read the ban list to ram

sudo ipset destroy
sudo ipset create banlist iphash
while IFS=‘’ read -r line || [[ -n “$line” ]]; do
sudo ipset add banlist $line
done < /path/to/ip2ban.lst

update the iptables script. After review the stateful firewall script of Archlinux, I relocate the DROP statement from “the very beginning of INPUT chain” to “just before the corresponding ACCEPT statement of the TCP chain”.

iptables -A TCP -p tcp --dport 80 -m set --match-set banlist src -j DROP
iptables -A TCP -p tcp --dport 80 -j ACCEPT
iptables -A TCP -p tcp --dport 443 -m set --match-set banlist src -j DROP
iptables -A TCP -p tcp --dport 443 -j ACCEPT

Set a crontab job to run the two scripts. ipset works closely with iptables that no restart or whatever is needed while updating the ip2ban list. Done.

Lastly, I have not rotated the nextcloud.log yet. Will make another script to consolidate ip2ban.old.lst and ip2ban.lst later.

----------edit
to make ipset persistent after reboot, check another easy to execute tutorial at Persistent ipset for Ubuntu/Debian compatible with ufw and iptables-persistent
I comment out the 2 ufw lines as I don’t use ufw; and uncomment the save change line. In fact, to play it safe, I run this line manually once before start the service.

Just for reference, this is what I did to enable fail2ban for Nextcloud logins:

	cat << _EOF_ > /etc/fail2ban/filter.d/nextcloud.conf
[Definition]
failregex={"reqId":".*","remoteAddr":".*","app":"core","message":"Login failed: '.*' \(Remote IP: '<HOST>'\)","level":2,"time":".*"}
ignoreregex =
_EOF_

	cp jail.conf jail.local

	cat << _EOF_ >> /etc/fail2ban/jail.local
[nextcloud]
enabled = true
port = http,https
#protocol = tcp
filter = nextcloud
maxretry = 3
bantime = 600
logpath = /path/to/nextcloud.log
_EOF_

	systemctl restart fail2ban

This of course is just for failed login attempts and not sure if this is still current :laughing: .
I don’t remember exactly, but I guess jail.local will be preferred over jail.conf, so this allows to keep the original jail.conf in case or failure, to allow automated APT updates etc.

For trusted domain errors, it could be something like this:

failregex={"reqId":".*","level":2,"time":".*","remoteAddr":"<HOST>",.*,"message":"Trusted domain error.*",.*}`

I just took the string from here: Trusted domain error from external - security issue?
To be sure, check how exactly the logs appear within your nextcloud.log.


That iptables -A INPUT -s 183.60.210.52 -j DROP does not work is indeed very strange. This should block on kernel level via netfilter, no idea how this can fail :thinking:.

But good you found an alternative :slightly_smiling_face:.

Thank you for your additional input. I will need it when I move my NC server to DMZ.

1 Like