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.
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?
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.
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.
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”.
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.
Yes, I used it but it was not useful (for now) 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.
TODO: So, I will have to check with our security provider or investigate to reflect the incoming source IP to protections like Crowdsec.
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.
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.
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.
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.
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.
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
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:
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.
TODO: So, I will have to check with our security provider or investigate to reflect the incoming source IP to protections like Crowdsec.
Here I need to make a note:
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.