There is no silver bullet to security and the best we can do is apply multiple protection layers. This is just one of them. Yes, there is the overhead of keeping track of the “application to DNS alias to port” mappings, however any decent CMDB would do the trick. In a small shop you could simply use an Excel spreadsheet (even though Excel is not a database…). Point is, the administrative/management processes should not be a barrier to security.

SQL Server Connection Strings, Unique Application DNS and Listening Ports
https://sqlserverdiaries.com/blog/index.php/2011/04/sql-server-connection-strings-unique-application-dns-and-listening-ports/

The same technique applies to all SQL Server versions and Editions, and is still valid today with the most recent release.

Thanks for your post.

Has anything changed from 2016 to 2022 in the context of this discussion? That is, I see changing ports as a starting point (phishing) but certainly not an end point (port scan) as the success depends on attack sophistication.

The reality of ransomware today makes it that much more important to do more than changing ports but its still good advice. The thief can break through the window but the police are still likely to ask whether taping the key to the door wasnt a bit ….. unthinking

Thanks Pieter, I forgot to mention the use of the browser service in the post. Disabling it makes sense if you have taken all the other steps.

I do agree with your approach. I give the same recommendations to my customers.
I would even go one step further and recommend to disable the SQL Browser Service and Hide the instance to be even more secure. Of course, this depends on what the customer wants but some of my clients do this by default.

Regards
Pieter

Agreed, default ports makes consolidations and migrations easier in a lot of scenarios.

After a few additional days of reflection on this topic I have noticed that much of the discussion is around the technical aspects using non-default ports. I think people are looking past the human element here.

If you choose to run on a default port, and the forensics of a security breach reveal that the bad actor used code that relied on default ports…in that edge case…how do you want to answer the inquiry? The persons on the other side of the table are not interested in all the technical aspects of the discussion, they just want to know if you did everything you could have done, or not.

We can go back and forth forever on the technical stuff, and workarounds for everything. But at the end of the day none of that will matter. Either you chose to use a default port, or not.

I’m with Brian here 😉
. Using DNS to abstract the physical server name is super useful.

I’ve created 10+ instance clusters with all of the instances on default ports.

Using using a dns Cname to ensure connections aren’t made to physical server name saves sooo much risk and effort on consolidations and migrations..