Dois-je fermer le port 80 pour toujours et depuis les initiatives de sécurité Web 2018 indiquées par Google?
J'établis souvent Ubuntu - LAMP environnements sur lesquels j'héberge quelques Drupal applications web que je possède moi-même (je ne fournis pas aucun service d'hébergement et jamais fait dans le passé).
Chaque fois que j'établis un tel environnement, les mesures de sécurité les plus fondamentales que je prends sont les suivantes:
ufw --force enable
ufw allow 22,25,80,443 # All allowed via both TCP/UPD as no restrictions were given;
apt update -y
apt upgrade unattended-upgrades sshguard
Après les réformes 2017-2018 W3C / Google (?) Concernant la prise en charge du navigateur dans HTTP, nous obligeant ou du moins nous encourageant tous à utiliser cryptage TLS = confirmé par un certificat SSL pour le transfert de données HTTP sécurisé (HTTPS), je me demande si le HTTP non sécurisé (généralement via le port 80) est toujours pertinent pour nous.
Remarques:
- Chacune de mes applications Web possède son propre certificat OpenSSL que je crée avec Certbot .
- Le seul utilitaire Web que j'utilise en dehors des sites Web est soit PHPMyAdmin/PHPMiniAdmin.
Ma question
Puis-je supprimer le port 80 de ufw allow 22,25,80,443 rendant ainsi mon système encore moins "vulnérable"?
Mise à jour par réponses
Les réponses recommandent de rediriger du port 80 vers le port 443 au lieu de simplement bloquer le port 80. Je pense que Certbot crée ces redirections automatiquement, donc je suis couvert si je garde le port 80 ouvert comme recommandé dans les réponses.
Google, le principal moteur de recherche d'Internet (éclipsant Bing et Yahoo) et le navigateur utilisé par la majorité des utilisateurs d'Internet, a fait pression pour un monde HTTPS uniquement en diminuant le classement des pages pour les sites qui ne sont pas HTTPS, et en ajoutant un avertissement du navigateur lorsqu'un site n'est pas sécurisé. Cependant, le rapport entre les sites HTTPS et non est encore beaucoup trop faible pour recommander une politique HTTPS d'abord pour tout le monde, car les utilisateurs obtiendraient constamment des messages "d'erreur de certificat" effrayants ou des erreurs de "connexion refusée".
Donc, jusqu'à ce que Google recommande une politique HTTPS d'abord pour les connexions de navigateur, il est peu probable que Firefox, Apple ou Microsoft recommandent de telles politiques non plus, et ce n'est pas probable jusqu'à ce qu'une majorité décente (peut-être 70% ou plus) des meilleurs sites sont compatibles HTTPS, ce qui représenterait une énorme augmentation par rapport aux ~ 50% des meilleurs sites qui ont aujourd'hui HTTPS .
La plupart des utilisateurs qui visitent intentionnellement ou accidentellement votre site HTTP, s'ils sont accueillis avec une erreur "connexion refusée", passeront probablement à un autre site. Je n'ai pas de bon moyen d'obtenir des chiffres concrets ici, mais il est probable que 70 à 90% des utilisateurs d'Internet ne comprendraient probablement pas que le site n'a pas de port HTTP sans redirection automatique; les autres sont probablement suffisamment compétents sur le plan technique pour réaliser qu'ils ont besoin de HTTPS, ou utilisent HTTPS Everywhere, et ne le remarqueraient pas de toute façon.
Utilisez certainement HSTS, certainement 301 redirigez vers les ressources HTTPS (le 301 indique un déplacement permanent vers les navigateurs, donc ils "se souviendront" de cette préférence), conseillez certainement à vos utilisateurs de s'assurer qu'ils voient un cadenas et vérifient le certificat, etc. Ne pas bloquez le port 80 à ce stade, car Internet n'est tout simplement pas encore prêt pour cela.
Pour autant que je sache, aucun site majeur n'a désactivé HTTP et bloqué le port 80. Si vous faites cela, vous allez briser les attentes des utilisateurs (que le site vous redirigera vers un site sécurisé), et comme la plupart des utilisateurs ne savent pas quoi faire ici, car ils n'obtiendront pas de message d'erreur convivial, supposeront simplement que votre site est en panne et passe à autre chose.
Vous ne devez pas fermer le port 80. Au lieu de cela, vous devez configurer votre serveur pour rediriger le port HTTP 80 vers le port HTTPS 443 afin d'utiliser TLS. Vous pouvez éventuellement utiliser HSTS (HTTP Strict Transport Security) pour indiquer aux navigateurs de se rappeler de n'utiliser TLS que lors de la connexion à votre site à l'avenir.
Il n'y a rien d'insécurité à propos de l'ouverture du port 80. Les problèmes de sécurité se produisent uniquement lorsque le serveur Web traite des demandes via une connexion non chiffrée, en particulier si ces demandes contiennent des données sensibles. Avoir le port 80 ouvert et envoyer rien de plus qu'une redirection HTTP est parfaitement sûr.
En bref: généralement, gardez-le ouvert et utilisez-le pour rediriger tout vers HTTPS .
Passons maintenant aux trucs compliqués : supprimer le port 80 peut empêcher les voleurs de cookies qui recherchent passivement des problèmes http://corp.com/some/forgotten/thing demandes. La connexion TCP échoue, le navigateur n'envoie pas le GET et les cookies, et le méchant ne peut pas les lire.
Parfois, c'est une chose raisonnable contre laquelle se protéger, en particulier en pensant aux environnements d'entreprise: applications héritées, HSTS seulement partiellement implémentées, cookies qui peuvent ne pas avoir drapeau ou chemin d'accès sécurisé ou restrictions d'hôte , tiers hébergés ou mandatés, ...
Maintenant, vous devrait-il le bloquer? Probablement pas.
Comme d'autres l'ont mentionné, cela compliquerait la configuration de Let's Encrypt et empêcherait les redirections (y compris les utilisateurs qui tapent simplement your.com dans la barre d'adresse). Si vous avez défini HSTS à l'échelle du domaine, la suppression des redirections peut même être considérée comme contre-productive (vous pouvez risquer un une simple connexion HTTP afin de protéger tous l'avenir ceux).
Notez également que les attaquants actifs ne seront pas arrêtés (ils peuvent établir la connexion artificiellement, les outils de proxy MITM peuvent même le faire par défaut), il existe des cas d'angle (proxy HTTP simples, domaines délégués en dehors de votre pare-feu), et vous pouvez simplement considérez l'attaque passive trop compliquée pour votre modèle.
Enfin, devez-vous ajouter le port 80 vers un nouveau serveur? Eh bien, à moins que vous n'ayez déjà une raison de l'ouvrir (voir ci-dessus), non.
En plus des autres réponses de forêt et de phyrfox, la vérification ACME http-01 utilise le port 80 pour atteindre vos serveurs. Si vous fermez le port, vous ne pourrez ni renouveler ni créer de certificats.
Je dis que c'est situationnel. Si votre site ne sert que de l'API, ou est un serveur de contenu principal ou de serveur de fichiers statique, où il est très peu probable que vos utilisateurs typiques vont taper l'adresse de votre serveur pour visiter votre site ou faire un signet sur la page (car l'adresse de ce serveur n'a jamais apparaît dans la barre d'adresse), il n'y a probablement aucun dommage qui pourrait être causé par la fermeture du port 80 pour ce serveur.
Si votre site est un nouveau site, sans historique de personnes utilisant votre site sur HTTP et sans signet existant ou si votre site ne contient pas de contenu que les gens sont susceptibles de partager en utilisant le lien, vous pouvez envisager de fermer le port 80.
Pour les serveurs qui servent votre page d'accueil, vous souhaiterez probablement conserver le port 80 pour l'instant, car ils sont beaucoup plus susceptibles d'être visités par des personnes tapant URL dans la barre d'adresse. De plus, si vous publiez votre adresse de page dans le monde physique (par exemple, dans des annonces physiques) ou sur un support où les gens ne peuvent pas facilement cliquer, vous pouvez conserver le port 80.