Remote work makes a firewall change look like a quick fix. Opening port 1433 to the internet also gives scanners a direct route to your SQL Server login surface.
Check Port 1433 From the Outside
Review firewall, NAT, cloud security group, and load balancer rules for the SQL endpoint. Test public reachability from an authorized external network, not from the SQL Server itself. A local Test-NetConnection to the private name proves only internal routing. I coordinate an external check with the network team and record the source address, destination, port, and result. Do not scan unrelated addresses. If the instance uses a dynamic port or named instance discovery, include those paths in the inventory.
What should an untrusted host see? Ideally no TCP route to the database listener. A closed public path is the first boundary, not the only one.
Prefer a Private Access Route
A corporate VPN puts the remote device on an authenticated private path under device and user policy. A hardened jump host or remote desktop gateway gives administrators a controlled place to run SSMS. Azure Bastion can provide private VM access without exposing a public remote desktop port. Choose the route that fits operations and audit needs. I avoid putting SQL Server directly on the public internet even when authentication is strong. Reducing reachability reduces the number of attempts the service must answer.
Keep administrative access separate from application access. A developer needing a test database does not need the same network path and login rights as an on-call production DBA.
Verify the Listener and Firewall Rules for Port 1433
Check which addresses and ports SQL Server listens on, then compare with host firewall and upstream rules. The sample PowerShell command tests a specific route from the machine where it runs. It does not prove internet exposure unless that machine is outside the trusted network. Record both allowed private paths and denied public paths. I also check whether an old temporary rule remains after a migration. Temporary rules have a talent for becoming permanent.
# PowerShell
Test-NetConnection -ComputerName 'sql.internal.example' -Port 1433
Get-NetFirewallRule -Enabled True -Direction Inbound |
Where-Object DisplayName -Match 'SQL'Encrypt With a Trusted Certificate
Use a current driver with encryption enabled and a certificate whose name matches the private endpoint clients use. Trust the issuing authority rather than setting TrustServerCertificate=True as a permanent shortcut. Encryption protects traffic on the approved path; it does not make a public port acceptable. I test certificate validation from the actual client hosts, including VPN and jump hosts. A name mismatch after an alias change is common and should be fixed in the certificate or name design.
Rotate certificates before expiry and keep that process in the access runbook. A secure route that fails after a routine certificate renewal is not operationally secure.
Review Logins and Server Settings
Disable unused SQL logins, enforce strong policy for those required, and grant only needed database rights. Prefer integrated or managed identity authentication where the environment supports it. Check failed login patterns and audit coverage. The query below lists SQL login state and policy flags for review; it does not expose passwords. I also review the default database and server-level roles, since a locked-down network path does not excuse a broadly privileged login.
SELECT name, is_disabled, is_policy_checked, is_expiration_checked,
create_date, modify_date
FROM sys.sql_logins
ORDER BY name;Check Authentication and Audit Together
Network isolation reduces exposure, but weak or shared logins can still cause trouble from inside the approved path. Review server roles, SQL login policy, disabled accounts, and stale service credentials. I keep human administrator access separate from application access and use individual identities where possible. Failed-login monitoring should distinguish expected mistakes from a repeated attack. Capture source addresses and timestamps without exposing password material. A jump host gives a useful audit point only when users do not all share one generic account.
For Azure or hybrid access, check whether Bastion, VPN, and private endpoints connect to the intended host and database. A private route that accidentally lands on a test instance can lead to confusing data and permission reports. I verify the endpoint from the client as well as the firewall rule.
Test That Port 1433 Stays Closed
A security checklist needs a negative test. From an authorized external vantage point, confirm that the public address and port do not accept a SQL connection. From the VPN or jump host, confirm the approved connection succeeds with certificate validation. Then try a low-privilege login and verify it cannot perform administrative operations. I coordinate these tests with network and security teams and keep the exact source location in the record. A test from inside the same network cannot establish public inaccessibility.
What happens after a firewall change or disaster recovery switch? Recheck both paths. Old NAT rules, temporary allowlists, and replacement hosts can reopen the port. I include the external denial test in periodic reviews, not only the initial remote-work setup. The goal is a private, authenticated, encrypted path that still works for the people who need it.
Review outbound paths from the jump host as well as inbound paths to SQL Server. A jump host that can reach many unrelated systems can expand the impact of a compromised administrator session. I keep its software patched, restrict clipboard or file transfer under local policy, and log privileged access. The network route should be narrow enough to support work without becoming a universal bridge.
Close the Remote-Work Checklist
Confirm no public inbound rule reaches port 1433 or the SQL listener. Confirm VPN, jump host, or Bastion access uses strong authentication and is logged. Confirm TLS validates a trusted certificate. Confirm service and human logins have the least rights they need. Test both a successful authorized connection and a denied unauthorized route. I keep the test evidence with the firewall change so the next audit does not depend on memory.
If an emergency rule is unavoidable under a separate approved process, give it an owner and expiration. Remove it after the incident and verify removal from an external vantage point. An open port does not become safe because the ticket says "temporary."
Related reading on this blog: Maximizing SQL Server Security: Instance Hiding vs SQL Browser Disable and Fix: Error: The certificate chain was issued by an authority that is not trusted.
Remote access is not a public database port, it is an authenticated path to a private service.
Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.
