Securing Port 443: The Gateway To A New Universe

At Wordfence our business is to secure over 4 million WordPress websites and keep them secure. My background is in network operations, and then I transitioned into software development because my ops role was at a scale where I found myself writing a lot of code. This led me to founding startups, and ultimately into starting the cybersecurity business that is Wordfence. But I’ve maintained that ops perspective, and when I think about securing a network, I tend to think of ports.

You can find a rather exhaustive list of TCP and UDP ports on Wikipedia, but for the sake of this discussion let’s focus on a few of the most popular ports:

  • 20 and 21 – FTP
  • 22 – SSH
  • 23 – (Just kidding. You better not be running Telnet)
  • 25 – Email via SMTP
  • 53 – DNS
  • 80 – Unencrypted Web
  • 110 – POP3 (for older email clients)
  • 443 – Web encrypted via TLS
  • 445 – Active Directory or SMB sharing
  • 993 – IMAP (for email clients)
  • 3306 – MySQL
  • 6378 – Redis
  • 11211 – Memcached

If you run your eye down this list, you’ll notice something interesting. The options available to you for services to run on most of these ports are quite limited. Some of them are specific to a single application, like Redis. Others, like SMTP, provide a limited number of applications, either proprietary or open-source. In both cases, you can change the configuration of the application, but it’s rare to write a custom application on one of those ports. Except port 443.

In the case of port 443 and port 80, you have a limited range of web servers listening on those ports, but users are writing a huge range of bespoke applications on port 443, and have a massive selection of applications that they can host on that port. Everything from WordPress to Drupal to Joomla, and more. There are huge lists of Content Management Systems.

Not only do you have a wide range of off-the-shelf web applications that you can run on port 443 or (if you’re silly) port 80, but you also have a range of languages they might be coded in, or in which you can code your own web application. Keep in mind that the web server, in this case, is much like an SSH or IMAP server in that it is listening on the port and handling connections, but the difference is that it is handing off execution to these languages, their various development frameworks, and ultimately the application that a developer has written to handle the incoming request.

With SSH, SMTP, FTP, IMAP, MySQL, Redis and most other services, the process listening on the port is the process that handles the request. With web ports, the process listening on the port delegates the incoming connection to another application, usually written in another language, running at the application layer, that is part of the extremely large and diverse ecosystem of web applications.

This concept in itself – that the applications listening on the web ports are extremely diverse and either home-made or selected from a large and diverse ecosystem – presents unique security challenges. In the case of, say, Redis, you might worry about running a secure version of Redis and making sure it is not misconfigured. In the case of a web server, you may have 50 application instances written in two languages from five different vendors all on the same port, which all need to be correctly configured, have their patch levels maintained, and be written using secure coding practices.

As if that doesn’t make the web ports challenging enough, they are also, for the most part, public. Putting aside internal websites for the moment, perhaps the majority of websites derive their value from making services available to users on the Internet by being public-facing. If you consider the list of ports I have above, or in the Wikipedia article I linked to, many of those ports are only open on internal networks or have access to them controlled if they are external. Web ports for public websites, by their very nature, must be publicly accessible for them to be useful. There are certain public services like SMTP or DNS, but as I mentioned above, the server that is listening on the port is the server handling the request in these cases.

A further challenge when securing websites is that often the monetary and data assets available to an attacker when compromising a website are greater than the assets they may gain compromising a corporate network. You see this with high volume e-commerce websites where a small business is processing a large number of web-based e-commerce transactions below $100. If the attacker compromises their corporate network via leaked AWS credentials, they may gain access to the company bank account and company intellectual property, encrypt the company’s data using ransomware, or perhaps even obtain customer PII. But by compromising the e-commerce website, they can gain access to credit card numbers in-flight, which are far more tradeable, and where the sum of available credit among all cards is greater than all the assets of the small business, including the amount of ransom that business might be able to pay.

Let’s not discount breaches like the 2017 Equifax breach that compromised 163 million American, British and Canadian citizen’s records. That was extremely valuable to the attackers. But targets like this are rare, and the Web presents a target-rich environment. Which is the third point I’d like to make in this post. While an organization may run a handful of services on other ports, many companies – with hosting providers in particular – run a large number of web applications. And an individual or company is far more likely to have a service running on a web port than any other port. Many of us have websites, but how many of us run our own DNS, SMTP, Redis, or another service listening on a port other than 80 or 443? Most of us who run websites also run MySQL on port 3306, but that port should not be publicly accessible if configured correctly.

That port 443 security is different has become clear to us at Wordfence over the years as we have tracked and cataloged a huge number of malware variants, web vulnerabilities, and a wide range of tactics, techniques, and procedures (TTP) that attackers targeting web applications use. Most of these have no relationship with the web server listening on port 443, and nearly all of them have a close relationship with the web application that the web server hands off control to once communication is established.

My hope with this post has been to catalyze a different way of thinking about port 443 and that other insecure port (80) we all hopefully don’t use. Port 443 is not just another service. It is, in fact, the gateway to a whole new universe of programming languages, dev frameworks, and web applications.

In the majority of cases, the gateway to that new universe is publicly accessible.

Once an attacker passes through that gateway, a useful way to think about the web applications hosted on the server is that each application is its own service that needs to have its patch level maintained, needs to be configured correctly, and should be removed if it is not in use to reduce the available attack surface.

If you are a web developer you may already think this way, and if anything, you may be guilty of neglecting services on ports other than port 80 or 443. If you are an operations engineer, or an analyst working in a SOC protecting an enterprise network, you may be guilty of thinking about port 443 as just another port you need to secure.

Think of port 443 as a gateway to a new universe that has no access control, with HTTPS providing easy standardized access, and with a wide range of diverse services running on the other side, that provide an attacker with a target and asset-rich environment.

Footnote: We will be exhibiting at Black Hat in Las Vegas this year at booth 2514 between the main entrance and Innovation City. Our entire team of over 30 people will be there. We’ll have awesome swag, as always. Come and say hi! Our team will also be attending DEF CON immediately after Black Hat.

Written by Mark Maunder – Founder and CEO of Wordfence. 

Did you enjoy this post? Share it!


  • Great summary, but the font is way too small to read on a large screen. I had to zoom 200%. Can you please make your blog even more enjoyable?

    • Thanks Tanel. I'll have our QA team take a look and try to reproduce the issue. Much appreciated.

    • I agree that the font is too small on a desktop device

    • Hi Tanel, thank you for letting us know about the font-size issue you are having viewing this post. Unfortunately I’m unable to replicate the problem here. If you are able, would you please send the following information to

        A screenshot of how the blog post looks on your screen
        Scaling settings for both your browser and operating system
        Is this appearance issue on all blog posts or just this specific one?
    • Tanel, after reviewing your comments and those of others, I have submitted a request to update the readability of the site. I appreciate your feedback.

  • Interesting stuff, but your rather exhaustive port list link is broken.

    • Thanks, I believe my colleague just fixed that.

  • I would love to see a discussion on port 3306. You said " Most of us who run websites also run MySQL on port 3306, but that port should not be publicly accessible if configured correctly.". But what is you want access to this port from external? I need access to my internal server for Good Data Studio.

    • You can still make 3306 accessible, just limit the IP range who can communicate with it on the firewall.

      I regularly limit my new AWS instances to just my static IP when I'm working on a new one ... means I can access it, but nobody else can until I'm ready. Limiting 3306 to just access the single IP (or range) that you need for access still gives you the access you need, without making it publicly available.

      This does assume you have a static IP of course.

  • i liked how it made me think

  • Have to agree with the font size issue (I'm running 2560x1440 on a 27" monitor, using plain vanilla Chrome at 100%). 125% is fine for me.

    But that's not why I'm commenting.

    At a get-together years ago, I happened to ask a Chemical Process Control colleague from our same employer whether they had secured UDP ports on their industrial automation controllers. He didn't know, so we walked to my computer, downloaded a UDP browser, and entered the IP address for one of his controllers (this from my house, not over a VPN, on the public internet). Up it came. He blanched, excused himself, and quickly called an emergency meeting. In an hour or so, open UDP access was no longer publicly available.

    Other than the initial mention, I don't see UDP on your list. I'd like to see more discussion on this topic. Maybe not of general interest to WordPress site admins, but in light of recent geopolitical events, may be of wider interest.

    • Thanks for the feedback. DNS is UDP which I do mention. It’s really in the same category as TCP as far as I’m concerned - just the one is connectionless and the other has a three way handshake that is required before client and server can talk. But for the sake of this discussion it doesn’t really matter either way.

      The ICS system you mention is another service in the category of non-user controlled application that I’ve described above. You don’t have a wide range of custom apps accessible via a single port as with web. But obviously worth securing nevertheless.



    • As more browsers and web sites move to supporting HTTP/3, UDP is definitely in the mix here, as HTTP/3 is designed to communicate over UDP and not TCP (see ).

  • Gud

  • The font colour is way too light, however a great article to read.

    • Thanks. Will improve it.

  • In the days when I built PCs during the gold rush era in the 90s I recall someone from the military telling me that there are some undocumented ports used by the intelligence apparatus. Just wonderedif this is true..

  • This is an excellent perspective to have, even if you run PCI and similar vulnerability scanners. Mark is offering a paradigm to help ops teams take an offensive position rather than always falling back to defense aided by endless logs and reports. Imagine the security time we might save if we engineered the stack (eh hem Apache community) to begin with ALL public ports closed and force ourselves to open only what MUST be opened to run the apps. Sure, it might be annoying and feel extraneous at first, but losing the sensitive data or being taken hostage by hackers has to be a lot more stressful.

    Nicely put, Mark!

    • Thanks.

  • Great analysis.......but you provide no solutions. Maybe use a different port?


  • Great article, making great points and above all making you think!

  • good information to keep us all on our toes