SQL Server's default port is 1433. I've been told by our admin that the port has to change "for security reasons".

Is it really that much safer to change the port? If the server is behind a firewall and it only allows connections to it from a certain range of IP's, is that not good enough?


9 Answers 9


It helps against common port scans that can be initiated through port scanning websites. But it won't help against a committed attacker. It's just another layer, but doesn't add much over the firewall, as you mentioned.


If your SQL Servers are directly connected to the Internet (which they shouldn't be) then it can offer you some protection as most of the generic attack scripts only use the default port numbers.

If your SQL Servers are not accessible directly from the Internet this is pretty pointless. Any firewall will have to allow connectivity to the remote port. As soon as I run the client software on the machine I can see what port the SQL Server is using via the NET STAT command. At this point you've slowed me down exactly 2-3 seconds.


It will break applications that expect port 1433.
Some apps can be configured to deal with this but this has to be deployed.

I'd just leave it. If they "hack" your default instance on port 1433 then you're already bollixed.

You can specify the port for named instances but then port 1434 needs opened to resolve instance to port...

  • 1
    If you always connect by port then SQL Server Browser (and thus, port 1434) can also stay closed. Commented Oct 10, 2011 at 15:40

Hackers frequently scan IP addresses for commonly used ports, so it's not uncommon to use a different port to "fly under the radar". This is just to avoid detection, other than that there is no added safety by using a different port.

If only a limited IP range can access the port, then you are already "under the radar", so I don't see a good reason to use a different port.


Actually, yes. To use another example, the administrator of my university's Linux lab changed the SSH port away from 22 to some obscure value. He reported that the network dropped from ~10,000 pings/attacks per day to roughly 1 or 2 per month. Granted, if you are not already suffering that kind of attack, maybe it is not worth the effort in most cases. Still, by changing to a discreet alternate port, you prevent broad probe assaults and whatnot.


I think this is a two-part problem.

1) Common port scanning software may try the common ports first, but there is nothing specifically limiting it from trying all ports, and it you need to be able to assume it will be able to finger-print the protocol when it finds an open port.

2) When the more aggressive port-scan is happening, you need to be able to detect it, and do something with this knowledge (like fail2ban, etc.)

Your admin is proposing (1), ask what ideas he has regarding (2).


Security through obscurity is not security at all.

Edit: then again, some say it is! Personally, I'll continue to adopt my original point.


Changing the port will force them to do a scan. When you use a security tool such as snort, with network taps or SPAN, then something like a port scan of your server becomes obvious. Someone legitimately connecting to the SQL server on the default port is not so obvious.

The best approach, I agree, is not security by obscurity. However, changing the default port on any and all applications, when possible, is part of an over-arching, deeper strategy that includes red team activities, network security monitoring teams, and all of the correct instrumentation, installed, matured, and understood by those who are using it.

When you have all of these things, then an intruder in your system stands out like a sore thumb. The bottom line - if anyone thinks that they can improve the security of their systems by checking off a bunch of items on a list, they are wrong. If they can't explain why they need the port changed, in no uncertain terms, then they don't belong in the role of someone telling you to change the port.


When an application connects to MS SQL over TCPIP the first part of the conversation takes place on 1433 with the default unnamed instance- not least is the desemination of any port numbers that named instances are communicating on. Any firewalls should be configuered to a) let this through to ip ranges that are appropriate, B) the fixed port numbers that any named instances may be using. These should be configuered in the SQL config manager as fixed. You can communicate with any instance using (ip address : (port number 12345) in the connection string. If the SQL browser service is not enabled then 1433 will not provide the intitial conversation. If you are using NT authentication then there is little to be gained. If you are using SQL authenetication then there is a small amount to be gained.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.