Restrict admin access from internet

[axelere]

Hello,

I've installed DefGuard on three Ubuntu servers. In my proxy setup, I have two network interfaces: DMZ (for public access) and MGT (for SSH access).
I'd like to restrict admin access the MGT interface only, and so completely block admin access from internet.

After some research, I couldn't find any documentation or discussion about this topic.
I've tried several proxy configurations to block the /admin/ path on DMZ interface while allowing it on MGT side, but without real success.

Is there any supported way to separate user and admin access across different interfaces or domains?

If not, is this feature planned or considered?

Thanks in advance for your help!

Axel

[teon]

Hi @axelere - can you elaborate more - what do you mean by ,proxy'? It's unclear if it's our proxy component or a reverse proxy (particularly I do not understand the /admin/ path - we have no such context - we have defguard core which should be in the intranet and our proxy for enrollment and onboarding services and keeping our desktop/mobile clients uptodate with configs).

Whatever the scenario is you can always use our ACLs which are firewall rules to define for example that Admin group has access to IPs/submets/etc (or doesn't have) - see our ACLs documentation.

They should be exactly what you are looking for.

[axelere]

Hi @teon,

Thank you for your quick response. You're right, I wasn’t clear enough in my first message.

My current implementation:

• DefGuard Core – 2 interfaces (SSH, gRPC)
• DefGuard GW – 5 interfaces (SSH, wg0, DMZ1, Internal VPN access, gRPC)
• DefGuard Proxy – 3 interfaces (SSH, DMZ2, gRPC)

My goal is to completely prevent admin access to the DefGuard web interface when the request comes from Internet.
In other words, if an admin wants to log in to web interface, they must go through management interface only.

I did think about using ACLs, but if I understand correctly, ACLs only apply to Wireguard traffic. In the documentation, I couldn’t find anything that would allow me to achieve this restriction for the web UI itself.

That’s why I tried to configure my reverse proxy to block https://defguard.domain.lu/admin/* or redirect it to https://defguard.domain.lu/me when the request comes from the Internet. Unfortunately, the result was not satisfactory.

If there’s currently no built-in way to achieve this and it’s planned for the future, the ideal implementation in my opinion would be to have two distinct GUIs:

• Interface 1: Exposed on Internet, without any admin features in Website menu.
• Interface 2: Not exposed to Internet, for admin users only, with full administrative options.

This would make it easy to separate securely user and admin access,reduce the attack surface if an admin user is compromised.

Axel

[teon]

Sounds like you have everything on one server. Am I correct?

To have the designed secured setup we recommend at least separating Defguard core from public facing components (proxy/gateway) - like on two separate VMs / servers.

Than defguard core (and the VM server) should only have local internal IPs/interfaces - accessible only from intranet / VPN.

But if you can't do that the only way to secure your reverse proxy setup for core (from public) is only through the proxy rules (I don't know what you use - nginx has restrictions for IP etc).

[axelere]

Hello @teon,

No, it is not - it runs on a separate VM as recommended in the documentation. The implementation follows the "Standalone package based installation" guide, with an Nginx reverse proxy in front.

My point is the following:
As I understand it, internet users should access Core only through the reverse proxy (port 8000 is not exposed to the internet, it’s only forwarded internally by proxy). This allows them to manage their own devices, MFA, change password, etc. - which is the current setup.

But my concern is: if an admin login to the web UI from internet (without VPN), they can still manage users, devices, ACLs, etc. So if an attacker somehow gains admin access (stolen credentials, bypassing MFA, etc.), they would have full control from internet.
To reduce this risk (maybe I’m just being a bit paranoid 😉), my suggestion would be to split web GUI into two separate interfaces:

• External interface (via reverse proxy, TCP 8000): accessible from internet, but with user-only rights (self-service: MFA, password change, device management).
• Internal interface (TCP 8001): accessible only from the internal network, with full admin rights (manage users, OpenID, SMTP, server config, etc.).

This would allow users to manage their accounts externally, while restricting admin functions to the internal network.

More details on the current setup:

Axel

[kchudy]

@axelere Your concern is absolutely valid and not paranoid at all.

Our recommended approach is not to expose Core at all. Only the Proxy and Gateway should be public. The Core web UI should be reachable only from the internal network or via VPN.

Users can still enroll through the Proxy and connect to the VPN via the Gateway.

Users manage their accounts only after connecting to the VPN.

With this approach, we do not see a strong need to divide the admin-related and user-related screens in the Core web UI.

More on our recommendations here.

[axelere]

@kchudy thank you very much for your feedback.

This is exactly the approach I used and implemented (except that I still use the Proxy internal interface (limited to internal IPs) for redirection to the core; I don't remember why I did it that way, I might need to change it).
I only identified one limitation with the implementation you described: For VPN locations with mandatory MFA, it must be temporarily disabled so that the remote user can access their profile to activate MFA.

A simple workflow idea for a new user, but without considering potential risks. Perhaps allow adding MFA via the proxy (GUI Enroll) if 0/3 MFA is configured ?

[teon]

@axelere No you don't need to do that. From version 1.6 we have enabled in the Desktop Client that if a VPN location requires MFA - during the user INITIAL enrollment, the user configures MFA in the desktop client during enrollment!

[axelere]

That's great if you've already changed this workflow! My experience was with version 1.5.x.
Thanks for all this information :)