SQL TIPS:Non-Standard SQL Port

25MAR

As a DBA, I have heard of a defensive maneuver that is supposed to help throw the hackers off your scent. That maneuver is configuring a non-standard port for the database engine, something other than 1433.

We first need to understand a standard configuration. If you select only the database engine on install, the default instance listens on TCP port 1433. No firewall changes are made so that is something you have to do post install. The SQL Browser service is disabled because it is not required. UDP/1434 was used by the SQL Slammer worm and took advantage of poor network packet handling of the SQL Browser service. I recommend you leave this service disabled.

In previous attacks I have demonstrated, during the information gathering phase, we locate a SQL Server using nmap or zenmap. We assume this is a SQL Server because port 1433 is open. You can find a good listing of default ports on wikipedia. You can also find a good list of windows ports in your services file usually located in c:\windows\system32\drivers\etc\

Rather than discuss whether we should or should not change the SQL Port what I want to do it test out the effectiveness of the tools if the port is changed. To change what port SQL listens on for remote connections, there are three spots in the SQL Server configuration manager we have to change.

First, I like to change the listen all setting to no.

Then, find your IPv4 address and enable listening on it and change the port.

Now, we have to change the firewall. I’ve added an extra rule, then verified I could connect using the “IP,port” in SSMS.

Penetration Testing

The only thing a port change will defend against is the information gathering phase of a hack. If we do a quick scan with zenmap, I noticed that this change is at least partially effective. The ms-sql port doesn’t light up green like we are used to. In fact, no open port is identified by a quick scan.

What we have to do is open up our scan. The intense all TCP ports is very time consuming. I doubt a hacker would wait this long for a single host, I sure didn’t.

nmap has a lot options and switches we can experiment with. I did notice the option “-p T:” which will try TCP ports within the range supplied. This completes in a reasonable amount of time.

However, the service identification is missing. By changing the command a bit we can identify that the service is SQL, just not the exact version.

As you can see the port change was ultimately ineffective. The fact that the host is always easily identified as online will draw the attention of an attacker. With a small amount of persistence, the attacker can identify the target as a SQL Server.