1433 MSSQL TCP Flagship
Reference for TCP port 1433, commonly associated with MSSQL.
What it's for
Port 1433 is the default port for Microsoft SQL Server, the relational database heavily used across enterprise and Windows-centric application stacks. Applications, ORMs, and tools like SQL Server Management Studio connect on this port to run queries, manage schemas, and administer the database.
Protocol basics
- Protocol: TCP, using SQL Server's own TDS (Tabular Data Stream) wire protocol for client-server communication.
- Named instance discovery. A single SQL Server installation can host multiple named instances beyond the default one listening on 1433, each on its own dynamically assigned port. The SQL Server Browser service (UDP port 1434) helps clients discover which port a named instance is actually using.
- Two authentication modes. SQL Server supports its own SQL authentication (username/password managed within the database) alongside Windows/Active Directory integrated authentication, letting domain-joined clients authenticate using their existing Windows credentials without a separate database password.
- TLS support is configurable but not always enabled by default, particularly in older or self-managed installations — this is a genuine gap worth checking explicitly rather than assuming.
Security considerations
- Port 1433 should never be exposed to the public internet. Like other database ports, it belongs on a private network reachable only by application servers, with firewall/security group rules enforcing that boundary rather than relying on database-level authentication alone.
- The
sa(system administrator) account is a prime brute-force target whenever SQL Server is reachable — disable it entirely where possible, or at minimum enforce a strong, unique password and rename/restrict it rather than leaving it as a well-known default target. - Prefer Windows/AD integrated authentication over SQL authentication where the environment supports it, since it centralizes credential management and avoids storing separate database passwords that can be independently compromised.
- Enable TLS explicitly — don't assume it's on by default, especially on older installations, since unencrypted TDS traffic exposes credentials and query data to anyone on the network path.
- SQL Server Browser (UDP 1434) reveals instance names and ports to anyone who queries it if left exposed — this reconnaissance information is exactly what an attacker probing for named instances would want, so it should be firewalled alongside 1433 itself.
Troubleshooting
"A network-related or instance-specific error occurred... (provider: TCP Provider, error: 0)":
- Check that SQL Server's TCP/IP protocol is actually enabled (it's off by default in some installations) via SQL Server Configuration Manager, and that a firewall isn't blocking 1433
Can connect to the default instance but not a named instance:
- Confirm SQL Server Browser (UDP 1434) is running and not blocked, since named instances rely on it for port discovery — alternatively, connect directly using the instance's actual static port if you've configured one
"Login failed for user 'sa'" or similar authentication failures:
- Verify SQL authentication is actually enabled on the server (it can be disabled in favor of Windows-only auth) and that the account isn't locked out from repeated failed attempts
Connects locally but not from another server/container:
- Check that SQL Server is configured to listen on all interfaces (not just localhost) and that both the OS firewall and any cloud security group allow inbound 1433 from the connecting host
Comparison / FAQ
| Port | Protocol | Key difference from 1433 (MSSQL) |
|---|---|---|
| 3306 (MySQL) | TCP | Open-source relational database with a different wire protocol; broadly comparable deployment patterns |
| 5432 (PostgreSQL) | TCP | Open-source relational database with strong standards compliance, often considered alongside MSSQL for new projects |
| 3389 (RDP) | TCP | Full remote desktop access to the Windows server itself, distinct from direct database connections on 1433 |
Why is SQL Server Browser (port 1434) relevant to securing port 1433?
Because it can reveal which named instances exist and what ports they're using to anyone who queries it, effectively handing reconnaissance information to an attacker — it should be restricted or disabled in the same way you'd restrict 1433 itself.
Should I use SQL authentication or Windows authentication?
Windows/Active Directory integrated authentication is generally preferred in domain environments since it centralizes credential management through existing infrastructure. SQL authentication remains necessary for non-domain scenarios (like cross-platform application connections) but requires careful password and account management, especially for the built-in sa account.
Is it safe to run SQL Server without TLS if it's on an internal network?
Even on an internal network, unencrypted TDS traffic can be intercepted by anyone with access to that network segment, including insider threats or a compromised adjacent host. Enabling TLS is low-cost relative to the risk of plaintext credentials and query data traversing the network.
Why does my connection work with SQL Server Management Studio but not from my application code?
Often a difference in how each client resolves the server address or handles named-instance discovery — SSMS may be using integrated authentication or the SQL Browser service to locate a named instance, while your application's connection string might need the port specified explicitly instead.