Csdrhrt

I often establish Ubuntu-LAMP environments on which I host a few Drupal web applications that I myself own (I don't provide any hosting services and never done so in the past).

Whenever I establish such an environment, the most fundamental security steps I take are these:

ufw --force enable

ufw allow 22,25,80,443 # All allowed via both TCP/UPD as no restrictions were given;

apt-get update -y

apt-get upgrade unattended-upgrades sshguard

After the 2017-2018 W3C/Google (?) reforms regarding browser support in HTTP, requiring or at least encouraging all of us to use TLS encryption confirmed with an SSL certificate for secured http data transfer (HTTPS), I wonder if unsecured HTTP (typically via port 80) is still relevant at all to any of us.

Notes:

1. Each of my web apps has its own OpenSSL certifcate I create with Certbot.


2. The only web utility I use besides websites is either PHPMyAdmin/PHPMiniAdmin.

My question

Is it okay for me to remove port 80 from ufw allow 22,25,80,443 thus making my system even a tiny bit less "vulnerable"?

Update per answers

Answers recommend redirecting from port 80 to port 443 instead just blocking port 80. I think Certbot creates these redirects automatically so I'm covered if I keep port 80 open as recommended in the answers.

Google, the major search engine of the Internet (dwarfing both Bing and Yahoo), and the browser used by majority of Internet users, has been pushing for an HTTPS-only world by decreasing the page rank for sites that do not HTTPS, and adding a browser warning when a site is not secure. However, the ratio of HTTPS sites to not is still far too low to recommend an HTTPS-first policy for everyone, because users would pretty constantly get scary "certificate error" messages or "connection refused" errors.

So, until Google recommends an HTTPS-first policy for browser connections, it's not likely that Firefox, Apple, or Microsoft will recommend such policies, either, and that is not likely until a decent majority (perhaps 70% or more) of top sites are HTTPS enabled, which would be a huge increase from the ~50% of top sites that have HTTPS today.

Most users that intentionally or accidentally visit your HTTP site, if greeted with a "connection refused" error, will likely move on to another site. I don't have a good way to get concrete numbers here, but it would be likely that 70-90% of Internet users probably wouldn't figure out the site has no HTTP port without an automatic redirect; the remainder are probably either technically competent enough to realize they need HTTPS, or use HTTPS Everywhere, and wouldn't notice anyways.

Definitely use HSTS, definitely 301 redirect to HTTPS resources (the 301 indicates a permanent move to browsers, so they will "remember" this preference), definitely advise your users to make sure they see a padlock and verify the certificate, etc. Do not block port 80 at this point, as the Internet simply is not ready for this yet.

As far as I know, there are no major sites that have disabled HTTP and blocked port 80. If you do this, you'll be breaking user expectation (that the site will forward you to a secure site), and since most users won't know what to do here, because they won't get a friendly error message, will simply assume your site is broken and move on.

You should not close off port 80. Instead, you should configure your server to redirect HTTP port 80 to HTTPS port 443 in order to use TLS. You can optionally use HSTS (HTTP Strict Transport Security) to tell browsers to remember to only use TLS when connecting to your site in the future.

There is nothing insecure about port 80 being open. Security issues only occur when the web server is serving requests over an unencrypted connection, especially if those requests contain sensitive data. Having port 80 be open and send nothing more than an HTTP redirect is perfectly safe.

In short: USUALLY, keep it open and use it to redirect everything to HTTPS.

Now onto the complicated stuff: taking away port 80 can stop cookie-thieves that passively look for straggle http://corp.com/some/forgotten/thing requests. The TCP connection does not succeed, the browser does not send the GET and cookies, and the bad guy cannot read them.

Sometimes this is a reasonable thing to protect against, especially thinking of corporate environments: legacy apps, HSTS only partially implemented, cookies that may lack the secure flag or path or host restrictions, third-parties hosted or proxied, ...

Now, should you block it? Probably not.

Like others mentioned, that would complicate setting up Let's Encrypt and prevent redirects (including users that just type your.com in the address bar). If you have set domain-wide HSTS, removing redirects may even be considered counterproductive (you may want to risk one plain HTTP connection so it will protect all future ones).

Also, note that active attackers will not be stopped (they can make the connection complete artificially, MITM proxy tools may even do this by default), there are corner cases (plain HTTP proxies, delegated domains outside your firewall), and you may just consider the passive attack too complicated for your model.

Finally, should you add port 80 to a new server? Well, unless you already have a reason for opening it (see above), no.

In addition to the other forest and phyrfox's answers, ACME http-01 verification uses port 80 to reach your servers. If you close the port, you won't be able to renew or create certificates.