Vous avez supprimé de nombreux problèmes qui vous causent normalement des problèmes (à 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 en tenir compte.

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 exploitent 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é dans le monde). Ce sont des listes à faible trafic, vous devriez donc vraiment vous abonner à votre distribution et la mettre à niveau lorsque vous en recevez des notifications.

Souvent, un serveur géré de manière informelle peut être forcé ou attaqué par dictionnaire sur une longue période du temps, puisque le mainteneur ne cherche 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 ne dépasse pas votre budget de maintenance (temps), prenez l'habitude de vous connecter régulièrement pour vérifier ces éléments manuellement.

Bien que ce ne soit pas traditionnellement considéré comme faisant partie de la sécurité, vous voulez vous assurer de pouvoir apporter un nouveau serveur rapidement. Cela signifie que les scripts de configuration du 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 suffisant pour assurer votre sécurité.

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

Donc non, ne limitons pas cette question aux paquets. Regardons la sécurité du serveur de manière holistique afin que quiconque lisant ceci ait une idée du nombre de pièces en mouvement qu'il y a réellement.

• 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 que celle-ci n'est pas contrôlée par dépôt, vous devez également la mettre à jour. Les plus gros frameworks ont des mécanismes pour automatiser cela, mais assurez-vous de prendre des sauvegardes et de surveiller l'état du service, car ils ne fonctionnent pas toujours bien.

• Vous avez tout écrit vous-même, donc vous pensez-vous que vous êtes à l'abri des enfants de script? Il y a des robots d'injection SQL automatisés et d'exploit XSS qui tournent partout, poussant toutes les chaînes de requêtes et toutes les formes.

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

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

  Le 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é.

  ^{Remarque: si vous bloquez l'accès en écriture, des choses comme WordPress ne pourront pas se mettre à jour automatiquement. Recherchez des outils comme wp-cli et faites-les fonctionner de manière planifiée.}

• Et votre calendrier de mise à jour est activement dangereux. Qu'est-ce que c'est que "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 0 jour et la disponibilité des correctifs, et certains exploits sont également inversés à partir de correctifs (pour attraper les pokes lents).

  Si vous N'appliquez des mises à jour qu'une fois par mois, il y a de fortes chances que vous exécutiez des logiciels exploitables dans la nature. TL; DR: utilisez les mises à jour automatiques.

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

  Si vous étiez sur un déchaînement "NEWER IS BETTER" et que vous êtes allé avec 16.10 lorsque vous avez configuré votre serveur, vous avez 9 mois . Ouais. Ensuite, vous devez mettre à niveau vers 17.04, 17.10 avant de pouvoir vous détendre sur 18.04 LTS.

  Si votre version d'Ubuntu expire, vous pouvez dist-upgrade toute la journée, vous n'obtiendrez cependant aucune mise à niveau de sécurité .

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

  • Vous vous devez renforcer votre configuration SSH: utilisez uniquement les clés SSH, désactivez les mots de passe, dérivez le port, désactivez les connexions root, surveillez les tentatives brutes et bloquez-les avec fail2ban .
  • Pare-feu hors de tout autre service avec ufw (et alii).
  • N'exposez jamais la base de données (sauf si vous avez besoin de , puis verrouillez l'adresse IP entrante dans le pare-feu).
  • Ne laissez pas les scripts PHP aléatoires installés ou vous les oublierez et ils être piraté.

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

• Considérez la sécurité (physique et distante) de votre FAI. Les «hôtes» à la douzaine de dollars (alias les pirates de CPanel) - qui offrent des plans d'hébergement illimités à 2 $ / mois - investissent-ils les mêmes ressources dans la sécurité qu'un serveur dédié? Renseignez-vous et examinez l'historique des violations.

  ^{Remarque: Une violation publiée n'est pas nécessairement une mauvaise chose. Les petits hôtes ont tendance à ne pas avoir de dossier et lorsque des choses sont introduites par effraction, il n'y a pas les "post-mortems" publics que de nombreux hôtes et services réputés effectuent.}

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

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

Simplement être conscient sur ce qui fonctionne 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 moyen d'applications Web - ne voulez pas vous plonger 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, votre serveur est piraté, votre client perd de l'argent et vous exposez des informations personnelles sur le client (par exemple, des données de facturation) et vous êtes poursuivi en justice ? Êtes-vous assuré pour ce niveau de perte et de responsabilité civile?

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

Sur la vertu de sauvegardes ...

Une sauvegarde complète du système est probablement la pire chose que vous puissiez conserver - pour la sécurité - car vous serez tenté de l'utiliser si vous êtes piraté. Leur seul endroit est la récupération après une panne matérielle.

Le problème avec leur utilisation dans des hacks est que vous 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 bloquer le trafic entrant et effectuer une mise à niveau du package, ce qui pourrait vous aider, mais à ce stade, vous Je ne sais 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 d'annonces sur vos pages, spam rebondi dans votre mailq). Le piratage aurait pu avoir lieu des mois avant cela.

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

Vous voulez quelque chose - juste un document en langage simple ou quelque chose de technique comme une routine Ansible / Puppet / Chef - qui peut guider quelqu'un à travers la restauration de l'ensemble site vers un tout nouveau serveur. Éléments à prendre en compte:

• Une liste de packages à installer
• Une liste de 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 tous les autres fichiers statiques dont vous ne pouvez pas contrôler la version.

Plus vous pouvez être détaillé ici, mieux c'est parce que sert de sauvegarde personnelle . Mes clients savent que si je meurs, ils ont un plan testé pour restaurer leurs sites sur du matériel qu’ils contrôlent directement.

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

^{* Remarque : les vidages de base de données doivent également être vérifiés. Assurez-vous qu'il n'y a pas de nouveaux utilisateurs administrateurs dans votre système ou de blocs de script aléatoires. C'est aussi important que de vérifier les fichiers source ou vous serez simplement piraté à nouveau.}

Il est fort probable que vous gardiez le serveur principalement sécurisé si vous exécutez des mises à jour souvent (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 prendre plus d'actions que de simplement exécuter des mises à jour régulières, comme:

• réduire la surface d'attaque en exécutant un système minimal, c'est-à-dire ne pas installer de logiciel inutile
• réduisez la surface d'attaque en restreignant tous les services accessibles de l'extérieur, c'est-à-dire n'autorisez pas la connexion SSH basée sur un mot de passe (uniquement basée sur une clé), n'exécutez pas de services inutiles, etc.
• assurez-vous de comprendre l'impact de les mises à jour critiques
• s'attendent à ce que le système soit attaqué et tente de réduire l'impact, par exemple en exécutant des services qui sont accessibles de l'extérieur à l'intérieur d'un chroot, d'une prison ou d'un conteneur
• consigner des événements importants comme échecs de connexion, comprendre les journaux et analyser les journaux

Pourtant, le vecteur d'attaque initial le plus utilisé est probablement des applications Web non sécurisées comme Wordpress ou d'autres CMS. Mais votre hypothèse était que l'application Web est entièrement sécurisée, donc j'espère qu'elle l'est vraiment.

La plupart des distributions Linux modernes sont livrées avec une sorte de solution de mise à jour automatique. Vous devriez envisager de l'activer sur vos serveurs. Cela réduira considérablement le temps que votre serveur sera vulnérable aux attaques.

Comme vous mentionnez Debian, vous devriez envisager de mettre en place des mises à jour sans assistance. RedHat a yum-cron, et Suse peut les obtenir via YaST.

Ces mises à jour sont normalement limitées aux correctifs de sécurité et ne risquent pas de casser votre système, mais ce n'est pas totalement impossible. En fin de compte, c'est à vous de pondérer les risques et les avantages de cette approche.

apt-get upgrade n'installe que les versions plus récentes des packages déjà installés. Il n'installe pas les packages qui ne sont pas actuellement installés, et il ne mettra pas à niveau un package déjà installé si la version la plus récente dépend d'un package qui n'est pas actuellement installé.

Dans Debian et Ubuntu, chaque version du noyau est placé dans un package séparé, avec la version incluse dans son nom. De plus, il existe un package virtuel qui dépend toujours du dernier noyau disponible, la dépendance étant modifiée à chaque version. Par exemple, comme pour le moment, linux-image-generic dans xenial dépend de linux-image-4.4.0-63-generic . Ce schéma permet de conserver les anciennes versions des noyaux installées, et au cas où la plus récente s'avère incompatible avec votre matériel.

Cependant, cela signifie que apt-get upgrade ne sera pas installé noyaux plus récents - vous avez besoin de apt-get dist-upgrade pour cela. Cependant, de nombreuses personnes évitent de l'utiliser automatiquement car il peut également supprimer des paquets. Dans les versions plus récentes d'Ubuntu, vous pouvez utiliser apt upgrade , qui installe de nouvelles dépendances, mais ne supprime jamais aucun paquet.

De plus, lorsque vous mettez à niveau OpenSSL, vous devez au moins recharger le les services qui utilisent cette bibliothèque; dans Ubuntu, le système demande simplement le redémarrage pour rester prudent, et de nombreuses personnes ont également des réserves contre les redémarrages automatiques.

Il y a déjà de bonnes réponses ici. Cependant, je voulais combler certaines lacunes et souligner quelques points qui ne semblent pas être abordés dans certaines des réponses existantes.

Pas directement ciblé par un super-hacker ou une organisation gouvernementale etc

C'est une perspective dangereuse. De nombreuses petites organisations ont été contraintes à la faillite en raison de variations de cette idée fondamentale. Vous ne pouvez vraiment pas prédire qui trouvera une utilisation ou une raison pour pirater votre serveur. C'est précisément en raison de ce type d'hypothèse sous-jacente qu'un gouvernement ou un super pirate pourrait cibler votre système. Ils peuvent ne pas être intéressés par votre application ou vos données, ils peuvent simplement vouloir un point de départ innocent à utiliser dans le cadre d'un piratage plus grand ou plus complexe sur une cible plus précieuse.

Normal LAMP Web -serveur exécutant l'application Web. (Par exemple, AWS EC2 + Apache2 + MySQL + Php7)

Méfiez-vous de «normal». Votre configuration n'est peut-être pas aussi normale que vous le pensez. Cela dépend beaucoup de ce que vous avez installé et de quels référentiels provient le paquet. Certaines des variations à connaître incluent -

• Type de distribution. Par exemple, il existe une grande différence entre les distributions Ubuntu LTS et non-LTS. En règle générale, les distributions non LTS auront généralement des mises à jour plus fréquentes et il sera important d'effectuer les mises à jour (ou de revoir les mises à jour - voir ci-dessous) plus fréquemment.

• Type de référentiel. La plupart des distributions, y compris Ubuntu, ont différents types de référentiels. Il existe les référentiels de base maintenus par Ubuntu qui passent généralement par des cycles de test assez robustes et qui reçoivent des mises à jour assez rapidement. Ensuite, il y a des dépôts de type «contrib» qui ne sont pas maintenus par l'équipe de distribution principale. Il peut s'agir de partenaires tiers ou d'autres utilisateurs ou groupes de développement. L'accent mis sur ces référentiels peut varier considérablement. Parfois, ils mettront l'accent sur la sécurité et une concentration moindre sur la stabilité, d'autres se concentreront sur la sursécurité de la stabilité. Il est important de connaître / comprendre les référentiels à partir desquels vous avez installé des logiciels.

• Sachez ce qui est installé. Trop souvent, vous entendez parler d'un système qui a été compromis uniquement pour trouver que le compromis s'est produit dans un paquet négligé - soit celui installé par défaut, soit celui qui est requis par la pile LAMP, mais qui est une dépendance profondément enfouie ou subtile dont vous n'étiez pas conscient de. Assurez-vous que vous avez supprimé tous les paquets inutiles (quelque chose qui peut être difficile à déterminer d'autant plus que certains paquets ont des dépendances inhabituelles).

• Bibliothèques auxiliaires. Il est courant d'oublier les bibliothèques supplémentaires qui ont été installées, mais qui ne sont pas gérées par l'écosystème apt. Par exemple, une bibliothèque PHP était nécessaire à des fins spéciales qui ne figuraient pas dans la charge standard des distributions ou qui devaient être construites sur le système en raison d'autres dépendances. Un exemple courant est celui des pilotes de base de données PHP pour les bases de données commerciales. Bien que les choses se soient probablement améliorées depuis la dernière fois que j'ai eu à gérer une pile basée sur PHP, je me souviens d'une époque où vous deviez créer le pilote PHP pour Oracle. Alors que le processus était relativement simple, vous deviez vous rappeler de reconstruire ce pilote après la mise à niveau des bibliothèques dépendantes pour vous assurer que la bibliothèque était liée à la version corrigée. Cela peut également être un problème avec des choses comme openSSL. Une distribution peut installer une version mise à niveau de la bibliothèque partagée, mais vous devrez peut-être prendre des mesures supplémentaires pour vous assurer que votre application utilise réellement la bibliothèque mise à niveau et non l'ancienne bibliothèque avec une vulnérabilité connue.

Vous devriez vérifier les mises à jour quotidiennement, puis revoir ces mises à jour pour évaluer leur importance et le potentiel de briser votre système. Bien que le processus de mise à jour adaptative d'Ubuntu soit assez robuste et casse rarement les choses, cela se produit de temps en temps. En raison de l'accent mis sur la stabilité, en particulier pour les LTS versions, le processus de mise à jour aura tendance à être conservateur, vous devez donc revoir et pas seulement exécuter la mise à niveau apt-get. Par exemple, en raison d'éventuels problèmes de dépendance et de la possibilité d'instabilité ou de rupture, vous devrez parfois faire une «mise à niveau dist». Ubuntu le fera délibérément pour indiquer clairement que vous devez faire attention, c'est-à-dire que la mise à niveau d'apt-get peut être fiable pour ne pas casser les choses, mais peut ne pas installer tous les correctifs de sécurité. apt-get dist-upgrade travaillera plus dur pour s'assurer que toutes les mises à jour de sécurité sont appliquées, mais peut casser des choses, donc l'administrateur doit faire plus attention.

Le malheur est qu'il n'y a pas de véritables raccourcis ici. La réalité est que vous vous trouvez dans une situation imparfaite où vous êtes un développeur qui travaille pour une petite entreprise qui ne peut pas se permettre d'employer à la fois un développeur et un administrateur dédié. Vous devez utiliser vos ressources limitées de manière à minimiser les risques pour l'entreprise et à vous assurer que l'entreprise sait quels sont ces risques et comprend les probabilités et les conséquences - elle doit être dans une position éclairée et savoir qu'elle a pris la décision en connaissance de cause. J'espère pour le meilleur, mais assurez-vous d'avoir prévu le pire. Ayez des sauvegardes fiables et testées. Sachez ce qu'une mise à jour fera avant d'appliquer la mise à jour. Surveillez les listes de sécurité pour être au courant des menaces nouvelles et émergentes et être en mesure d'évaluer votre exposition et d'examiner les journaux pour confirmer vos hypothèses. Vérifiez les mises à jour quotidiennement. Il est tout à fait légitime de décider de ne pas appliquer les mises à jour quotidiennement, mais seulement après avoir évalué ce qu'elles sont et ce qu'elles corrigent et être en mesure de prendre la décision en connaissance de cause.

En relation avec le point ci-dessus, aucune ingénierie sociale et l'application Web elle-même n'est sécurisée.

Croire que vous savez et savoir peut être des mondes séparés. J'ai perdu le compte du nombre de fois où une évaluation de sécurité a révélé des vulnérabilités dont je n'étais pas au courant. Il est fort probable qu'il existe des vulnérabilités dans PHP (ou tout autre couche impliquée) qui n'ont pas encore été découverts - ou pire, ont été découverts par les mauvaises personnes et ne sont pas encore largement connus. Lorsque les professionnels de la sécurité évaluent une application, ils ne déclareront jamais qu'elle est sûre. Ils diront qu'aucune vulnérabilité n'a été détectée, mais cela ne signifie pas qu'il n'existe pas.

Ceci est certainement une bonne pratique et devrait faire partie de la routine de sécurité de votre serveur. Il est difficile de dire si votre plan de sécurité a besoin de plus que cette seule pratique, mais je n'ai jamais vu et je ne peux penser à aucun bon plan de sécurité qui ne repose pas sur cela.

Ne pas appliquer de correctifs aux logiciels et services installés est un risque élevé pour la sécurité car les bogues et vulnérabilités découverts dans ces paquets peuvent souvent entraîner un accès complet à la boîte en exploitant. C'est l'une des premières, sinon la première, chose qu'un attaquant tentera.

Mais les erreurs de configuration du système sont également l'un des principaux moyens par lesquels les attaquants compromettent les systèmes. Corriger le logiciel seul ne corrigera pas nécessairement les erreurs de configuration. Parfois, cela se produit, mais ce serait parce que la mauvaise configuration est née de l'installation d'origine de l'application.

Une chose à vérifier est si l'un de vos services s'exécute en tant que root. Il n'y a pas beaucoup de cas où c'est une bonne idée, mais il arrive qu'un service fonctionne en tant que root parce que la personne qui l'a installé ne savait pas mieux, ou ils ne pouvaient pas le faire fonctionner en tant que non- utilisateur root. Ce n’est qu’un exemple.

Quel que soit le système d'exploitation utilisé, il y aura des meilleures pratiques sur la façon de renforcer le système d'exploitation. Commencez par là, puis durcissez spécifiquement tous les services / packages installés, tels que MySql, apache, etc.

Si lors du déploiement, le système d'exploitation et tous les services ont été spécifiquement effectués conformément aux meilleures pratiques, l'application des correctifs peut être la seule chose que vous devez faire.

Je dis peut-être parce que ce n'est toujours pas une certitude. Cela dépendrait des processus de changement et si les processus couvrent le maintien d'une sécurité appropriée. Les changements proposés sont-ils examinés pour la sécurité? Les contrôles incluent-ils des tests spécifiques à la sécurité? La réponse à ces questions est généralement non et par conséquent, des erreurs d'un administrateur peuvent se produire et ne pas être détectées.

En gros, vous ne pouvez pas sécuriser un serveur Web. Il y a des exploits de 0 jour, qui peuvent être corrigés quelques heures après la découverte, mais qui ont déjà été exploités à ce moment-là. Une bonne société d'hébergement pourrait être en mesure d'agir très rapidement face à de telles menaces. Cependant, un serveur géré coûte cher (en supposant que le personnel de gestion de l'hébergeur vaut quelque chose). Ils peuvent toutefois décider de mettre le serveur hors ligne au cas où ils décideraient que cela est nécessaire pour éliminer une menace actuelle, en donnant la priorité à la sécurité , et non à la disponibilité - ce qui pourrait être faux genre de sécurité si vous avez besoin de la boîte en place et réactive à tout moment. Combien d'argent et combien de vies perdez-vous par heure de panne?

Des fuites de données peuvent également se produire ailleurs. Les sauvegardes sont-elles stockées en toute sécurité? (sécurisé contre l'accès à distance et physique; dans un cas, j'ai pu démontrer l'exfiltration de données non pas du site Web en direct, mais des sauvegardes) Avec quelle facilité quelqu'un peut-il pénétrer dans la salle des serveurs? Il n'est pas nécessaire qu'un super-criminel comme Lex Luthor vous attaque directement (après tout, il est juste après les 40 gâteaux), mais vous pouvez être des dommages collatéraux. Et, oui, j'ai vu des fermes de serveurs secrets (cas 1: accidentellement ouvert la mauvaise porte, qu'apparemment un idiot avait oublié de verrouiller et un autre idiot avait décidé d'avoir une poignée de porte à l'extérieur, cas 2: voulait le savoir pourquoi il y avait tant de chaleur effrayante venant de derrière le panneau de particules, dans une installation de stockage partagée où l'on pouvait espacer d'un mètre carré). En théorie, exploité par des entreprises professionnelles, en pratique ... eh bien. On pourrait saisir l'opportunité, lever quelques serveurs ou lecteurs, les vendre sur eBay et bonne chance après ça.

Les attaques à distance contre l'infrastructure sont souvent négligées. Strictement parlé, cela n'a rien à voir avec le niveau de sécurité du serveur, mais si quelqu'un attaque l'infrastructure de gestion ou le proxy qui sert les packages logiciels pour vos mises à jour apt-get, la sécurité se dégrade encore d'une manière ou d'une autre. Oui, certaines personnes font de telles choses pour le plaisir.

Je suppose qu'AWS EC2 est raisonnablement sûr en ce qui concerne de tels scénarios, mais AWS EC2 n'est fourni qu'à titre d'exemple, pas comme un fait dans les OP question (contrairement à l'affirmation selon laquelle l'application Web elle-même est sûre - c'est probablement pour nous empêcher de discuter de toutes nos histoires de guerre sur l'injection SQL, etc.).