Open Proxy Ports
To set up open proxy ports, you allow inbound network traffic through your firewall rules. Teams bind a listening service to a specific TCP port to forward client requests. Many engineering teams open these ports so remote developers can reach internal databases and servers. When teams make firewall rules or user roles too broad, anyone on the network can reach sensitive systems. A shared role lets any user run high-risk commands on production data. How to set up open proxy ports in your netwo
Database Proxy (ProxySQL, PgBouncer) + Open Policy Agent (OPA): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
To set up open proxy ports, you allow inbound network traffic through your firewall rules. Teams bind a listening service to a specific TCP port to forward client requests. Many engineering teams open these ports so remote developers can reach internal databases and servers. When teams make firewall rules or user roles too broad, anyone on the network can reach sensitive systems. A shared role lets any user run high-risk commands on production data.
How to set up open proxy ports in your network
Setting up a forwarding port starts at the network edge. An admin picks an unused port number on a routing server. Next, the admin updates the cloud security group or host firewall. This rule allows inbound packets from specific IP ranges to reach that port. The admin then starts a forwarding service that listens on that exact network socket.
When a developer sends a request, the packet hits the listening port first. The service reads the destination address and sends the traffic to the internal database or server. Teams often pair this port setup with basic user roles on the destination host. The firewall checks the source IP address before it lets the packet through. Then the target database checks the username and password before it starts a session.
Why network port rules are not enough
Firewall rules and port forwards solve the basic routing problem. They let remote apps and engineers reach private subnets without making every server public. A strict IP allowlist blocks random bots from scanning your internal database ports. Native user roles also stop unauthenticated users from logging in to the server.
Still, port rules only decide where packets can go and who can log in. Once a session starts, an open port does not inspect what individual queries or commands do in flight. If an engineer logs in with a broad role, they can still drop a table by mistake. They can also read millions of customer rows in a single query. Standard port forwarding also leaves raw emails, phone numbers, and card numbers exposed in query results. Also, network logs only show packet counts and IP addresses, not the exact SQL statements or shell commands run.
Database Proxy (ProxySQL, PgBouncer) + Open Policy Agent (OPA): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Managing credentials and exposed ports
Keeping ports open on public IP addresses creates constant maintenance work for your team. Developer home IP addresses change often, so admins must update firewall rules every week. When teams get tired of updating IP rules, they often open the port to the whole internet. Attackers scan for these open ports day and night to test stolen passwords.
Sharing static database keys across a team makes this problem much worse. If one laptop gets compromised, the attacker has both the open port and the valid key. Revoking that shared key breaks scripts and blocks other engineers from doing their daily work. Teams need a way to control each command and protect sensitive fields without managing static keys or public ports.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
What happens if you leave forwarding ports open to the internet?
Automated bots will find the port within minutes and run brute-force login attacks. If a user has a weak password or leaked key, attackers can enter your internal network.
Do firewall port rules log database queries or shell commands?
No, network firewalls only log source IP addresses, destination ports, and byte counts. They cannot read encrypted database queries or record the specific commands a user runs inside a session.
Can native port forwarding hide sensitive data in query results?
No, standard port forwarding moves raw network packets back and forth without changing the payload. Any emails, phone numbers, or card numbers in the database response arrive in plain text on the client machine.