We were deploying a new web service. Because of the nature of the service, we wanted it to listen on a non-standard port. Security by obscurity doesn’t work against a real attacker or well-written malware. However, if someone was just attempting to check for a web server by doing the standard http:// or https://, they wouldn’t find the web service. It wasn’t the only countermeasure we employed, but it was the first. 

This brought up a discussion of what port to use. Immediately, 8443 was suggested. Except this port is little better than 443. Then someone threw out 1701. That isn’t a well known port, at least not for a web server. However, that was still not a good choice. The person who made the suggestion was a huge Star Trek fan. This wasn’t a secret. Therefore, from a social engineering perspective, an insider could possibly guess what the port was by knowing the security pro in question. 

Tired of the back and forth, which had gone on for the better part of an hour, I reached into my bookbag and pulled out these:

Dice. If we wanted a random port, one that couldn’t be tied back to one of our preferences, this method was as good as any for selecting the value. The six-sided die is intentional due to the max port value. And we rolled. That’s how we chose the port. 

When it comes to security configurations, we can fall into the trap of trying to be too clever. We devise a method that surely will fool everyone. However, in a lot of cases a determined adversary who has done his or her research can puzzle together our plan unless we seek steps to randomize things or intentionally break from known patterns. That’s what the dice did for us: it broke us from known patterns. 

That shouldn’t be all we do. Determining the port was the easiest thing we implemented to protect that web service. Also, when we make choices, we do still have to consider the operational ramifications. For instance, if we have a SQL Server that will be accessed by business users, does throwing it on a random port make sense? It likely doesn’t. In the case of the web service, it was only going to be accessed by back-end applications. Therefore, going to a non-standard port was perfectly reasonable. Had we expected end users to access it, that would have been a different story.