Free tools Windows power users keep installed

One-click scans. No signup required.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more

TCP/1433 is the usual default port for a SQL Server Database Engine instance, but the headline figure of 5,873,669 hosts is not a verified current count of exposed SQL Server databases. The accessible result carrying that number did not provide its scan method or underlying evidence. Shodan’s port table, accessed October 5, 2026, showed 178,800 TCP/1433 results labeled “mssql”—a separate, changing observation that cannot be reconciled with the headline count from the available evidence. Neither number establishes that the listed hosts are vulnerable or compromised.

What does an internet-facing port 1433 count tell you?

A count of search results for TCP/1433 describes observations made by an internet-scanning service under a particular query and coverage. It is not automatically a count of unique, confirmed SQL Server installations, and it does not show that anyone accessed data or bypassed authentication.

Figure What is established What is not established
5,873,669 This number appears in the headline of an article result. Its accessible page did not reveal the provider, search string, scan date, geographic scope, deduplication method, or definition of “hosts.” It cannot be treated as a current census, a count of vulnerable databases, or a confirmed SQL Server count.
178,800 Shodan’s Data Status port table listed this many TCP/1433 results and labeled the service “mssql.” The live page was accessed October 5, 2026; it did not state a separate stable observation date. It is not a directly comparable confirmation of the headline figure. Query definition, scan coverage, and date affect the result.

Shodan explains that its statistics are based on a search query and facets such as port, and that filters can narrow results. See Shodan Data Status and Shodan’s explanation of search statistics. An open-port observation is a reachability signal, not proof that SQL Server is definitely running, that a vulnerability exists, or that a compromise occurred. Defenders should validate observations against their own authorized asset inventory and firewall configuration.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Why is TCP/1433 associated with SQL Server?

Microsoft documents TCP/1433 as the common port for a default SQL Server Database Engine instance. It is a convention, not a requirement: administrators can change the port, and named instances commonly use dynamic ports. A scan looking only for 1433 therefore cannot find every SQL Server, while a response on 1433 alone does not conclusively identify what is listening. See Microsoft’s Windows Firewall guidance for Database Engine access.

What about UDP/1434?

The SQL Server Browser service can help clients locate instances that are not listening on 1433; it uses UDP/1434. Microsoft recommends leaving Browser stopped for a more secure environment and configuring clients with the port number when practical. That discovery function is not a reason to expose UDP/1434 to the public internet. The same Microsoft guidance covers Browser and firewall configuration.

How should you secure a SQL Server listener?

Start by deciding which systems genuinely need to connect and from where. Microsoft’s Windows firewall documentation states: “By default, Windows enables the Windows Firewall, which closes port 1433 to prevent Internet computers from connecting to a default instance of SQL Server on your computer.” Its guidance is to allow only authorized users or computers and warns that opening ports can expose servers to malicious attacks.

  1. Confirm ownership and business need. Verify that the IP address and service belong to your organization, identify the applications and administrators that depend on access, and use only authorized scanning and asset-inventory methods.
  2. Remove unnecessary public reachability. Prefer private network paths for administration and application-to-database traffic. For Azure SQL Database, Microsoft recommends private endpoints through Azure Private Link to avoid public internet exposure. When using private endpoints, Microsoft also recommends disabling public network access. These recommendations are specific to Azure SQL; configure self-hosted SQL Server and SQL Server VMs at the applicable host, network, or cloud layer. See Microsoft’s Azure SQL Database security guidance and its connectivity overview.
  3. If public access is necessary, restrict its sources. Use the relevant host firewall, network security group, or managed-service firewall to allow only required IP addresses or ranges. Microsoft’s Azure SQL guidance recommends limiting firewall rules to necessary addresses or ranges; do not leave a broad rule simply because it is convenient.
  4. Harden beyond network filtering. Encrypt connections, apply least privilege, review privileged permissions, and disable unused components. A firewall controls reachability; it does not replace identity, authorization, or database security. Microsoft’s SQL Server security guidance covers these broader controls.
  5. Review adjacent configuration. Check whether SQL Server Browser is needed and avoid opening extra ports by habit. Where clients can use a known port, Microsoft’s guidance favors leaving Browser stopped.
  6. Validate after the change. Confirm that legitimate applications and administrators still connect, and verify from an external vantage point that unauthorized public sources cannot reach the listener. Changing the port number alone is not an access-control measure.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Which access pattern should you choose?

Access pattern Public reachability Operational considerations
Private endpoint, private network, or VPN Can avoid exposing the database listener to the public internet. Requires maintaining private network paths for applications, administrators, and recovery processes. Identity, authorization, and encryption remain necessary.
Public endpoint restricted to known sources Publicly addressed, but inbound access is limited by firewall rules. Requires maintaining accurate source allow-lists and checking that rules do not drift into broad access.
Broadly reachable public endpoint Reachable from a wider range of internet sources. Creates greater dependence on deliberate access controls and secure service configuration; public reachability is not itself proof of compromise.

Control ownership varies by deployment: a self-hosted server may rely on Windows Firewall and perimeter controls, while a cloud deployment may also use network security groups or a managed-service firewall. A physical firewall appliance is only one possible enforcement point; existing host firewalls, network appliances, cloud firewalls, or security groups may already provide the needed restriction.

What’s actually slowing this PC down?

Pick the symptom - the matching free tool is one click away.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.