Hello,
I installed on a german V-Server Frappe and ERPNext in a multi tenant setup. I used following install routine:
All ERPNext subdomains are with ssl secured via Let’s Encrypt.
All subdomains are registered at my domain provider and the dns a-record is set to the IP of my virtual ubuntu 18.04 cloud server.
With this server running i’ve got an email from our german state department of information security. They said i have an “open dns resolver” running. It is just a hint from them because this can be used for DDoS-Reflection/Amplification-attacks and they advice to convert that “open dns resolver” by disable recursion or limit recursion to trusted clients in the DNS server’s configuration.
How can i solve this problem with my current setup?
Hi you best refer this to your DNS service provider.
The problem has to do with how they have configured the name space zones of your domain and subdomains, and authoritative (trusted) servers that answer a query for a host lookup.
Presumably the general risk here is possibly a server can be compromised or say a rogue untrusted server added to the set of trusted servers?
At my domain provider i have only three subdomains. Each domain is via A-Record redirected to my virtual cloud server with a separate site (name of subdomain) of my bench. I have no more subdomains listed at my domain provider. All sites are configured with nginx as multitenant.
I have one more blank bench site, which is directly reachable with the v-server ip. That was the only way to get a multitenant setup workable because i couldn’t set up ssl encrypting for the default site, only the following sites have succesfully ssl encrypting (https). Every time I tried there was the “Sorry! We will be back soon.” notification.
Is maybe this the error? I think that maybe nginx is the reason.
I had the same experience with our vultr servers. I had to add enable firewall manually, just keeping port 443 and 80 open for incoming.
Rest all closed for incoming.
This had solved the issue I guess. I hope this is the real solution if not then i would be interested to know.
Yes, quite likely your cloud provider shares responsibility with your dns provider for name space resolution and query results - so best to find a dns expert to run say nslookup tests to identify which one is the culprit!?
I also got a warning today for my recently installed server from the BSI telling me that my server has DNS open-resolver enabled.
I am looking into this.
None of my other servers were on the same situation.
I got a new cloud server a few days ago, and ported my previous v11 installation to it. I am supposing that my previous server was not on the same situation, as I had it for several years and never received the warning, but I can check it.
I am recreating the steps done, because at the moment I don’t know what is producing the dns open-resolver situation. I don’t have Bind9 installed.
I am also in Ubuntu 18.04. By now what I have seen is:
1.- Create server from Ubuntu 18.04 Hetzner image- No problem
2.- After installing ERPNext I check again and now the server is a dns open-server
So I think that definitely this is something related to ERPNext.
I failed to configure the firewall this time and I am sure that this stops the thread, but I wonder why is ERPNext doing this by default and if this might be mitigated to enhance the security by default.
I can do basic things with server, but I am totaly blank with dns related matters.