rXg protecting UI / shell from public access
January 31, 2025
Introduction
The management plane on the rXg platform must be protected in production conditions against unauthorized access, especially when hosting a high value network infrastructure. It is also recommended that all unnecessary ports on the WAN and LAN side of the rXg are closed, leaving only the service-related ones open and accessible. This means shutting down SSH and HTTP(S) access on the WAN side and by default on the LAN side, leaving access to the management plane restricted to a specific LAN segment with tight security policy.
This KB document shows a way to restrict access to the rXg management plane under several different scenarios using the in-build ‘Admin ACL’ mechanism. The rXg platform used in this KB document is on code release 16.025, though the core functionality of this feature has been available for a long time.
A Word of Warning
Please be warned that the ‘Admin ACL’ mechanism, when applied incorrectly, can easily remove all access to the management plane on the rXg platform. Special attention should be paid to the selected WAN Targets / Policies creating exceptions, making sure that at least one access path remains at any time. In such cases, console access to the rXg shell is required to recover access to the management plane and disable the Admin ACLs. To delete all Admin ACLs from the rXg shell, execute the following in the Ruby console:
[1] pry(main)> AdminControllerAcl.destroy_all => [#<AdminControllerAcl:0x00002d6c45a15200 id: 3, name: "Scenario (b)", active: false, note: nil, created_by: "adminuser", updated_by: "adminuser", created_at: Tue, 28 Jan 2025 19:09:30.456246000 PST -08:00, updated_at: Tue, 28 Jan 2025 19:17:06.710642000 PST -08:00, scratch: nil, block_admin: true, block_ssh: true, block_web_wan: true, block_web_lan: true, allow_wan_until: nil, backend_load_at: nil>, #<AdminControllerAcl:0x00002d6c3f9d3ea0 id: 2, name: "Scenario (a)", active: false, note: nil, created_by: "adminuser", updated_by: "adminuser", created_at: Tue, 28 Jan 2025 17:20:28.864361000 PST -08:00, updated_at: Wed, 29 Jan 2025 05:51:39.137781000 PST -08:00, scratch: nil, block_admin: true, block_ssh: true, block_web_wan: true, block_web_lan: true, allow_wan_until: nil, backend_load_at: nil>]
Do note that this operation will remove all Admin ACLs from the system and require them to be rebuilt.
Prerequisites
Several scenarios are considered, including
- Scenario (a), with the management plane access restricted to a dedicated management sub-interface only, with no access on the WAN and LAN side otherwise
- Scenario (b), with no LAN-side access, and WAN access restricted to selected public addresses
The configuration process relies on the ‘System::Admins::Admin ACLs’ scaffold (see https://www.rgnets.com/manual/system/admins) with the combination of WAN targets (see https://www.rgnets.com/manual/identities/definitions) and Policies (see https://www.rgnets.com/manual/policies).
The LAN interface features two sub-interfaces, created on a LAGG interface (see a separate KB document for LAGG interface configuration): ‘LAN-VID-0031’ and ‘LAN-VID-0032’, with VLAN IDs of 31 and 32, respectively. ‘LAN-VID-0032’ is used to emulate a customer-facing LAN, while ‘LAN-VID-0031’ is used to emulate the trusted management network. ‘LAN-10.0.31.0/24-IP’ and ‘LAN-10.0.32.0/24-IP’ are also created and assigned to specific subinterfaces, as shown below in the ‘Network::LAN’ scaffold.
The following WAN Targets were created in the ‘Identities::Definitions::WAN targets’ scaffold:
The following Policies were created in the ‘Policies::Policies’ scaffold:
In the default state, the following ports are open on the WAN interface: 22, 80, and 443.
nmap 192.168.150.38
Starting Nmap 7.80 ( https://nmap.org ) at 2025-01-29 01:14 UTCNmap scan report for 192.168.150.38Host is up (0.00034s latency).Not shown: 997 filtered portsPORT STATE SERVICE22/tcp open ssh80/tcp open http443/tcp open https
Nmap done: 1 IP address (1 host up) scanned in 4.76 secondsThe following ports are open on the LAN subinterfaces: nmap 10.0.31.1Starting Nmap 7.80 ( https://nmap.org ) at 2025-01-29 02:29 UTCNmap scan report for _gateway (10.0.31.1)Host is up (0.00042s latency).Not shown: 996 filtered portsPORT STATE SERVICE22/tcp open ssh53/tcp open domain80/tcp open http443/tcp open https
Nmap done: 1 IP address (1 host up) scanned in 4.25 seconds
nmap 10.0.32.1Starting Nmap 7.80 ( https://nmap.org ) at 2025-01-29 02:53 UTCNmap scan report for _gateway (10.0.32.1)Host is up (0.00035s latency).Not shown: 996 filtered portsPORT STATE SERVICE22/tcp open ssh53/tcp open domain80/tcp open http443/tcp open https
Nmap done: 1 IP address (1 host up) scanned in 4.65 seconds
Scenario (a)
In this scenario, access to the management plane is restricted to a dedicated ‘Management’ sub-interface on the LAN side only, with no access on the WAN and LAN side otherwise. An administrator must be therefore located on the ‘Management’ subinterface for SSH and/or HTTP(S) access to the rXg management plane. The resulting management plane access is shown below.
Therefore, the following functional requirements hold:
- Access to SSH / HTTP(S) is restricted from any untrusted source, i.e., from public Internet or the ‘LAN-VID-0032’ subinterface
- Access to SSH / HTTP(S) is granted from a trusted source, i.e., any host on the ‘LAN-VID-0031’ subinterface
To create the Admin ACL entry, use the ‘System::Admins::Admin ACLs’ scaffold and create the following entry for Scenario (a):
- ‘Name’, an arbitrary name for the policy
- ‘Active’, make sure the field is checked to activate the policy
- ‘Block Admin’, ‘Block SSH’, ‘Block HTTP/S (WAN)’, and ‘Block HTTP/S (LAN)’ fields are to be checked
- Select the ‘LAN-10.0.31.0/24’ WAN target in the ‘WAN Targets’ selector field
- No policies are selected
When attempting to access the management plane from the WAN side, the following message is being displayed, indicating no access is available.
A port scan on the WAN interface shows all previously open ports now closed
nmap 192.168.150.38 -p-
Starting Nmap 7.80 ( https://nmap.org ) at 2025-01-29 01:21 UTC
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 3.05 secondsA port scan on the LAN interfaces from a VM on the ‘LAN-VID-0031’ shows all previously open ports now closed. It is still possible to access the management interface, though, as shown below. When originating from the ‘LAN-VID-0031’, it is also possible to access the management interface on the WAN side. nmap 10.0.31.1
Starting Nmap 7.80 ( https://nmap.org ) at 2025-01-29 02:13 UTC
Nmap scan report for _gateway (10.0.31.1)
Host is up (0.00031s latency).
Not shown: 999 filtered ports
PORT STATE SERVICE
53/tcp open domain
MAC Address: 3C:FD:FE:BD:A2:60 (Intel Corporate)
Nmap done: 1 IP address (1 host up) scanned in 4.69 seconds
nmap 10.0.32.1
Starting Nmap 7.80 ( https://nmap.org ) at 2025-01-29 02:18 UTC
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 3.09 seconds
A port scan on the LAN interfaces from a VM on the ‘LAN-VID-0032’ shows all previously open ports now closed. The attempt to establish a connection to the admin interface times out, including access via the WAN interface, which is just denied.
nmap 10.0.31.1
Starting Nmap 7.80 ( https://nmap.org ) at 2025-01-29 02:19 UTC
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 3.04 seconds
nmap 10.0.32.1
Starting Nmap 7.80 ( https://nmap.org ) at 2025-01-29 02:19 UTC
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 3.04 seconds
Scenario (b)
In this scenario, access to the management plane is completely restricted from the LAN side, independent of which VLAN the request originates from. The access on the WAN side is restricted to only one host, with the IP address of 192.168.150.2/32. The resulting management plane access is shown below.
Therefore, the following functional requirements hold:
- Access to SSH / HTTP(S) is restricted from any LAN-based source as well as any unknown (untrusted) hosts on the WAN side
- Access to SSH / HTTP(S) is granted from a trusted source, i.e., a host with the IP of 192.168.150.2/32.
To create the Admin ACL entry, use the ‘System::Admins::Admin ACLs’ scaffold and create the following entry for Scenario (b):
- ‘Name’, an arbitrary name for the policy
- ‘Active’, make sure the field is checked to activate the policy
- ‘Block Admin’, ‘Block SSH’, ‘Block HTTP/S (WAN)’, and ‘Block HTTP/S (LAN)’ fields are to be checked
- Select the ‘WAN-192.168.150.2/32’ WAN target in the ‘WAN Targets’ selector field
- No policies are selected
When attempting to access the management plane from the WAN side from a host other than the ‘WAN-192.168.150.2/32’ WAN target, the following message is being displayed, indicating no access is available.
Access to the management plane from the ‘WAN-192.168.150.2/32’ WAN target is available:
Access from the LAN-based VMs is also blocked, as expected.
All ports on the rXg platform are closed when probing from the LAN-side VMs:
nmap 10.0.31.1
Starting Nmap 7.80 ( https://nmap.org ) at 2025-01-29 03:15 UTC
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 3.04 seconds
nmap 10.0.32.1
Starting Nmap 7.80 ( https://nmap.org ) at 2025-01-29 03:14 UTC
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 3.04 seconds
