Disable nginx listening for one of the domains on a miab instance

Is there a supported way to disable nginx from answering for one of the domains hosted on a miab install. I’ve got one instance that WordPress scrapers / bots are scanning like crazy. What would be a good way to block those from flooding log files? Would putting something like cloudflare in front be the way to go?

Technically you could go though the nginx config file and comment out the lines for that subdomain. You could really break stuff though. So I recommend taking a backup of that file before starting to do anything.

File should be here:

nano   /etc/nginx/conf.d/local.conf

comments can be added by putting a # in front of the line.

I would like to restrict external access to /admin for the same reason.
Unfortunately, MIAB will overwrite that file in every night and remove changes with that. Right question is, where is template or instructions containing “right” contents of the local.conf file?

yeah so that gets modified in the /root/mailinabox/conf/nginx-primaryonly.conf file.

then you can run:

sudo management/web_update.py

from the /root/mailinabox/ directory to see the changes.

Again, this is not advised and could end up breaking things if your not careful or know what your doing, but it is possible to change this, also that file likely will get replaced when you update MIAB so keep track of your changes so you can put it back upon a new upgrade.

in my opinion MIAB is too restrictive on these config files. Some customization should be possible. Like apt upgrade does. If config file is modified - keep it, and/or write new config file with different extension or something.

For example, why /admin interface should be visible to the world? Every bot receiving response from that URL start poking around in there. But there is no simple or supported way to hide it. Fortunately at least firewall rules and some other config changes persist between daily maintenances allowing to close ssh port to the world.

It’s too complicated to make every option for everyone. This project wouldn’t be possible if we did every different configuration possibility that every user asked for. A strong password and two-factor authentication will have to be good enough!

exposing to the world unnecessary services is against good security policy.

Let me ask this in other way. With upgrade I can understand, but Is it really necessary overwrite nginx conf every night? Why?

Tell that to literally every website with a login page.

It’s not just upgrades. The contents may change between upgrades. You should read the source code to see what circumstances that may be. (I don’t exactly remember. This is around a decade old.)

every website probably don’t care, but they should. Especially with admin interfaces. We do not discuss here some complicated user interface changes, but allowing simple customization of the nginx config file.

management/daily_tasks.sh undo changes made in local.conf every night. There is no obvious reason for that. So I’m asking is there a reason or is that some mistake.

I think it has to in order to apply subdomains and new certs that are added, right?

It’s not with the intent to overwrite user changes each night. But it’s not a mistake. I think it is a side effect of the https/TLS certificate acquisition process to ensure nginx gets restarted if any certificate changes, even if no nginx directives change. But yeah as @stylnchris notes, there can be a change in directives after certificates are acquired. (There probably aren’t any other changes that occur in the middle of the night, but the same logic is used when the user makes other changes in the admin.)

1 Like

Thanks for all of the responses. Really, my only goal is to find some way to block vulnerability scanners and other nefarious activity from interacting with nginx from a denial-of-service point of view. I’m seeing a little over 4000 hits daily at a clip of 100 or so at short timespans of a few seconds per clip. I just want to block that activity. Is there a supported way to enable the nginx or Wordpress fail2ban configs along the same lines as the one for ssh that’ll block that and won’t end up being overwritten in the future?

then there must be some kind of logic error. As far I understand, certificate acquisition not require rewriting nginx conf. Especially when certs is not actually acquired.

My phyton is a little rusty, but seems like management/web_update.py (run by ssl_certificates.py) generate new local.conf and then compares it with current one, and if anything has changed, then overwrite it and restart nginx. Rremoving also manual changes in there.

So, in short, web_update.py don’t know or care is there actually new certificates installed. It just detect change in local.conf and overwrite it followed by restarting nginx. Interestingly, mail services get restarted only when new certs is installed, but
web_update.py is started in any case, even when not actually needed.

Anyway, there should be different config files to separate static and dynamic parts of the configuration. That would resolve a lot of problems. Let the install/update write static config and daily maintenance deal with dynamic ones.

I think this has been discussed on git:
But it has not come to fruition

Moving the admin page to another port, as well-known ports are easier targets for attacks.
For now you might just use an uwf deny port 80, 443 rule and turn it on and off to access the admin page.

just my thoughts. Port change is maybe too drastic measure, because that will make using admin page more inconvenient. allow/disallow rule in nginx conf not forcing to write port number every time in the URL and at the same time allow limit access to selected sensitive folders.

4-5 years as passed since that discussion and nothing has changed.

You could try port knocking works for me using ssh and https

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.