Historically, it has been recommended not to use the default ports for connections to SQL Server, as part of security best practice. On a server with a single, default instance, the following ports would be used by default:

  • SQL Server service - Port 1433 (TCP)
  • SQL Server Browser service - Port 1434 (UDP)
  • Dedicated Admin Connection - Port 1434 (TCP)


  • Is this advice still relevant?
  • Should ALL of the above ports be changed?
  • 1
    Maybe this post can help you dba.stackexchange.com/questions/213810/… – ElGrig Oct 16 '18 at 15:51
  • 4
    I think it is still recognised as a good idea, but the reality is this just slows down an attack more than prevents it. A port scanner is quickly going to find the ones it needs. Changing the port simply disassociates the application with that default port number, which means any hacker needs to do a little more work to figure out which application is listening on any port. – DimUser Oct 16 '18 at 15:52
  • 4
    @DimUser Emphasis on the "little." – jpmc26 Oct 16 '18 at 20:27
  • 1
    Changing the port number of the SQL Server Browser service isn't possible. This service is used to look up available instances and supply their ports, and clients expect it to be available at the well-known port number 1434. If you were intent on changing the default port of SQL Server, you'd have to shut down the Browser as well (and if you're running multiple instances, clients would have to know the port number of each of them). Whatever little additional security would be added by obscuring the ports has to be weighed against such complications as well. – Jeroen Mostert Oct 17 '18 at 12:48
  • I thought the default was Dynamic Ports - random port on every startup. – Robert Niestroj Oct 19 '18 at 8:58

Historically, it has been recommended not to use the default ports for connections to SQL Server, as part of security best practice.

Which was asinine then and still asinine now. Security through arguably obscurity isn't security at all.

Is this advice still relevant

IMHO it was never relevant. It was required for some compliance purposes because the people drafting up those compliances did not understand what they were doing, again, IMHO.

Should ALL of the above ports be changed?

I wouldn't change any.

  • 12
    I'd like to note that it can defend against some attacks, by extremely unskilled people who don't know that ports can change. I'd also like to shoot down that argument by reminding everyone that, if you're only defending against attackers with that little experience, you've probably already been breached, and it's time to nuke your server and do it right this time. – Nic Hartley Oct 16 '18 at 17:12
  • 19
    @NicHartley Absolutely. I don't have my old blogs but I exposed two instances of SQL Server to the internet and logged all traffic to the virtual machines. One instance was setup on the default port, one was setup to a non-default port. Both instances were hit with SA password attacks within 5 minutes. – Sean Gallardy Oct 16 '18 at 17:36
  • 7
    @ndenarodev True, this was two different VMs on two different public IPs. One test was from my own address, the other from a friends' address. The traffic pattern was the same in both instances: 1) scan all ports, 2) try protocol resolution on each port found open, 3) attack using known tools – Sean Gallardy Oct 16 '18 at 19:19
  • 9
    It's not arguably security through obscurity; it is security through obscurity, as demonstrated by your online test. If anything, the arguable part is that it's security at all. ;D One thing you might consider adding is that the proper defense is to firewall the server inside a network that can only be accessed by those who really need to be in that environment (e.g., DBAs and system admins, and the web server can access the DB). – jpmc26 Oct 16 '18 at 20:25
  • 6
    What it basically does is keep your logs cleaner ;) not hundreds of "oh, someone tries to connect" entries from bots and script kiddies. That is ALL security you have. – TomTom Oct 17 '18 at 8:16

Even though security through obscurity isn't actual security I won't say there aren't any cases where it helps.

If an attacker wants to know where your service is listening they can easily find out, but in the event of a dumb automated attack you could be lucky if you changed the port.

The only time I can remember where it actually helped is during the time of SQL Slammer where SQL Server 2000 was vulnerable and a worm spread by generating random ip's and connecting to the default SQL Server browser port.

If I recall correctly it was official advice at the time to change the ports until you could patch your server (either because there wasn't a patch available immediately or because you didn't have a window)

For that worm to enter your network at the time you needed to have a SQL Server connected to the internet instead of behind a firewall, which you shouldn't, but anyhow, a non-default port number could have helped in that specific case.

I do however agree that if you have proper security in place the complexity you add probably doesn't outweigh the chances of it preventing an incident.


Historically, it has been recommended not to use the default ports for connections to SQL Server, as part of security best practice

No, it wasn't. Some misguided people may have presented it as such, but I've been doing security for 20+ years and changing default ports has always been a kind of "here is something you can do if you want which maybe sometimes in very specific circumstances provides a bit of additional security against some very specific threats" thing.

Is this advice still relevant?

Under very specific circumstances, depending on your threat model and risk analysis, there may be some instances in which this is sound advice. In the vast majority of cases, no, it isn't relevant nor was it ever.


YES, it is still useful.

Changing default ports has one real purpose only: defend against automated scans/attacks, if you database server is open towards hosts which might get compromised.

While that might not sound like a big deal, remember that:

  • any host might get compromised (or your databases server might get exposed to Internet at large due to some mistake)
  • most of the attacks those days are automated attacks, and many of them will try only default ports (as aiming at low-hanging fruits is most efficient).

So, yes, while it by itself will not help you much if are under targeted attack, using random ports (and/or making it listen on random IPv6 address only) will make it much less visible, thus at least giving you more time to upgrade before automated 0day exploit scan hits you (and might even protecting you completely against such automated scan all by itself!)

In addition (this will help not only against all automated attacks against, but also against some targeted attacks too) when attackers try to find your database port to exploit it by bruteforce portscans, it can be detected and defended against (by blacklisting attacker IP ranges, and alerting admins if some internal host has been detected as source of the attack)

Also note that changing default port for server and clients (especially if they are deployed automatically) is trivial amount of work, and detecting bruteforce scans is easy too; so you really should be doing it (not just for database servers; but for all services where overhead of setting it up is not prohibitive due to usability issues: like changing default port for web from 80 is not recommended, as some people (and bots) will mess it up, and random firewalls around the world might not allow connection to be established. But RDP is great target for example for non-default port)

  • A lot of automated attacks use a port scan first. So they will attack whatever port you use. – Jungkook Oct 18 '18 at 13:13
  • 2
    @Jungkook as I've written, portscans are easily detected, and attackers using them are easily blocked automatically (much before they can find the random port, and try to attack sql server). And those attackers that do not use portscan (but use default ports) are also mitigated. So you are protected against BOTH types of automated attacks. – Matija Nalis Oct 18 '18 at 14:24

I would not change the port, but however never expose the database service directly over the internet. Only through a secure tunnel like SSH. Changing the port of SSH might be a good idea to minimize the traffic by scanners.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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