Since we’re on a recent theme of revising long-held best practices that are not, here’s a timely one for you:
Don’t change your default SQL Server port for security reasons.
In SQL Server Configuration Manager, you can set a custom port for your SQL Server instance. If you’re running named instances, you might even find this a necessary step, because maybe you don’t want the SQL Server Browser service running. Or maybe you have multiple SQL Server containers on your Red Hat Enterprise Linux host.
Those are good reasons to set custom ports. Security, however, is not one of them. If you think that having SQL Server running on the default port of 1433 is a security risk, you’re doing security wrong. Default ports are there for a reason and changing this for security reasons means you’re thinking about security the wrong way. You are also adding complexity to your environment, and you might not be documenting things correctly.
A fundamental misconception about SQL Server is that it is insecure. It isn’t if you follow best practices:
- Don’t expose your SQL Server instance to the Internet. That’s probably rule number one for any production environment. If you’re exposing anything on the Internet, changing the default port is going to slow down an attacker less than a millisecond, because chances are they’ve already used a port scanner to figure out you’re running SQL Server.
- Make sure you are fully patched. Cumulative Updates are released on a regular cadence, and given your testing process, you should at least be only one or two CUs behind.
- In your internal network, you should also ensure the only traffic that is allowed to connect to your production database1Remember, if you’re restoring production data to a developer instance, it’s still production data. is your API. Then, protect your API host and don’t leak database connection information.
Security can be scary, I get that. But I also know firsthand that if you have a patched SQL Server instance and a strong password, the only thing that’s going to happen is your error log will grow as SQL Server denies and logs all the invalid connection attempts. There is a chance your server may run out of disk space if you’re not monitoring that, but you are monitoring disk usage on your production server, right?
It’s easy to get caught up in behaviour that is based on a belief system as opposed to measured results.
MAXDOP 1 was a great example of this with SharePoint for the longest time. Recently Erik Darling sounded the alarm on enabling optimize for ad hoc workloads by default.
Don’t change the default port on SQL Server as a “best practice.” Don’t do it for “security reasons.” There are great reasons why you might want to — which I outlined at the start — but don’t do it because you think it’ll keep people out of your database.
Most data leaks are caused by internal vectors. Practise the zero trust model and use defence in depth. Take care of things like backup file encryption, securing your offsite backups, and keeping port 1433 away from the Internet.
Share your security best practices in the comments below.
- 1Remember, if you’re restoring production data to a developer instance, it’s still production data.