{"id":4977,"date":"2026-02-11T16:59:22","date_gmt":"2026-02-11T13:59:22","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/secure-remote-access-to-hosting-panels-with-vpn-and-bastion-hosts\/"},"modified":"2026-02-11T16:59:22","modified_gmt":"2026-02-11T13:59:22","slug":"secure-remote-access-to-hosting-panels-with-vpn-and-bastion-hosts","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/secure-remote-access-to-hosting-panels-with-vpn-and-bastion-hosts\/","title":{"rendered":"Secure Remote Access to Hosting Panels with VPN and Bastion Hosts"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><p>When you manage multiple cPanel, DirectAdmin, Plesk or custom hosting panels across <a href=\"https:\/\/www.dchost.com\/vps\">VPS<\/a>, <a href=\"https:\/\/www.dchost.com\/dedicated-server\">dedicated server<\/a>s or colocation, the real challenge is not just performance\u2014it is <strong>how people log in<\/strong>. Exposed admin URLs, shared passwords and open SSH ports are still the default in many teams, even though automated scans and credential stuffing attacks target these surfaces 24\/7. A safer pattern is to move from \u201copen to the internet\u201d to a controlled <strong>VPN + bastion host<\/strong> architecture, where all remote access flows through a small, well\u2011hardened entry point. In this article, we will design that architecture step by step\u2014network layout, firewall rules, user workflows and migration strategy\u2014so you can secure hosting panels without making daily operations painful. The same principles apply whether your infrastructure lives on shared hosting, VPS, dedicated servers or colocation at dchost.com.<\/p>\n<div id=\"toc_container\" class=\"toc_transparent no_bullets\"><p class=\"toc_title\">\u0130&ccedil;indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#Why_Direct_Internet_Access_to_Hosting_Panels_Is_Dangerous\"><span class=\"toc_number toc_depth_1\">1<\/span> Why Direct Internet Access to Hosting Panels Is Dangerous<\/a><\/li><li><a href=\"#Core_Concepts_VPN_Bastion_Host_and_ZeroTrust_Access\"><span class=\"toc_number toc_depth_1\">2<\/span> Core Concepts: VPN, Bastion Host and Zero\u2011Trust Access<\/a><ul><li><a href=\"#Virtual_Private_Network_VPN\"><span class=\"toc_number toc_depth_2\">2.1<\/span> Virtual Private Network (VPN)<\/a><\/li><li><a href=\"#Bastion_Host_Jump_Server\"><span class=\"toc_number toc_depth_2\">2.2<\/span> Bastion Host (Jump Server)<\/a><\/li><li><a href=\"#ZeroTrust_Approach_to_Admin_Access\"><span class=\"toc_number toc_depth_2\">2.3<\/span> Zero\u2011Trust Approach to Admin Access<\/a><\/li><\/ul><\/li><li><a href=\"#Reference_Architecture_VPN_Bastion_for_Hosting_Panels\"><span class=\"toc_number toc_depth_1\">3<\/span> Reference Architecture: VPN + Bastion for Hosting Panels<\/a><ul><li><a href=\"#Key_Components\"><span class=\"toc_number toc_depth_2\">3.1<\/span> Key Components<\/a><\/li><li><a href=\"#Traffic_Flow_Overview\"><span class=\"toc_number toc_depth_2\">3.2<\/span> Traffic Flow Overview<\/a><\/li><\/ul><\/li><li><a href=\"#Designing_Network_Segments_and_Firewall_Rules\"><span class=\"toc_number toc_depth_1\">4<\/span> Designing Network Segments and Firewall Rules<\/a><ul><li><a href=\"#Separate_Management_and_Production_Networks\"><span class=\"toc_number toc_depth_2\">4.1<\/span> Separate Management and Production Networks<\/a><\/li><li><a href=\"#Firewall_Policy_Blueprint\"><span class=\"toc_number toc_depth_2\">4.2<\/span> Firewall Policy Blueprint<\/a><\/li><\/ul><\/li><li><a href=\"#Implementing_the_VPN_Layer\"><span class=\"toc_number toc_depth_1\">5<\/span> Implementing the VPN Layer<\/a><ul><li><a href=\"#Choosing_a_VPN_Technology\"><span class=\"toc_number toc_depth_2\">5.1<\/span> Choosing a VPN Technology<\/a><\/li><li><a href=\"#User_Identity_and_MFA\"><span class=\"toc_number toc_depth_2\">5.2<\/span> User Identity and MFA<\/a><\/li><li><a href=\"#Split_Tunnel_vs_Full_Tunnel\"><span class=\"toc_number toc_depth_2\">5.3<\/span> Split Tunnel vs Full Tunnel<\/a><\/li><li><a href=\"#DNS_and_Internal_Names\"><span class=\"toc_number toc_depth_2\">5.4<\/span> DNS and Internal Names<\/a><\/li><\/ul><\/li><li><a href=\"#Building_the_Bastion_Host\"><span class=\"toc_number toc_depth_1\">6<\/span> Building the Bastion Host<\/a><ul><li><a href=\"#Base_Operating_System_and_Hardening\"><span class=\"toc_number toc_depth_2\">6.1<\/span> Base Operating System and Hardening<\/a><\/li><li><a href=\"#SSH_Key_Management_and_Access_Sharing\"><span class=\"toc_number toc_depth_2\">6.2<\/span> SSH Key Management and Access Sharing<\/a><\/li><li><a href=\"#How_the_Bastion_Exposes_Hosting_Panels\"><span class=\"toc_number toc_depth_2\">6.3<\/span> How the Bastion Exposes Hosting Panels<\/a><ul><li><a href=\"#1_SSH_Port_Forwarding_from_Admin_Devices\"><span class=\"toc_number toc_depth_3\">6.3.1<\/span> 1. SSH Port Forwarding from Admin Devices<\/a><\/li><li><a href=\"#2_Reverse_Proxy_on_the_Bastion_With_Strong_TLS_Controls\"><span class=\"toc_number toc_depth_3\">6.3.2<\/span> 2. Reverse Proxy on the Bastion (With Strong TLS Controls)<\/a><\/li><\/ul><\/li><li><a href=\"#Command_and_Session_Logging\"><span class=\"toc_number toc_depth_2\">6.4<\/span> Command and Session Logging<\/a><\/li><\/ul><\/li><li><a href=\"#Access_Workflows_for_SSH_Panels_and_Custom_Tools\"><span class=\"toc_number toc_depth_1\">7<\/span> Access Workflows for SSH, Panels and Custom Tools<\/a><ul><li><a href=\"#SSH_Access_to_VPS_and_Dedicated_Servers\"><span class=\"toc_number toc_depth_2\">7.1<\/span> SSH Access to VPS and Dedicated Servers<\/a><\/li><li><a href=\"#Access_to_cPanelWHM_Plesk_DirectAdmin\"><span class=\"toc_number toc_depth_2\">7.2<\/span> Access to cPanel\/WHM, Plesk, DirectAdmin<\/a><\/li><li><a href=\"#ThirdParty_Tools_and_Internal_Apps\"><span class=\"toc_number toc_depth_2\">7.3<\/span> Third\u2011Party Tools and Internal Apps<\/a><\/li><\/ul><\/li><li><a href=\"#Operational_Practices_Onboarding_Offboarding_and_Auditing\"><span class=\"toc_number toc_depth_1\">8<\/span> Operational Practices: Onboarding, Offboarding and Auditing<\/a><ul><li><a href=\"#Onboarding_a_New_Admin\"><span class=\"toc_number toc_depth_2\">8.1<\/span> Onboarding a New Admin<\/a><\/li><li><a href=\"#Offboarding_and_Access_Reviews\"><span class=\"toc_number toc_depth_2\">8.2<\/span> Offboarding and Access Reviews<\/a><\/li><li><a href=\"#Monitoring_and_Alerts\"><span class=\"toc_number toc_depth_2\">8.3<\/span> Monitoring and Alerts<\/a><\/li><\/ul><\/li><li><a href=\"#Choosing_Infrastructure_at_dchostcom_for_VPN_Bastion\"><span class=\"toc_number toc_depth_1\">9<\/span> Choosing Infrastructure at dchost.com for VPN + Bastion<\/a><\/li><li><a href=\"#Migration_Plan_From_Public_Panels_to_VPN_Bastion\"><span class=\"toc_number toc_depth_1\">10<\/span> Migration Plan: From Public Panels to VPN + Bastion<\/a><ul><li><a href=\"#Phase_1_Prepare_Infrastructure\"><span class=\"toc_number toc_depth_2\">10.1<\/span> Phase 1 \u2013 Prepare Infrastructure<\/a><\/li><li><a href=\"#Phase_2_Pilot_with_a_Small_Admin_Group\"><span class=\"toc_number toc_depth_2\">10.2<\/span> Phase 2 \u2013 Pilot with a Small Admin Group<\/a><\/li><li><a href=\"#Phase_3_Lock_Down_ServerSide_Access\"><span class=\"toc_number toc_depth_2\">10.3<\/span> Phase 3 \u2013 Lock Down Server\u2011Side Access<\/a><\/li><li><a href=\"#Phase_4_Close_Public_Panel_Access\"><span class=\"toc_number toc_depth_2\">10.4<\/span> Phase 4 \u2013 Close Public Panel Access<\/a><\/li><li><a href=\"#Phase_5_Review_Document_and_Automate\"><span class=\"toc_number toc_depth_2\">10.5<\/span> Phase 5 \u2013 Review, Document and Automate<\/a><\/li><\/ul><\/li><li><a href=\"#Summary_and_Next_Steps\"><span class=\"toc_number toc_depth_1\">11<\/span> Summary and Next Steps<\/a><\/li><\/ul><\/div>\n<h2><span id=\"Why_Direct_Internet_Access_to_Hosting_Panels_Is_Dangerous\">Why Direct Internet Access to Hosting Panels Is Dangerous<\/span><\/h2>\n<p>Leaving hosting panels and SSH ports open to the public internet looks convenient, but it creates a wide attack surface. Typical risks include:<\/p>\n<ul>\n<li><strong>Credential stuffing:<\/strong> Attackers try leaked email\/password pairs from other breaches against \/whm, \/cpanel, \/plesk or custom admin URLs.<\/li>\n<li><strong>Brute force and password spraying:<\/strong> Bots systematically guess weak passwords and target known usernames like <code>admin<\/code>, <code>root<\/code> or common email addresses.<\/li>\n<li><strong>Exploiting panel vulnerabilities:<\/strong> When a new cPanel, Plesk or web server exploit appears, scanners immediately start hitting every open port they can find.<\/li>\n<li><strong>Enumeration and reconnaissance:<\/strong> Even if login is blocked, response codes, error messages and banners can reveal software versions and internal structure.<\/li>\n<\/ul>\n<p>You can (and should) still harden the panels themselves\u2014rate limits, 2FA, IP allowlists and strong passwords. Our <a href=\"https:\/\/www.dchost.com\/blog\/en\/cpanel-guvenlik-sertlestirme-kontrol-listesi\/\">cPanel security hardening checklist<\/a> covers many of these measures on the panel side.<\/p>\n<p>But relying only on panel\u2011level protections means your most sensitive interfaces are still exposed to the whole internet. A stronger approach is to remove them from public reach entirely and require administrators to come in through a <strong>VPN and bastion host<\/strong> that you control and monitor.<\/p>\n<h2><span id=\"Core_Concepts_VPN_Bastion_Host_and_ZeroTrust_Access\">Core Concepts: VPN, Bastion Host and Zero\u2011Trust Access<\/span><\/h2>\n<h3><span id=\"Virtual_Private_Network_VPN\">Virtual Private Network (VPN)<\/span><\/h3>\n<p>A <strong>VPN<\/strong> creates an encrypted tunnel between an administrator\u2019s device (laptop, phone, tablet) and a private network. Once connected, the device receives an internal IP and can reach internal services as if it were on the office LAN.<\/p>\n<p>If you want a refresher on the basics and protocol types, we have a separate guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/sanal-ozel-ag-vpn-nedir-guvenli-internet-kullanimi-icin-onemi\/\">what a Virtual Private Network (VPN) is and why it matters<\/a>.<\/p>\n<h3><span id=\"Bastion_Host_Jump_Server\">Bastion Host (Jump Server)<\/span><\/h3>\n<p>A <strong>bastion host<\/strong> (or jump server) is a small, hardened server that acts as the single entry point into your infrastructure for administrative access:<\/p>\n<ul>\n<li>It is reachable only from the VPN network (not from the public internet directly).<\/li>\n<li>Admins SSH into the bastion, or access a web interface on it, and from there connect to internal servers or hosting panels.<\/li>\n<li>All admin activity can be logged and audited centrally.<\/li>\n<\/ul>\n<p>Instead of dozens of servers each having exposed SSH or panel ports, the bastion concentrates that risk into one machine you can lock down very aggressively.<\/p>\n<h3><span id=\"ZeroTrust_Approach_to_Admin_Access\">Zero\u2011Trust Approach to Admin Access<\/span><\/h3>\n<p>A <strong>zero\u2011trust<\/strong> model assumes no user, device or network segment is inherently trusted. Access is granted based on verified identity, device posture and least privilege, and it is re\u2011evaluated regularly.<\/p>\n<p>In the context of hosting panels, zero\u2011trust means:<\/p>\n<ul>\n<li>Panel URLs are not publicly reachable.<\/li>\n<li>Every admin must authenticate to the VPN (ideally with MFA) before even seeing those URLs.<\/li>\n<li>From the VPN, they reach a bastion host that enforces additional access control and logging.<\/li>\n<\/ul>\n<p>We have previously explored this in a broader context in our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/zero-trust-ile-hosting-ve-sunucu-erisimini-guvenceye-almak\/\">zero\u2011trust access to hosting panels and servers<\/a>. Here, we will focus specifically on the VPN + bastion pattern and how to implement it step by step.<\/p>\n<h2><span id=\"Reference_Architecture_VPN_Bastion_for_Hosting_Panels\">Reference Architecture: VPN + Bastion for Hosting Panels<\/span><\/h2>\n<p>Let\u2019s define a concrete reference architecture you can adapt to your environment.<\/p>\n<h3><span id=\"Key_Components\">Key Components<\/span><\/h3>\n<ul>\n<li><strong>Admin devices:<\/strong> Laptops or workstations of system administrators, developers, support staff and sometimes trusted external partners.<\/li>\n<li><strong>VPN gateway:<\/strong> A dedicated VPS or small cluster that terminates VPN tunnels (WireGuard, OpenVPN, IPsec) and assigns internal IPs to admins.<\/li>\n<li><strong>Bastion host:<\/strong> A hardened Linux server reachable from the VPN network; it exposes SSH and possibly a small internal web UI used to relay access to hosting panels.<\/li>\n<li><strong>Management subnet:<\/strong> A private network segment where the bastion and panel endpoints live.<\/li>\n<li><strong>Hosting panel servers:<\/strong> cPanel, DirectAdmin, Plesk, custom panels and plain VPS instances.<\/li>\n<li><strong>Central logging\/monitoring:<\/strong> Your log stack (e.g. ELK, Loki, or any SIEM) and metrics\/alerts platform.<\/li>\n<\/ul>\n<h3><span id=\"Traffic_Flow_Overview\">Traffic Flow Overview<\/span><\/h3>\n<ol>\n<li>Admin starts VPN client, authenticates (user + password + MFA or certificate) and receives an internal IP address (for example, 10.20.10.25).<\/li>\n<li>Firewall rules on the VPN gateway allow this VPN subnet to reach only the bastion IP and perhaps a few internal services (DNS, monitoring dashboards).<\/li>\n<li>Admin opens SSH to bastion (for example, <code>ssh admin@10.20.0.10<\/code>) or opens a browser to an internal URL on the bastion (for example, <code>https:\/\/bastion.internal<\/code>).<\/li>\n<li>From the bastion, the admin connects to target servers over SSH or HTTP\/HTTPS (for example, <code>https:\/\/cpanel01.internal:2087<\/code>).<\/li>\n<li>All steps are logged: VPN login, SSH login to bastion, commands run, and connections initiated from bastion to target servers.<\/li>\n<\/ol>\n<p>The core idea is that the <strong>only<\/strong> machines allowed to reach hosting panels on their admin ports (2083\/2087 for cPanel, 8443 for Plesk, 2222 for DirectAdmin, 22 for SSH, etc.) are:<\/p>\n<ul>\n<li>the bastion host(s)<\/li>\n<li>and possibly a very small set of emergency IPs (for example, an on\u2011premise NOC range)<\/li>\n<\/ul>\n<h2><span id=\"Designing_Network_Segments_and_Firewall_Rules\">Designing Network Segments and Firewall Rules<\/span><\/h2>\n<h3><span id=\"Separate_Management_and_Production_Networks\">Separate Management and Production Networks<\/span><\/h3>\n<p>A clean design separates traffic into multiple segments:<\/p>\n<ul>\n<li><strong>VPN subnet:<\/strong> IP range assigned to admin devices when they connect to the VPN (for example, 10.20.10.0\/24).<\/li>\n<li><strong>Management subnet:<\/strong> Contains bastion and panel admin interfaces (for example, 10.20.0.0\/24).<\/li>\n<li><strong>Public\/DMZ subnet:<\/strong> Production web servers, load balancers and reverse proxies that face the internet.<\/li>\n<\/ul>\n<p>You can implement these as separate VLANs in colocation, as isolated networks on dedicated servers, or via virtual networks on VPS infrastructure at dchost.com.<\/p>\n<h3><span id=\"Firewall_Policy_Blueprint\">Firewall Policy Blueprint<\/span><\/h3>\n<p>At a high level, firewall rules should implement the following policy:<\/p>\n<ul>\n<li><strong>From internet to hosting panels:<\/strong> Block all direct access to panel ports (2083\/2087\/8443\/2222\/WHMCS\u2011like ports, SSH, RDP, etc.). Only allow HTTP\/HTTPS to the public web frontends.<\/li>\n<li><strong>From VPN subnet to bastion:<\/strong> Allow SSH (22) and HTTPS (if your bastion provides an internal web UI or reverse proxy for panels). Deny everything else by default.<\/li>\n<li><strong>From bastion to management subnet:<\/strong> Allow SSH and specific panel ports to the relevant servers. Still apply least privilege (for example, only allow bastion to reach <code>cpanel01<\/code> on 22\/2087, not every port).<\/li>\n<li><strong>From VPN subnet to management subnet directly:<\/strong> Block or at least heavily restrict; ideally, all access to management subnet goes through the bastion.<\/li>\n<\/ul>\n<p>If you are building this on a VPS, tools like <code>ufw<\/code>, <code>firewalld<\/code> or raw <code>iptables\/nftables<\/code> work well. Our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/vps-sunucularda-guvenlik-duvari-yapilandirma-ufw-firewalld-ve-iptables\/\">firewall configuration on VPS servers<\/a> walks through practical examples for each option.<\/p>\n<h2><span id=\"Implementing_the_VPN_Layer\">Implementing the VPN Layer<\/span><\/h2>\n<h3><span id=\"Choosing_a_VPN_Technology\">Choosing a VPN Technology<\/span><\/h3>\n<p>For admin access, you typically want:<\/p>\n<ul>\n<li><strong>Strong encryption<\/strong> and modern ciphers.<\/li>\n<li><strong>Per\u2011user identities<\/strong> (keys or accounts) for clean revocation and logging.<\/li>\n<li><strong>Stable clients<\/strong> for Windows, macOS, Linux and often mobile.<\/li>\n<\/ul>\n<p>Popular choices include:<\/p>\n<ul>\n<li><strong>WireGuard:<\/strong> Modern, fast, simple configuration, great for per\u2011device keys.<\/li>\n<li><strong>OpenVPN:<\/strong> Mature, widely supported, flexible but more complex.<\/li>\n<li><strong>IPsec\/IKEv2:<\/strong> Often built into OS clients; good for site\u2011to\u2011site and device VPN.<\/li>\n<\/ul>\n<p>From a hosting\u2011team perspective, WireGuard is often a great starting point: small config files per admin, good performance and minimal overhead on a VPS or dedicated server.<\/p>\n<h3><span id=\"User_Identity_and_MFA\">User Identity and MFA<\/span><\/h3>\n<p>A VPN user should not be just \u201csome laptop with a key file\u201d. You want to tie access to a real person and enforce strong authentication:<\/p>\n<ul>\n<li>Issue <strong>unique keys\/certificates per user and per device<\/strong>.<\/li>\n<li>Use MFA on a separate portal or identity provider if your VPN supports it.<\/li>\n<li>Document which VPN identities correspond to which people and which teams.<\/li>\n<\/ul>\n<p>When an employee leaves or a contractor\u2019s engagement ends, you revoke their VPN access first, then their bastion and panel accounts. A clean identity map makes this fast and auditable.<\/p>\n<h3><span id=\"Split_Tunnel_vs_Full_Tunnel\">Split Tunnel vs Full Tunnel<\/span><\/h3>\n<p>You must decide whether the VPN will route <strong>all<\/strong> traffic from the admin device, or only traffic destined for internal subnets:<\/p>\n<ul>\n<li><strong>Split tunnel:<\/strong> Only internal IP ranges (for example, 10.20.0.0\/16) go through the VPN; internet browsing goes out locally.<\/li>\n<li><strong>Full tunnel:<\/strong> All traffic, including web browsing, goes through your VPN and exits via your data center.<\/li>\n<\/ul>\n<p>For most hosting teams, a split tunnel is enough if the VPN is used purely for administrative access. If you have strict regulatory or logging requirements, a full tunnel may be preferable so that admin web traffic while \u201con duty\u201d is also monitored.<\/p>\n<h3><span id=\"DNS_and_Internal_Names\">DNS and Internal Names<\/span><\/h3>\n<p>Inside the VPN, use an internal DNS zone such as <code>*.internal<\/code> or <code>*.corp<\/code> (not a public TLD you own) for management endpoints:<\/p>\n<ul>\n<li><code>bastion.internal<\/code> &rarr; 10.20.0.10<\/li>\n<li><code>cpanel01.internal<\/code> &rarr; 10.20.0.101<\/li>\n<li><code>plesk01.internal<\/code> &rarr; 10.20.0.102<\/li>\n<\/ul>\n<p>This keeps admin URLs distinct from public domains and gives you flexibility in renaming or moving services without changing bookmarks on every admin\u2019s laptop.<\/p>\n<h2><span id=\"Building_the_Bastion_Host\">Building the Bastion Host<\/span><\/h2>\n<h3><span id=\"Base_Operating_System_and_Hardening\">Base Operating System and Hardening<\/span><\/h3>\n<p>Use a lean, long\u2011term\u2011support Linux distribution (for example, Debian or AlmaLinux) as the base for your bastion. Apply hardening practices similar to any critical VPS:<\/p>\n<ul>\n<li>Disable direct root SSH login; use <code>sudo<\/code> and per\u2011user accounts.<\/li>\n<li>Require SSH keys and disable password authentication.<\/li>\n<li>Restrict SSH to VPN subnet IPs.<\/li>\n<li>Apply automatic security updates and reboot policies.<\/li>\n<li>Deploy Fail2ban or similar to react to suspicious login attempts, even from within the VPN.<\/li>\n<\/ul>\n<p>Our <a href=\"https:\/\/www.dchost.com\/blog\/en\/vps-guvenlik-sertlestirme-kontrol-listesi-sshd_config-fail2ban-ve-root-erisimini-kapatmak\/\">VPS security hardening checklist<\/a> provides a practical baseline you can apply almost as\u2011is to your bastion host.<\/p>\n<h3><span id=\"SSH_Key_Management_and_Access_Sharing\">SSH Key Management and Access Sharing<\/span><\/h3>\n<p>The bastion is where SSH access should be most carefully managed. Instead of sharing one key or one user, every admin gets:<\/p>\n<ul>\n<li>a unique Unix user on the bastion (<code>alice<\/code>, <code>bob<\/code>, <code>support01<\/code>)<\/li>\n<li>a unique SSH key, stored in version\u2011controlled infrastructure code or an internal directory<\/li>\n<\/ul>\n<p>This makes it easy to rotate keys, revoke old ones and see who did what. For more detail on safe SSH workflows, see our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/ssh-anahtar-yonetimi-ve-yetki-paylasimi-kucuk-ekipler-icin-guvenli-vps-erisimi\/\">SSH key management and access sharing<\/a>.<\/p>\n<h3><span id=\"How_the_Bastion_Exposes_Hosting_Panels\">How the Bastion Exposes Hosting Panels<\/span><\/h3>\n<p>You have two main options to give admins access to panel UIs via the bastion:<\/p>\n<h4><span id=\"1_SSH_Port_Forwarding_from_Admin_Devices\">1. SSH Port Forwarding from Admin Devices<\/span><\/h4>\n<p>Admins establish SSH tunnels from their laptops to the bastion, which forwards traffic to panel ports:<\/p>\n<ul>\n<li>Example: <code>ssh -L 8443:cpanel01.internal:2087 alice@bastion.internal<\/code><\/li>\n<li>Then open <code>https:\/\/localhost:8443<\/code> on the laptop browser to reach WHM on <code>cpanel01.internal<\/code>.<\/li>\n<\/ul>\n<p>Pros:<\/p>\n<ul>\n<li>No additional web app on the bastion.<\/li>\n<li>Works well with existing SSH tooling and keys.<\/li>\n<\/ul>\n<p>Cons:<\/p>\n<ul>\n<li>Less user\u2011friendly for non\u2011technical staff.<\/li>\n<li>Multiple tunnels can get messy when managing many servers.<\/li>\n<\/ul>\n<h4><span id=\"2_Reverse_Proxy_on_the_Bastion_With_Strong_TLS_Controls\">2. Reverse Proxy on the Bastion (With Strong TLS Controls)<\/span><\/h4>\n<p>Alternatively, you can run Nginx or Caddy on the bastion and expose a small internal portal (for example, <code>https:\/\/panels.internal\/<\/code>) which reverse\u2011proxies to the actual panel endpoints. In this model:<\/p>\n<ul>\n<li>Admins browse to a single internal URL after connecting to the VPN.<\/li>\n<li>The bastion, acting as a reverse proxy, connects to <code>cpanel01.internal:2087<\/code>, <code>plesk01.internal:8443<\/code>, etc.<\/li>\n<\/ul>\n<p>If you go this route, you should protect the reverse proxy itself extremely well, ideally with <strong>mutual TLS (mTLS)<\/strong> so that only clients with a valid certificate can talk to it at all. We describe this in detail in our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/yonetim-panellerini-mtls-ile-nasil-kale-gibi-korursun-nginxte-istemci-sertifikalari-adim-adim\/\">protecting admin panels with mTLS on Nginx<\/a>.<\/p>\n<h3><span id=\"Command_and_Session_Logging\">Command and Session Logging<\/span><\/h3>\n<p>Because bastion hosts are choke points, they are a perfect place to collect logs:<\/p>\n<ul>\n<li>Record <strong>who connected when<\/strong> (SSH logins, VPN user identity in metadata).<\/li>\n<li>Use <code>auditd<\/code> or advanced shells (or even session recording tools) to log critical commands.<\/li>\n<li>Ship logs to a centralized system (ELK, Loki, etc.) with long enough retention to support investigations and compliance.<\/li>\n<\/ul>\n<p>If you already centralize logs from multiple VPS instances (for example, using Loki + Grafana as we describe in our <a href=\"https:\/\/www.dchost.com\/blog\/en\/birden-fazla-sunucuda-log-yonetimi-elk-ve-loki-stack-ile-merkezi-hosting-loglama\/\">centralized log management guide<\/a>), just add the bastion as another log source and tag its events clearly.<\/p>\n<h2><span id=\"Access_Workflows_for_SSH_Panels_and_Custom_Tools\">Access Workflows for SSH, Panels and Custom Tools<\/span><\/h2>\n<h3><span id=\"SSH_Access_to_VPS_and_Dedicated_Servers\">SSH Access to VPS and Dedicated Servers<\/span><\/h3>\n<p>A clean SSH workflow looks like this:<\/p>\n<ol>\n<li>Admin connects to VPN, receives internal IP.<\/li>\n<li>Admin SSHes into bastion: <code>ssh alice@bastion.internal<\/code>.<\/li>\n<li>From bastion, admin uses either:<\/li>\n<\/ol>\n<ul>\n<li><strong>Per\u2011user keys on target servers:<\/strong> <code>ssh root@cpanel01.internal<\/code>, but keys are centrally managed on bastion.<\/li>\n<li><strong>SSH agent forwarding<\/strong> (if policy allows) so bastion does not store private keys itself.<\/li>\n<\/ul>\n<p>For small teams, you can enforce that all production SSH must originate from the bastion, not from random admin IPs, by firewalling servers to allow SSH only from the bastion\u2019s IP.<\/p>\n<h3><span id=\"Access_to_cPanelWHM_Plesk_DirectAdmin\">Access to cPanel\/WHM, Plesk, DirectAdmin<\/span><\/h3>\n<p>Once VPN and bastion are in place, classic panel URLs become internal\u2011only:<\/p>\n<ul>\n<li><code>https:\/\/cpanel01.internal:2087<\/code> (WHM)<\/li>\n<li><code>https:\/\/plesk01.internal:8443<\/code><\/li>\n<li><code>https:\/\/da01.internal:2222<\/code><\/li>\n<\/ul>\n<p>Admins reach them via:<\/p>\n<ul>\n<li>SSH port forwarding from local browser (for power users).<\/li>\n<li>Internal reverse proxy portal with mTLS (for larger teams and mixed skill levels).<\/li>\n<\/ul>\n<p>You still keep panel\u2011level controls\u2014strong passwords, 2FA, IP restrictions on the panel if supported\u2014but the biggest change is that <strong>attackers on the open internet cannot even see the login pages<\/strong>.<\/p>\n<h3><span id=\"ThirdParty_Tools_and_Internal_Apps\">Third\u2011Party Tools and Internal Apps<\/span><\/h3>\n<p>The same bastion and VPN used for hosting panels can safely expose:<\/p>\n<ul>\n<li>Monitoring dashboards.<\/li>\n<li>Internal Git or CI\/CD interfaces.<\/li>\n<li>Custom support\/admin tools.<\/li>\n<\/ul>\n<p>Just ensure your firewall rules and reverse proxy configuration define which apps are reachable from which user groups. If some tools are more sensitive (billing, full client data exports), consider separate bastions or stricter mTLS profiles.<\/p>\n<h2><span id=\"Operational_Practices_Onboarding_Offboarding_and_Auditing\">Operational Practices: Onboarding, Offboarding and Auditing<\/span><\/h2>\n<h3><span id=\"Onboarding_a_New_Admin\">Onboarding a New Admin<\/span><\/h3>\n<p>A secure and smooth onboarding process might follow this order:<\/p>\n<ol>\n<li>Create an identity in your directory or internal admin list.<\/li>\n<li>Issue VPN credentials\/keys for that person and register their devices.<\/li>\n<li>Create a bastion Unix user with SSH key and appropriate groups (for example, \u201csupport\u201d, \u201cdevops\u201d).<\/li>\n<li>Grant access on specific hosting panels according to role (read\u2011only vs full admin).<\/li>\n<\/ol>\n<p>By centralizing the first steps on VPN + bastion, you avoid sending direct cPanel or root credentials via email or chat.<\/p>\n<h3><span id=\"Offboarding_and_Access_Reviews\">Offboarding and Access Reviews<\/span><\/h3>\n<p>When someone leaves or changes role:<\/p>\n<ul>\n<li>Revoke VPN access (keys, certificates, accounts).<\/li>\n<li>Lock or remove their bastion user.<\/li>\n<li>Rotate any shared panel credentials they might have used.<\/li>\n<li>Review logs from their last weeks for unusual access patterns.<\/li>\n<\/ul>\n<p>Quarterly access reviews\u2014who has VPN, who has bastion accounts, who has panel admin rights\u2014help catch privilege creep before it becomes a risk.<\/p>\n<h3><span id=\"Monitoring_and_Alerts\">Monitoring and Alerts<\/span><\/h3>\n<p>Because all flows pass through VPN and bastion, you get powerful detection signals:<\/p>\n<ul>\n<li>Alert on <strong>VPN logins from unusual countries<\/strong> or at odd hours for the user.<\/li>\n<li>Alert on <strong>multiple failed SSH attempts<\/strong> on the bastion, even from the VPN subnet.<\/li>\n<li>Track <strong>panel logins<\/strong> from the bastion IP and correlate with bastion user sessions.<\/li>\n<\/ul>\n<p>If you are already using centralized metrics and alerts for VPS nodes (for example, Prometheus + Grafana\u2014see our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/merkezi-sunucu-izleme-ve-alarm-mimarisi\/\">centralized server monitoring and alerting<\/a>), treat the VPN gateway and bastion as top\u2011tier monitored services.<\/p>\n<h2><span id=\"Choosing_Infrastructure_at_dchostcom_for_VPN_Bastion\">Choosing Infrastructure at dchost.com for VPN + Bastion<\/span><\/h2>\n<p>From an infrastructure perspective, this architecture is lightweight:<\/p>\n<ul>\n<li><strong>VPN gateway:<\/strong> A small VPS with adequate CPU for encryption and a public IP.<\/li>\n<li><strong>Bastion host:<\/strong> Another small VPS (or shared with VPN for very small setups, though we prefer separating them).<\/li>\n<li><strong>Panel servers:<\/strong> Existing shared hosting, VPS, dedicated or colocation servers where your sites already live.<\/li>\n<\/ul>\n<p>On dchost.com you can:<\/p>\n<ul>\n<li>Use a <strong>VPS<\/strong> as VPN gateway and bastion for flexible routing and firewalling.<\/li>\n<li>Put <strong>high\u2011value production sites<\/strong> on dedicated servers or colocation and connect them to the same private management network.<\/li>\n<li>Keep smaller or low\u2011risk sites on shared hosting, but still restrict cPanel\/DirectAdmin access behind VPN where possible.<\/li>\n<\/ul>\n<p>If you are unsure how many vCPUs or how much RAM you need for a VPN\/bastion combo versus your web workloads, our resource planning guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/woocommerce-laravel-ve-node-jsde-dogru-vps-kaynaklarini-nasil-secersin-cpu-ram-nvme-ve-bant-genisligi-rehberi\/\">choosing VPS specs for WooCommerce, Laravel and Node.js<\/a> gives you a practical way to size VPS instances by load profile.<\/p>\n<h2><span id=\"Migration_Plan_From_Public_Panels_to_VPN_Bastion\">Migration Plan: From Public Panels to VPN + Bastion<\/span><\/h2>\n<p>Moving to this architecture does not need to be disruptive. A staged approach works well:<\/p>\n<h3><span id=\"Phase_1_Prepare_Infrastructure\">Phase 1 \u2013 Prepare Infrastructure<\/span><\/h3>\n<ul>\n<li>Deploy VPN gateway VPS and test connectivity from a few admin devices.<\/li>\n<li>Deploy bastion VPS, harden SSH, integrate with your logging stack.<\/li>\n<li>Create internal DNS names for bastion and panel servers.<\/li>\n<\/ul>\n<h3><span id=\"Phase_2_Pilot_with_a_Small_Admin_Group\">Phase 2 \u2013 Pilot with a Small Admin Group<\/span><\/h3>\n<ul>\n<li>Onboard 1\u20133 admins to the new flow (VPN \u2192 bastion \u2192 panels).<\/li>\n<li>Keep public panel access open but <strong>start using the VPN path by policy<\/strong>.<\/li>\n<li>Gather feedback: is SSH port forwarding enough, or do you need a reverse proxy portal?<\/li>\n<\/ul>\n<h3><span id=\"Phase_3_Lock_Down_ServerSide_Access\">Phase 3 \u2013 Lock Down Server\u2011Side Access<\/span><\/h3>\n<ul>\n<li>Restrict SSH on panel servers to accept connections only from bastion IPs.<\/li>\n<li>Restrict panel admin ports (2083\/2087\/8443 etc.) to bastion IPs via host firewall or security groups.<\/li>\n<li>Keep a short \u201cbreak glass\u201d rule for a known static IP if needed (for example, office IP).<\/li>\n<\/ul>\n<h3><span id=\"Phase_4_Close_Public_Panel_Access\">Phase 4 \u2013 Close Public Panel Access<\/span><\/h3>\n<ul>\n<li>Remove public DNS records pointing to panel ports.<\/li>\n<li>Verify that panel logins only appear from bastion IP.<\/li>\n<li>Communicate to all admins and vendors that <strong>VPN + bastion is now mandatory<\/strong>.<\/li>\n<\/ul>\n<h3><span id=\"Phase_5_Review_Document_and_Automate\">Phase 5 \u2013 Review, Document and Automate<\/span><\/h3>\n<ul>\n<li>Write a short runbook: \u201cHow to access production panels safely.\u201d<\/li>\n<li>Automate VPN account creation and bastion user setup via scripts or Ansible\/Terraform.<\/li>\n<li>Schedule quarterly reviews of VPN users, bastion accounts and panel admin rights.<\/li>\n<\/ul>\n<p>If you maintain multiple environments (dev, staging, production), you can adopt the same pattern at different strictness levels. We discuss environment separation options in our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/gelistirme-test-ve-canli-ortamlar-icin-hosting-mimarisi\/\">hosting architecture for development, staging and production<\/a>.<\/p>\n<h2><span id=\"Summary_and_Next_Steps\">Summary and Next Steps<\/span><\/h2>\n<p>Exposing hosting panels and SSH ports directly to the internet is no longer a tolerable risk for serious projects. Automated scans, password reuse and panel\u2011specific exploits mean that \u201chidden\u201d URLs and \u201cstrong enough\u201d passwords will eventually be tested. A <strong>VPN + bastion host<\/strong> architecture shrinks that attack surface dramatically: admins must authenticate into your private network first, then reach hosting panels through a small, hardened jump point you fully control, monitor and log.<\/p>\n<p>The practical steps are straightforward: deploy a VPN gateway on a dchost.com VPS, add a bastion host with strict SSH key management, rewire firewall rules so only bastion can reach admin ports, and gradually move teams from public URLs to the new flow. Combine this with panel\u2011side hardening, proper backup and a basic zero\u2011trust mindset, and your hosting stack becomes much harder to compromise\u2014without making daily operations painful.<\/p>\n<p>If you would like help choosing the right mix of shared hosting, VPS, dedicated servers or colocation to implement this architecture, our team at dchost.com can review your current setup and propose a realistic plan. Start by mapping which panels you have today, who uses them and from where, then design your first VPN + bastion prototype. With a few careful steps, remote access to your hosting panels can go from \u201calways a worry\u201d to \u201cjust another well\u2011managed service\u201d.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>When you manage multiple cPanel, DirectAdmin, Plesk or custom hosting panels across VPS, dedicated servers or colocation, the real challenge is not just performance\u2014it is how people log in. Exposed admin URLs, shared passwords and open SSH ports are still the default in many teams, even though automated scans and credential stuffing attacks target these [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":4978,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-4977","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-teknoloji"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/4977","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=4977"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/4977\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/4978"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=4977"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=4977"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=4977"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}