Secure Configuration for Remote Operations Access: Minimizing Exposure and Access Control

The convenience and risk of remote operations access go hand in hand: the larger the entry point opened for convenience, the greater the exposure surface. The reasonable approach is not “open or closed,” but rather narrowing the entry so that only authorized personnel can access it.

This article discusses several common remote access methods and how to minimize the exposure surface, tailored for enterprise intranet operations scenarios.

First, Clarify: Who Needs Access to What

Core Principle: Only expose what is strictly necessary on the public internet. Databases, caches, and admin panels should never be directly exposed.

I. Minimal Exposure Configuration for SSH

# /etc/ssh/sshd_config
Port 22                          # Or change port (reduces noise, but isn't a security measure)
PermitRootLogin no               # Disable direct root login
PasswordAuthentication no        # Use key authentication only
PubkeyAuthentication yes
AllowUsers ops                   # Allow only specified users

# Verify configuration (mandatory after changes)
sshd -t
systemctl reload sshd

# Restrict source IPs via Security Group/Firewall (The most critical step)
firewall-cmd --permanent --add-rich-rule=
'rule family="ipv4" source address="Your_Egress_IP" port protocol="tcp" port="22" accept'
firewall-cmd --reload

Restricting source IPs is far more effective than changing ports. Changing ports merely reduces the probability of being scanned; restricting sources prevents scanners from establishing connections entirely.

Handling Egress IP Changes

The practical difficulty with restricting source IPs is that home broadband egress IPs often change. Solutions include:

• Allowing a smaller subnet (rather than a single IP)
• Maintaining a fixed “jump host” (bastion host), connecting to the target via the jump host first

# Jump Host Method: Add only the Jump Host IP to the whitelist
# Connection method
ssh -J ops@JumpHost ops@TargetMachine
# Or configure ~/.ssh/config for simplification

# ~/.ssh/config
Host target
    HostName Target_Intranet_IP
    User ops
    ProxyJump ops@JumpHost_Public_IP

II. Using SSH Tunnels for Intranet Service Access

When accessing internal databases or admin panels, there is no need to expose ports; simply use an SSH tunnel to map the remote port to your local machine.

# Local Port Forwarding: Map remote 3306 to local 13306
ssh -L 13306:127.0.0.1:3306 ops@ServerIP -N

# Then connect locally (as if connecting to a local database)
mysql -h 127.0.0.1 -P 13306 -u user -p

# Dynamic Forwarding (SOCKS proxy, allows access to multiple intranet services)
ssh -D 1080 ops@ServerIP -N
# Configure browser or tools to use SOCKS proxy 127.0.0.1:1080

Advantage of Tunnels: Intranet services do not need to expose any public ports. Port 3306 listens only on 127.0.0.1 and is accessed via an authenticated SSH channel.

# Configuration: Database listens only on localhost
grep bind-address /etc/my.cnf
# bind-address = 127.0.0.1

III. VPN (For Multi-Server Scenarios)

When managing many servers or allowing multiple users to access, VPNs are easier to manage than configuring whitelists one by one.

# WireGuard Brief Workflow
yum install -y wireguard-tools

# Generate key pair
wg genkey | tee privatekey | wg pubkey > publickey

# Configure /etc/wireguard/wg0.conf (one copy for server, one for client)
# Start
wg-quick up wg0
systemctl enable wg-quick@wg0

# Server Example (Simplified)
[Interface]
Address = 10.0.0.1/24
PrivateKey = Server_Private_Key
ListenPort = 51820

[Peer]
PublicKey = Client_Public_Key
AllowedIPs = 10.0.0.2/32

# Allow VPN port (UDP)
firewall-cmd --permanent --add-port=51820/udp
firewall-cmd --reload

# Check connection status
wg show

Security Essentials for VPN Deployment

• One peer per client (Do not share keys; this allows individual revocation)
• Server port should only allow necessary sources (or at least not expose management capabilities)
• Disable client connections when not in use
• Regularly check the peer list and remove unused entries

# View currently connected peers and last handshake time
wg show
# If 'last handshake' was a long time ago, that peer is likely no longer in use

IV. Handling Temporary Allowances

# Temporarily allow a port (Must be closed after use)
firewall-cmd --add-port=8080/tcp      # Do NOT add --permanent; it expires on reboot
# Or set a timer to close it automatically

# Confirm current allowances
firewall-cmd --list-all

Temporary rules easily become long-term leftovers. The recommended practice is to omit --permanent, so they automatically expire after a reboot, preventing them from being forgotten.

Decision Tree

Remote Access Solution
├─ Managing only 1-2 servers
│  ├─ SSH: Disable root + Disable password + Restrict source IP
│  └─ Access intranet services via SSH tunnels (do not expose ports)
├─ Egress IP changes frequently
│  ├─ Allow a smaller subnet, or
│  └─ Use a Jump Host (ProxyJump)
├─ Many servers / Multiple users
│  └─ VPN (WireGuard recommended)
│     ├─ One peer per person for easy individual revocation
│     └─ Regularly check and clean up unused peers
└─ Temporary needs
   └─ Temporary allowance without --permanent; auto-expires on reboot

Scenario Simulation: Opening Remote Ports to the Entire Internet for Convenience, Targeted After Three Days

Symptoms: To conveniently handle issues from anywhere,
you opened the remote login port to all sources and retained password authentication.
A few days later, logs show numerous failed attempts, and unfamiliar accounts are found added.

1. First, confirm if you have been breached →
   Check successful login records, new accounts, and authorized keys.
   This step determines whether subsequent actions are cleanup or hardening.
2. Stop the bleeding: Minimize exposure immediately →
   Disable password authentication and allow only confirmed necessary source addresses.
3. Clean up what has already been written → Remove unfamiliar accounts and authorized keys,
   and check crontabs for any implanted persistence mechanisms.
4. Shift to “Default Deny” instead of “Default Allow” →
   Only allow confirmed necessary source ranges; deny everything else. This is a mindset shift, more important than adding a few rules.
5. Rein in middleware management ports as well →
   Services like databases and caches should also not face the public internet; they are often overlooked.
6. Verify both allowed and denied sources work correctly →
   Confirm access from allowed sources and denial from disallowed sources.

# Check for breaches
last -10
awk -F: '$3>=1000 && $7 !~ /nologin|false/ {print $1,$3,$7}' /etc/passwd
cat ~/.ssh/authorized_keys | wc -l

# Tighten: Disable password, restrict sources
grep -E '^(PasswordAuthentication|PermitRootLogin|PubkeyAuthentication)' /etc/ssh/sshd_config
# PasswordAuthentication no
systemctl reload sshd

# Middleware should also not be external (Check listening addresses)
ss -lntp | grep -E '6379|3306|27017'

# Default Deny Mindset
firewall-cmd --list-all 2>/dev/null | head -20

Root Cause: Prioritizing “convenience” over “minimal exposure.”
Opening to the entire internet and allowing password authentication is equivalent to leaving it to endless brute-force attempts to determine if you can be breached.

Two Key Takeaways:

• Access control should be designed based on “Default Deny,” not “Default Allow.”
  The latter means remembering to tighten every time a new service is added; forgetting leads to exposure.
• Middleware management ports are just as critical as remote login ports.
  Databases and caches assume intranet use by default; once listening on a public-facing address, they are effectively public.

8 Common Pitfalls

1. Exposing 3306/6379 to the public internet: A primary intrusion vector.
2. Believing changing ports ensures security: Source IP restriction is what actually works.
3. Adding --permanent to temporary rules: Turns them into long-term leftovers.
4. Multiple people sharing one VPN key: Prevents individual revocation.
5. Failing to clean up unused peers: Permissions remain active indefinitely.
6. Allowing direct root login: Excessive privileges and untraceable actions.
7. Using password login: Should switch to key-based authentication.
8. Not checking the allowance list: Legacy rules go unnoticed.

Real Customer Feedback (From Cloud Market Reviews and Consultations for Similar Products)

The following excerpts are taken from real buyer reviews and consultations for similar operations services on Alibaba Cloud / Tencent Cloud / Huawei Cloud Cloud Markets (service providers include our store and competitors, provided solely for reference of real feedback, not fictional tickets from this site):

10***77 2022-09-19 5.0 Affordable Price | Skilled Tech | Patient & Professional Received ICP filing rectification notice, found this service exactly when needed, handled quickly 10***49 2022-04-12 5.0 On-time Delivery | Affordable Price | Skilled Tech Needed rectification, fast configuration, good

b****4 Rating: 5.0 Points 2025-06-23 16:57 b****4 Rating: 5.0 Points 2025-06-23 16:56 Jian****Wei Rating: 5.0 Points 2021-01-20 15:03 Technology is awesome! Speed is very fast! It turned out to be a Trojan causing Baidu global hijacking!!!! 1 f****u Rating: 5.0 Points 2021-01-02 20:43 Thanks for assisting in maintaining Yuncai’s normal operation. 1****1 Rating: 5.0 Points 2020-11-20 10:03 Consistently good service 1****1 Rating: 5.0 Points 2020-11-17 09:13 Thanks for the consistently good service. 1****1 Rating: 5.0 Points 2020-09-25 15:42 Very much appreciated. 1****1 Rating: 5.0 Points 2020-08-24 15:34 Sincerely thank your company’s technical staff 1****1 Rating: 5.0 Points 2020-07-24 09:49 Sincerely thank you! 1