when relevant content is
added and updated.
We’ve all heard the argument that using a different TCP port number for SQL, other than 1433, is more secure. Here’s the truth, it isn’t. Andy said it best here in a conversation on Twitter that happened in the #sqlhelp hash tag. If you think that hiding your SQL Servers on a different TCP port number is going to make them harder to break into you are sadly mistaken.
The two most common ways of a data breach are employees and SQL Injection. Employees already know what port the SQL Server is listening on, as they know how to connect to it already. If not, they can easily download a port scanner and scan the SQL Server for open ports. The ones that are open they’ll connect to. If it’s a decent port scanner it’ll tell them which port is SQL and what all the other open ports are so they’ll know which one to connect to. You’ve slowed the attacker down by about 5-10 seconds, maybe.
If the attacker is using SQL injection then they don’t care what port the SQL Server is running on. They are connecting to the web/app tier and just using whatever SQL Server connection information that the application has to get access to your database. By changing the TCP port number you haven’t slowed them down at all.
Proper security requires understand user/business requirements and building a solution which will meet those requirements while building proper secure protections into the system so that if something does go wrong the exposure is limited.
Pretending that hiding the servers and making them harder to find is making them more secure isn’t. Spend time doing things which will make the environment actually secure so that when the system is breached the data isn’t all lost. And if possible do this without making the environment harder to manage, which is all that you are doing by changing the TCP port numbers.