Exécuter apt-get upgrade de temps en temps est-il suffisant pour assurer la sécurité d'un serveur Web ?

Vous avez supprimé de nombreux problèmes qui vous causent normalement des ennuis (à savoir, en supposant que l'application que vous hébergez est complètement sécurisée). D'un point de vue pratique, vous devez absolument les considérer.

Mais probablement puisque vous en êtes conscient, vous avez mis en place des mesures de protection. Parlons du reste, alors.

Pour commencer, vous ne devriez probablement pas exécuter une mise à jour "de temps en temps". La plupart des distributions gèrent des listes de diffusion d'annonces de sécurité, et dès qu'une vulnérabilité y est annoncée, elle est plutôt publique (enfin, c'est souvent avant cela, mais dans votre situation, vous ne pouvez pas vraiment surveiller toutes les listes de sécurité du monde). Ce sont des listes à faible trafic, vous devriez donc vraiment vous abonner à vos distributions et les mettre à niveau lorsque vous en recevez des notifications.

Souvent, un serveur entretenu de manière informelle peut être brutalement attaqué ou attaqué par un dictionnaire sur une longue période, car le responsable ne recherche pas vraiment les signes. C'est une bonne idée alors d'appliquer les contre-mesures habituelles - pas d'authentification par mot de passe ssh, fail2ban sur ssh et apache - et idéalement de mettre en place des alertes de surveillance en cas d'activité suspecte. Si cela dépasse votre budget de maintenance (temps), prenez l'habitude de vous connecter régulièrement pour vérifier ces éléments manuellement.

Bien que cela ne soit pas traditionnellement considéré comme faisant partie de la sécurité, vous voulez vous assurer que vous pouvez mettre en place un nouveau serveur rapidement. Cela signifie des scripts de configuration de serveur (des outils comme Ansible, Chef, etc. sont de toute façon utiles dans l'administration système) et un système de sauvegarde automatique que vous avez testé. Si votre serveur a été piraté, vous devez supposer qu'il est compromis pour toujours et simplement l'effacer, et cela craint si vous n'avez pas effectué de sauvegardes régulières de vos données.

Non. Ce n'est pas assez pour vous garder en sécurité.

Cela vous gardera probablement en sécurité pendant un certain temps, mais la sécurité est complexe et rapide, donc votre approche n'est vraiment pas assez bonne pour la sécurité à long terme . Si tout le monde faisait les mêmes hypothèses que vous faites dans votre question, Internet serait désormais un gros botnet.

Alors non, ne limitons pas cette question aux packages. Examinons la sécurité du serveur de manière globale afin que quiconque lise ceci ait une idée du nombre réel de pièces mobiles.

• APT (par exemple, les dépôts d'Ubuntu) ne couvre qu'une partie de votre pile logicielle. Si vous utilisez (par exemple) Wordpress ou une autre bibliothèque PHP populaire et qui n'est pas contrôlée par le référentiel, vous devez également la mettre à jour. Les frameworks plus importants ont des mécanismes pour automatiser cela, mais assurez-vous de faire des sauvegardes et de surveiller l'état du service, car ils ne fonctionnent pas toujours bien.

• Tu as tout écrit toi-même donc tu penses être à l'abri des script kiddies ? Il y a des injections SQL automatisées et des bots d'exploitation XSS en cours d'exécution, explorant chaque chaîne de requête et chaque formulaire.

  C'est en fait l'un des endroits où un bon framework aide à se protéger contre les programmeurs inadéquats qui n'apprécient pas les nuances de ces attaques. Faire auditer le code par un programmeur compétent aide également à dissiper les craintes ici.

• PHP (ou Python, ou tout ce que vous utilisez) doit-il vraiment pouvoir écrire partout ? Renforcez votre configuration et vous atténuerez de nombreuses attaques. Idéalement, les seuls endroits où une application Web est capable écrire sont une base de données et des endroits où les scripts ne seront jamais exécutés (par exemple, une règle nginx qui permet uniquement de servir des fichiers statiques).

  Les valeurs par défaut de PHP (du moins comment les gens les utilisent) permettent à PHP de lire et d'écrire PHP n'importe où dans la racine Web. Cela a de sérieuses implications si votre site Web est exploité.

• Et votre calendrier de mise à jour est activement nuisible. Qu'est-ce que c'est "de temps en temps" ? Les bogues critiques de sécurité à distance ont une demi-vie courte, mais il y a déjà un délai entre le jour 0 et la disponibilité des correctifs, et certains exploits sont également inversés à partir des correctifs (pour attraper les ralentissements).

  Si vous n'appliquez les mises à jour qu'une fois par mois, il y a de fortes chances que vous exécutiez un logiciel exploitable dans la nature. TL ; DR :utiliser les mises à jour automatiques.

• Les versions des distributions ne durent pas éternellement. Si vous étiez sensé et que vous avez choisi une version LTS d'Ubuntu, vous avez 5 ans à compter de la sortie initiale. Deux autres versions LTS sortiront dans ce délai et cela vous donne des options.

  Si vous étiez sur un saccage "NEWER IS BETTER" et que vous avez opté pour 16.10 lorsque vous avez configuré votre serveur, vous avez 9 mois . Ouais. Ensuite, vous devez mettre à niveau jusqu'à 17.04, 17.10 avant de pouvoir vous détendre sur 18.04 LTS.

  Si votre version d'Ubuntu expire, vous pouvez effectuer une mise à niveau toute la journée, mais vous n'obtiendrez aucune mise à niveau de sécurité.

• Et la pile LAMP elle-même n'est pas le seul vecteur d'attaque contre un serveur Web standard.

  • Vous devez durcissez votre configuration SSH :uniquement utiliser les clés SSH, désactiver les mots de passe, dériver le port, désactiver les connexions root, surveiller les tentatives brutes et les bloquer avec fail2ban .
  • Pare-feu de tous les autres services avec ufw (et alii).
  • N'exposez jamais la base de données (sauf si vous avez besoin vers, puis verrouillez l'adresse IP entrante dans le pare-feu).
  • Ne laissez pas de scripts PHP installés au hasard, sinon vous le ferez oubliez-les et ils le feront se faire pirater.

• Il n'y a aucune surveillance dans votre description. Vous êtes aveugle. Si quelque chose se passe là-bas et commence à pomper du spam, à infecter vos pages Web, etc., comment pouvez-vous dire que quelque chose de mal s'est passé ? Surveillance des processus. Comparaison de fichiers planifiée avec git (assurez-vous qu'il s'agit d'un accès en lecture seule depuis le serveur).

• Tenez compte de la sécurité (physique et à distance) de votre FAI. Les dix « hôtes » (c'est-à-dire les pirates CPanel) — proposant des plans d'hébergement illimités à 2 $/mois — investissent-ils les mêmes ressources dans la sécurité qu'un serveur dédié ? Demandez autour de vous et enquêtez sur l'historique des violations.

• Et puis il y a vous . La sécurité de l'ordinateur sur lequel vous codez tout cela est presque aussi importante que le serveur. Si vous utilisez les mêmes mots de passe, vous êtes un handicap. Sécurisez vos clés SSH avec une clé physique FIDO-UF2.

Je fais des devops depuis environ 15 ans et c'est c'est quelque chose que vous pouvez apprendre sur le tas, mais il suffit vraiment d'une seule brèche - un adolescent, un bot - pour ruiner un serveur entier et causer des semaines de travail à désinfecter le produit du travail.

Être simplement conscient sur ce qui est en cours d'exécution et ce qui est exposé, vous aide à prendre de meilleures décisions sur ce que vous faites. J'espère juste que cela aidera quelqu'un à démarrer le processus d'audit de son serveur.

Mais si vous, le programmeur d'applications Web moyen ordinaire, ne voulez pas creuser dans ce genre de choses, devriez-vous même utiliser un serveur ? C'est une question sérieuse. Je ne vais pas vous dire que vous ne devriez absolument pas, mais que vous arrive-t-il lorsque vous ignorez tout cela, que votre serveur est piraté, que votre client perd de l'argent et que vous exposez des informations personnelles sur le client (par exemple, des données de facturation) et que vous êtes poursuivi ? Êtes-vous assuré pour ce niveau de perte et d'exposition à la responsabilité ?

Mais oui, c'est pourquoi les services gérés coûtent tellement plus cher que les serveurs stupides.

Sur la vertu des sauvegardes...

Une sauvegarde complète du système est peut-être la pire chose que vous puissiez conserver —pour la sécurité - parce que vous serez tenté de l'utiliser si vous vous faites pirater. Leur seule place est de se remettre d'une panne matérielle.

Le problème avec leur utilisation dans les hacks est que vous réinitialisez à un moment encore plus ancien. Pourtant, plus de défauts dans votre pile sont apparents maintenant, encore plus d'exploits existent pour le trou qui vous a eu. Si vous remettez ce serveur en ligne, vous pourriez être piraté instantanément. Vous pouvez pare-feu désactiver le trafic entrant et effectuer une mise à niveau du package et cela pourrait vous aider, mais à ce stade, vous ne savez toujours pas ce qui vous a eu, ni quand cela vous a eu. Vous basez toutes vos hypothèses sur un symptôme que vous avez vu (injection de publicité sur vos pages, spam renvoyé dans votre mailq). Le piratage aurait pu avoir lieu des mois avant cela.

Ils sont évidemment mieux que rien, et très bien dans le cas d'un disque en train de mourir, mais encore une fois, ils sont nuls pour la sécurité .

Les bonnes sauvegardes sont des recettes

Vous voulez quelque chose - juste un document en langage clair ou quelque chose de technique comme une routine Ansible/Puppet/Chef - qui peut guider quelqu'un pour restaurer l'intégralité du site sur un tout nouveau serveur. Points à considérer :

• Une liste des packages à installer
• Une liste des modifications de configuration à apporter
• Comment restaurer la source du site Web à partir du contrôle de version.
• Comment restaurer le vidage de la base de données* et tout autre fichier statique dont vous ne contrôlez peut-être pas la version.

Plus vous pouvez être verbeux ici, mieux c'est parce que cela sert également de sauvegarde personnelle . Mes clients savent que si je meurent, ils ont un testé prévoient de restaurer leurs sites sur du matériel qu'ils contrôlent directement.

Une bonne restauration par script ne devrait pas prendre plus de 5 minutes. Ainsi, même le décalage temporel entre une restauration par script et la restauration d'une image disque est minime.

Il y a de fortes chances que vous gardiez le serveur surtout sécurisé si vous exécutez souvent des mises à jour (c'est-à-dire au moins quotidiennement, au lieu de seulement "de temps en temps").

Mais des bogues critiques se produisent de temps en temps, comme Shellshock ou ImageTragick. Une configuration de serveur non sécurisée peut également rendre les attaques possibles. Cela signifie que vous devez également effectuer plus d'actions que la simple exécution de mises à jour régulières, telles que :

• réduire la surface d'attaque en exécutant un système minimal, c'est-à-dire n'installer aucun logiciel inutile
• réduire la surface d'attaque en restreignant tous les services accessibles de l'extérieur, c'est-à-dire ne pas autoriser la connexion SSH basée sur un mot de passe (uniquement basée sur une clé), ne pas exécuter de services inutiles, etc.
• Assurez-vous de comprendre l'impact des mises à jour critiques
• attendez-vous à ce que le système soit attaqué et essayez de réduire l'impact, par exemple en exécutant des services accessibles de l'extérieur à l'intérieur d'un chroot, d'une prison ou d'un conteneur
• enregistrer les événements importants tels que les échecs de connexion, comprendre les journaux et analyser réellement les journaux

Néanmoins, les vecteurs d'attaque initiale les plus utilisés sont probablement les applications Web non sécurisées telles que Wordpress ou d'autres CMS. Mais votre hypothèse était que l'application Web est entièrement sécurisée, alors j'espère qu'elle l'est vraiment.