Ports SQL
You set up ports sql rules by binding your database listener to one TCP port. Then you restrict that port in your network firewall so only trusted hosts can talk. Most engineering teams start by opening the default database port to an internal subnet. When network rules or database roles are too broad, anyone on the subnet can query sensitive tables. A safe setup needs both tight network rules and strict query controls. How ports sql listeners and network rules work Every relational database
SQL Query Filtering: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up ports sql rules by binding your database listener to one TCP port. Then you restrict that port in your network firewall so only trusted hosts can talk. Most engineering teams start by opening the default database port to an internal subnet. When network rules or database roles are too broad, anyone on the subnet can query sensitive tables. A safe setup needs both tight network rules and strict query controls.
How ports sql listeners and network rules work
Every relational database engine runs a background listener process on the host machine. This process waits for incoming client requests on a specific network port. PostgreSQL uses the configured port by default, while MySQL uses the configured port. Microsoft SQL Server listens on the configured port for standard TCP traffic. When a client app starts a session, it sends a packet to that IP and port.
The host operating system checks its local firewall rules before passing the packet along. Cloud networks also check security group rules at the subnet border. If the source IP address matches an allow rule, the handshake finishes. Next, the database engine asks the client to log in with a key or password. Once the user logs in, the port keeps the session active for two-way data flow.
Teams often change the default port number to reduce noise from automated scanners. Moving a listener to a custom port stops basic bots from guessing the service. Still, anyone with a port scanner can still find the active listener in seconds. You must pair port rules with strong encryption and strict user roles.
What native port locks solve and what they miss
Locking down network ports stops outside attackers from reaching your database listener. It ensures that only approved servers and developer machines can start a network session. Combined with TLS encryption, port rules protect data as it moves across the wire. This network layer setup is a vital first step for any production system.
Still, a network port only decides who can knock on the database door. Once a user logs in through an open port, the firewall does not inspect traffic. The network layer cannot tell a safe read query from a full table drop. If a developer shares a role, every query looks the same at the port level.
SQL Query Filtering: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Database roles try to fix this gap, but they stay static during a session. Teams often grant broad read roles so engineers can fix production bugs fast. With an open port and a read role, a user can pull thousands of customer emails. Native port rules also fail to rewrite sensitive fields like phone numbers or card numbers in flight. To control what happens inside the session, you need inspection at the query level.
Best practices for managing database ports in production
Start by placing all database hosts inside private subnets with no public IP addresses. Never expose a database port directly to the public internet, even for quick tests. Use firewall rules that allow traffic only from specific app servers, not whole subnets. Remove old IP rules right away when you retire a server or service.
Check your active port listeners often to spot rogue services or open test instances. Turn off dynamic port allocation on database engines that support it, as this breaks strict firewall rules. Pin every database instance to one known TCP port so your team can track all traffic. Combine these tight network boundaries with query-level logs and data masking for full safety.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev sits inline in the protocol beside each supported service as an open-source proxy, a sidecar for your database or API. For every query or command an AI agent or engineer runs against production, hoop.dev decides to pass, mask, block, or hold it for human approval.
First, hoop.dev guardrails block banned queries before they run or hold risky ones for review, and hoop.dev data masking rewrites matched sensitive values in responses in memory. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
Which default TCP ports do major SQL databases use?
PostgreSQL uses TCP the configured port, and MySQL listens on TCP the configured port. Microsoft SQL Server uses TCP the configured port for standard client traffic. Always check your engine setup file to see which port is active.
Does changing the default SQL port make a database safe?
No, changing the port only hides the database from basic automated scans. Attackers can still run a full port scan to find the new listener. You still need strict firewall rules, strong login keys, and query controls.
Why can a user still pull raw data through a restricted port?
A firewall port only checks the source IP address when a session starts. Once the user logs in, the firewall passes all SQL commands without reading them. Without data masking, queries return raw emails, phone numbers, and card numbers.