User portal, unprotected access from the outside

Hi!
I’m trying to test NS8; yesterday I managed to install an instance on Proxmox/VM using Rocky’s ISO.

Side note: the pre-created image didn’t work for me after many attempts, I was never able to access the cluster-admin after changing the IP address; with or without restarting the VM.

I immediately activated the 2FA; several snapshot & reboots later I verified that it was working in the cluster-admin.

User Portal

And then I noticed something strange: the User Portal
This one is open to everyone, and yes I understand its function, but:

Is it possible to disable it?
I prefer to be the one to manage the user passwords.

Or, Is there a way to make it only accessible from certain IPs and exempt it from being accessible from the outside? (edit)I can’t use a strict policy at the moment; and I certainly think it will be easy to break any password in a matter of hours.

Justification:

After several erroneous attempts on purpose to “hack” some account, I don’t see NS8 doing anything to protect or block these attempts.

Thanks!


I forgot to ask this; I think it’s part of the topic:

My installation of Rocky was with the option of the least software to install.
But, I’m not sure if this similar to the NS8 qcow2 image, ie: my installation does not bring active apparmor or something security (which I don’t know).

(edit) Is this the way it should be, and is there a document to verify that my installation is NS8 secure?

Hi @MrE,

this will help to solve your problem.

Regards…

Uwe

1 Like

Forget what I linked there. That doesn’t solve the problem. The site is still bare-bottomed in the www. This is a security risk that should not exist in this form. Maybe @davidep has a solution for that.

2 Likes

(I wrote this before I saw your message.)

Thanks for the suggestion.
But in my case it does not seem to work; my firewall being the gateway (GW) if blocked, I can no longer manage the server (except by local IP). And of course, I suspect that any other service that I don’t use at the moment would stop working if I block the GW.

Then, and as soon as I give permission to the GW the user portal is accessible.

I think that ideally the portal should be from a port to be able to block it on my firewall.


For now; I will remove access to the GW (traefik) and manage it by IP, while I continue with my tests.

1 Like

I think that ideally the portal should be from a port to be able to block it on my firewall.

I agree with that. But it only seems to be the case with the User Manager page that it doesn’t work with @davidep solution. The administration page of NS8 e.g. my.domain.de/cluster-admin shows me “Forbidden”.

1 Like

In my case, if I remove the GW from the allowed IPs this happens inside my local network: Forbidden

As I am still testing; I will add my GW to what is allowed but will prevent external access completely.

And of course, by giving access to the GW, all my users on the local network can access the user portal.

1 Like

Yes, the user portal is configured in another .yml file, but the solution should be technically similar. I’m working on Traefik v3 upgrade and I’d like to add IPAllowList management to set-route action.

Meanwhile, for your security concerns, did you try the Crowdsec module?

The number of attempts required for a brute-force attack depends also on the password strength/complexity. System users must be aware of this.

4 Likes

@davidep Thank you

Yes, I used it but it was not useful (for now)
:zap:Something is wrong with my firewall configuration; incoming external IPs are not registered as such in NS Logs/Traeffik/Crowdsec, it only registers events as my internal GW’s IP. If I enable blocking I don’t want to imagine what will happen if this blocks my own GW’s IP or external fixed IP.

:star:TODO: So, I will have to check with our security provider or investigate to reflect the incoming source IP to protections like Crowdsec.

:star:TODO: I understand, and this will take me some time, but it is necessary.

I see you are working on something (IPAllowList) this will be very helpful. In my case, I would only allow its use internally to the PC group of IT managers.
I look forward to hearing about this upgrade.

:spiral_notepad: Here I need to make a note:
When I prevented the IP of my GW in YML file; I could no longer enter the “cluster-admin” nor the “user-portal” and although the “user-portal” is another thing I think it is necessary to consider this situation, that is to say if I block the “user-portal” that the cluster-admin is not affected.

:question: For implementing/migrating a mail server with NS8 (I have them with NS7); can this situation with the user portal be avoided by disabling it somehow? My mail users in NS7 are separated from the AD I have in NS7 and I would like to keep it that way.

Regards

If you use an HTTP proxy in the firewall, Traefik must be configured to look at the request headers added by the proxy and trust them to extract the original IP address. This is a missing feature in our Traefik configuration. I’m working on this use case too.

If you configure a port forward for 80 and 443 in the firewall, you’d see the orginal IP. I’m using this setup at work.

2 Likes

This breaks the reverse proxy letsencrypt certificates for there reverse proxy domains.

Better to arrange within the UI a block that it is not accessible from WAN if not required and a custom tweak at the prompt which can be overwritten by an update.

1 Like

I’m working also on providing a way (APIs) to distribute LE certificates from NS8 to external hosts.

3 Likes

Small addition.
My reverse proxies are also linked to NS8 server.
For example the Sogo and Nextcloud FQDN are on the NS8 server and forwarded by the reverse proxy with an LE certificate by Nethsecurity

Greetings Davide!
Where can I see the progress on this improvement?
I was very busy with work issues and I stopped checking the forum for 15 days.

Regards

1 Like

Greetings!

We recently released Core 3.6.0 and Traefik 3.0.0, introducing new features, though they are not yet visible in the UI—consider them as “previews.” You can find more details in these issues:

An upcoming release will bring UI management for IPAllowList: Expose IP allow list configuration in cluster web interface · Issue #7348 · NethServer/dev · GitHub.

Since your gateway acts as a front-end proxy, you’ll need to configure it as a trusted proxy, as explained in the linked issue 7305.

We’re still refining documentation and use cases, and future core releases will bring more UI improvements for HTTP routes and TLS certificates.

Let me know if you have any questions!

5 Likes