deny access to apache using public IP

[testbird]

I found many unsolicited access attemps even in the NC admin interface log complaining about "secure domain" failures. These were requests using the external IP as domain.

Instead of having apache listening and NC block these request, maybe apached could be configured right away to only answer requests using IPs (instead of dns domain names) if they are local IPs.

~~Here is an example restricting request based on the source IP, which is another thing, but maybe the same ranges can be used to bypass a "apache secure domains configuration" https://salsa.debian.org/freedombox-team/plinth/commit/21d6174ba052e22926f05b0a6806e3fa7f83c8f1~~

This is like in this question (however, the actual config for the solution there is at the duplicate question): https://serverfault.com/questions/786809/block-direct-ip-connections-to-apache-web-server

[nachoparker]

hi, that is exactly what ncp-web does but... I do want to access to NextCloudPi from outside my local IPs.

I want to access from my phone, from work, and so on.

[testbird]

I want to access from my phone, from work, and so on.

Sure. But you know and use your (dyn)DNS name to access, while portscanners and search bots just try IPs (http://1.2.3.4 etc.) and spider whatever they find. What I thought about would have a similar result as if NC would return nothing in response to requests for "non-trusted domains" instead of the info page, ideally it would be as if the port wasn't opened at all in the firewall.

Its like the solution to this question (actual config of the solution is at the duplicate question) https://serverfault.com/questions/786809/block-direct-ip-connections-to-apache-web-server

[nachoparker]

ok, I get you now... well that is interesting then, I just wonder if there will be use cases of people wanting to access through external IP address.

otherwise, I think it's worth implementing it

feeling brave to throw a PR at me? :P

[testbird]

Yes, the use case would be those with a static IP and avoiding tracking of their DNS lookups (connection activity).

[nachoparker]

@testbird

feeling brave to throw a PR at me? :P

[testbird]

You don't necessarily need to ask. I do make PRs if I think it's reachable for me and I'm able to. Still struggling with my docker container.

(In looking for above, I came accross a potentially vast apache config https://askubuntu.com/questions/922085/i-need-rules-to-drop-some-malicious-apache-connection)

[nachoparker]

haha it was worth a try ;D

[theCalcaholic]

It should definitely disabled if no domain is defined and probably not be enabled by default. I'm using NCP behind a static IP for instance - probably a few others as well.

Of course most will still use a domain (especially for proper TLS), but it would be confusing if you couldn't reach the instance by IP - which is also often necessary for debugging purposes.

[nachoparker]

It should definitely disabled if no domain is defined and probably not be enabled by default. I'm using NCP behind a static IP for instance - probably a few others as well.

Do you access from outside through static IP, not by DDNS domain name? It is true that we would block many attack attempts by implementing this.

[nachoparker]

Regardless of wether we do it or not, I am wondering if the following would work ( in /etc/apache2/sites-enabled/nextcloud.conf )

<RequireAny>
      Require host *
      Require local
      Require ip 192.168
      Require ip 172
      Require ip 10
</RequireAny>

We would need to test if host * would capture any hostname, but not direct access by IP. The other lines I know that work because are copied from ncp.conf, so they could be commented out for the test.

<RequireAny>
      Require host *
</RequireAny>

In that case, the above config should not allow any IP access (local or otherwise), but should allow domain access.

[theCalcaholic]

@nachoparker I do for testing/debugging purposes mainly (port/DNS setup and such).

[testbird]

I think you'll still be able to test the port forwarding as you see a "not allowed" message from apache.

[testbird]

From what I read in the links above "host *" would have to be in the first (used as default) virtual host stanza (whichever that may be with multiple files).

[nachoparker]

in a quick test, host * it didn't work, I guess that the solution would be to, if anything, add these lines only when we set up DDNS

<RequireAny>
      Require local
      Require ip 192.168
      Require ip 172
      Require ip 10
</RequireAny>

[testbird]

maybe a regexp is expected? .*

[testbird]

No, i actually just commented out "Require host localhost", it checks the domain of the ip the request is comming from, and reverse lookup does not work for every ip, and not at all in the docker container.

The solution to this issue is, as in the linked answers above, have a first "dummy" virtualhost block everything (it gets used as fallback for non defined virtual hosts).

[nachoparker]

The solution to this issue is, as in the linked answers above, have a first "dummy" virtualhost block everything (it gets used as fallback for non defined virtual hosts).

I aggree, it would be nice if somebody could come up with this configuration, as my hands are pretty full right now

[Aeon512]

Just wanted to throw in my opinion on this. Why not using the geoip database, and overing an option in NCP to specify which countries are allowed to externally access NextCloud?

Usually, there are only a few countries where you usually want to have access from, so you would filter out a lot of unwanted accesses.

Having said that, the best approach is still to enabled the two factor authentication plugin in NextCloud and enforce this for all users.

[nachoparker]

Thanks

Usually, there are only a few countries where you usually want to have access from, so you would filter out a lot of unwanted accesses.

This would prevent us from using Tor

[szaimen]

Hey, maybe something here can be useful? https://github.com/nextcloud/vm/blob/master/network/geoblock.sh