SQL Ports to Open

Published
Length
3 min read

Luis Felipe Dias

All posts

To pick the right sql ports to open, enable TCP the configured port for SQL Server. For PostgreSQL and MySQL, open TCP ports 5432 and 3306 on your private firewall. Most teams start by opening these ports to a wide range of internal subnets. When network rules and database roles are too broad, anyone on the network can run risky queries. A good setup pairs tight firewall rules with strict database permissions. Which sql ports to open for your database Every relational database listens on a sp

Open Policy Agent (OPA) + End-to-End Encryption: the complete guide

Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.

Free white paper. No spam. Unsubscribe anytime.

To pick the right sql ports to open, enable TCP the configured port for SQL Server. For PostgreSQL and MySQL, open TCP ports 5432 and 3306 on your private firewall. Most teams start by opening these ports to a wide range of internal subnets. When network rules and database roles are too broad, anyone on the network can run risky queries. A good setup pairs tight firewall rules with strict database permissions.

Which sql ports to open for your database

Every relational database listens on a specific network port for client traffic. Microsoft SQL Server uses TCP the configured port for its default instance. Named instances often use dynamic ports, and the browser service listens on UDP the configured port. PostgreSQL listens for client traffic on TCP the configured port. MySQL and MariaDB listen on TCP the configured port for standard client connections. You set up these rules in your cloud security group or host firewall. First, you block all public web traffic from reaching these database ports. Next, you allow inbound traffic only from specific app servers or private subnets. The database engine then checks the user name and key when a client connects. Once the login succeeds, the database assigns a role to that user session.

How to set up network rules for database hosts

Start by listing every app and user group that needs database access. Create a firewall rule that allows only the exact IP addresses of your app servers. Avoid opening the database port to the entire corporate network or VPN subnet. If you run SQL Server with named instances, assign a fixed TCP port first. Dynamic ports force you to open a wide range of ports on the firewall. A fixed port lets you keep the firewall rule tight and easy to check. You should also turn on encrypted transport so data stays safe on the wire. After you set up the firewall, review your database roles and remove extra admin rights. Give each app role only the read or write permissions it needs to run.

What firewall rules solve and what they miss

Firewall rules and port controls keep outside attackers away from your database hosts. They make sure only approved machines on your network can reach the login screen. Still, a firewall only checks the network address and port number of a packet. Once a user logs in over an open port, the firewall does nothing else. Native database roles also Decide who logs in, not what each query does in flight. An engineer with read access can still pull a full table of customer emails. A developer with write access can still run a bad update statement by mistake. Port rules cannot mask phone numbers or card numbers in query results. They also cannot ask a team lead to approve a single risky command.

Open Policy Agent (OPA) + End-to-End Encryption: architecture patterns and best practices

Continue reading? Get the full guide.

Free. No spam. Unsubscribe anytime.

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

Should I ever open SQL ports to the public internet?

No, you should never open database ports to public IP addresses. Automated bots scan ports 1433, 3306, and 5432 all day for weak keys. Always place your databases in a private subnet with no public IP address.

Do I need to open UDP the configured port for SQL Server?

You only need UDP the configured port if you use dynamic ports on named instances. It is safer to set a fixed TCP port for your instance instead. Then you can leave UDP the configured port closed on your firewall.

Does changing the default SQL port make my database safe?

Changing the default port hides your database from basic port scans, which reduces noise. Still, attackers can still find the new port with a full network scan. You still need strong keys, strict roles, and query controls to protect your data.

Save the open-source gateway.

hoop is MIT-licensed infrastructure for controlling how AI agents reach production data. Star hoophq/hoop so you can inspect it, deploy it, or share it when your team starts governing agent access.