Question:
Solution d'hébergement résistante au piratage pour une organisation à but non lucratif?
user249493
2016-03-09 08:49:15 UTC
view on stackexchange narkive permalink

(Bien que les réponses et les commentaires sur Comment gérer un serveur compromis? sont utiles, ma question porte davantage sur la prévention du piratage lorsque je n’exerce pas un contrôle total (ou important) sur le serveur. J'ai un accès SSH mais pas les privilèges root. Je ne peux rien voir ou changer quoi que ce soit en dehors de mon propre compte utilisateur.)

Je fais du bénévolat pour une organisation à but non lucratif, maintenant leur site Web pour eux. Nous sommes sur une plateforme d'hébergement mutualisé à petit budget (Bluehost) depuis plusieurs années. Le site a été construit sur Wordpress et j'ai fait de mon mieux pour garder le noyau WP et tous les plugins à jour.

Mais nous avons été piratés plusieurs fois. Parfois, c'était malveillant (dégradant la page d'accueil) tandis que d'autres fois c'était furtif (j'ai découvert des fichiers cachés qui semblaient simplement permettre à quelqu'un d'entrer et de fouiner).

Je me suis totalement débarrassé de WP, en reconstruisant le site sur Bootstrap. J'ai supprimé tous les fichiers du serveur, exécuté plusieurs analyses antivirus sur la version locale du nouveau site, effectué une recherche sur tout ce qui serait suspect, puis j'ai téléchargé les fichiers sur le serveur. J'étais presque sûr à 100% que cette nouvelle base de code était "propre".

Mais en quelques jours, j'ai découvert (en comparant le serveur à ma version locale) un index.php piraté (certains 'preg-replace 'code a été inséré avant la première ligne) et a trouvé un fichier "logo-small.png" dans un sous-répertoire qui n'était pas vraiment un fichier image. C'était un gros morceau de PHP obscurci qui semblait prêt à faire des choses désagréables (j'ai désobscurci et visionné le code).

Je savais que les hôtes partagés, souvent avec des centaines de sites, pouvaient être vulnérables. À ce stade, je me méfie totalement du serveur sur lequel nous sommes. Mais quand j'ai demandé à Bluehost si nous serions plus en sécurité sur un VPS ou un serveur dédié (en pensant que notre "bac à sable" serait plus difficile d'accès), ils ont dit que cela ne ferait pas vraiment de différence.

Je suis donc dans un dilemme. L'asbl que j'aide a un budget limité. Mais je ne veux pas non plus continuer à passer des dizaines à des centaines d'heures à surveiller et à réparer le site. Je ne sais pas si les pirates entrent via le système de fichiers ou un port ouvert qui ne devrait pas être ouvert.

Existe-t-il une solution rentable offrant un bien meilleur «durcissement»?

Les serveurs Web pour les petits sites n'ont pas besoin d'une tonne de matériel. Certains de vos membres ont-ils un ancien PC qu'ils n'utilisent jamais et sont prêts à faire un don? Installez Ubuntu dessus et commencez à exécuter nginx ou Apache dessus et vous n'aurez plus à faire confiance à personne d'autre. Pour un site Web plus petit avec un budget limité, mais aussi pour une personne soucieuse de la sécurité qui travaille à la maintenance du serveur, c'est probablement le meilleur pari. S'il s'agit d'un site plus grand que ce type de site, ne tenez pas compte de ce commentaire.
Copie possible de [Comment gérer un serveur compromis?] (Http://security.stackexchange.com/questions/39231/how-do-i-deal-with-a-compromised-server)
Jusqu'à ce que vous en appreniez plus sur la sécurité des serveurs, vous allez être piraté. Aucune solution serveur n'est a priori à l'épreuve des hackers, il faut comprendre et mettre en œuvre toutes les étapes répertoriées dans les tutoriels de renforcement et les guides de sécurité. En bref: la sécurité commence dans votre tête, pas sur un serveur tiers.
@DeerHunter: Cela suppose qu'il contrôle le serveur Web. S'il s'agit d'un hébergement partagé (comme mentionné), vous n'avez pas de chance.
Ne semble pas être un double de [Comment gérer un serveur compromis?] (Http://security.stackexchange.com/questions/39231/how-do-i-deal-with-a-compromised-server) tome. OP de cette question essaie de comprendre la sécurité des différentes options d'hébergement, pas comment rectifier une brèche de serveur.
Par intérêt, la chose «preg-replace» [semble être assez courante] (http://security.stackexchange.com/questions/114919/found-suspicious-obfuscated-php-file-is-this-a-hack -tentative-sur-mon-site)
La génération de sites statiques est certainement la voie à suivre, * en particulier * si vous pouvez utiliser un fournisseur d'hébergement où vous êtes colocalisé uniquement avec d'autres clients uniquement hébergés statiques (donc personne assis à côté de vous sur la même machine n'exécute du code potentiellement vulnérable Soit). Voir https://www.staticgen.com/ pour une liste d'options populaires concernant les outils de génération de site open source.
@Oasiscircle Cela nécessite alors que l'hébergeur ait un téléchargement assez rapide qu'il serait prêt à partager avec le site. L'exécution d'un serveur enfreint également à peu près les conditions de service de tous les FAI pour Internet client (vous pouvez vous en tirer en fonction du FAI).
Une possibilité est que le problème ne vient pas de l'hébergement mais de votre ordinateur. Certains virus peuvent voler vos informations d'identification FTP et télécharger des fichiers sur votre hébergement. Avez-vous changé les mots de passe à chaque fois que le site Web était * piraté *?
Je vais recommander [Jekyll] (https://jekyllrb.com/), un ** générateur de site statique **, si vous ne faites que servir des pages statiques (on dirait que vous l'êtes). Vous avez dit que vous avez réécrit le site en utilisant Bootstrap, donc je suppose que vous n'êtes pas un peu nouveau dans le codage. Jekyll est incroyablement simple et n'a pas vraiment beaucoup de codage à moins que vous ne vouliez faire des choses fantaisistes. Fondamentalement, vous écrivez simplement des pages Web dans Markdown (comme Stack Exchange) et cela génère un site. Il peut également être hébergé gratuitement sur [Pages Github] (https://jekyllrb.com/docs/github-pages/). Cela vaut peut-être la peine de regarder si vous avez une heure!
La rentabilité dépend de votre budget. Si vous êtes grand comme la Croix-Rouge ou certaines dénominations d'églises, une solution de cloud privé virtuel pourrait fonctionner pour vous. Si vous êtes une petite organisation à but non lucratif, l'hébergement Google peut être suffisant.
Avez-vous changé les mots de passe du compte après le premier compromis?
À moins que vous ne sachiez ce que vous faites, le VPS est ** beaucoup plus difficile ** à sécuriser qu'un hébergement partagé compétent.Un VPS vous donne beaucoup plus de liberté pour configurer votre serveur et beaucoup plus de façons de faire des erreurs.Je ne connais pas un BlueHost, mais un hôte partagé configuré par un administrateur système compétent ne serait pas plus sécurisé qu'un VPS car ils configureraient leurs serveurs de telle sorte que la compromission d'un site n'affecterait pas les autres sites sur le même hôte.
Neuf réponses:
WoJ
2016-03-09 13:33:23 UTC
view on stackexchange narkive permalink

Si la seule chose que vous exposez à Internet sont des pages Web non interactives et que vous n'avez pas besoin d'exécuter des composants côté serveur, vous pouvez réduire considérablement vos risques en utilisant un site Web statique.

Il vous reste alors le moteur Web lui-même et dans une certaine mesure le système d'exploitation sous-jacent. Apache ou nginx ne sont pas simples à renforcer, vous pouvez donc jeter un œil à Cherokee ou publicfile.

Vous pouvez aller plus loin en hébergeant votre des fichiers statiques sur un environnement existant qui les accepte ( Pages Github par exemple) ou déplacez-vous vers un site que vous créez avec des blocs comme Google Sites (qui sont gratuits pour non à but lucratif).

Vous pouvez même utiliser AWS S3 pour l'hébergement de sites statiques et ne plus jamais avoir à vous soucier de la sécurisation du serveur. Ils prennent même en charge l'utilisation de vos propres domaines: http://docs.aws.amazon.com/AmazonS3/latest/dev/WebsiteHosting.html
Jeroen
2016-03-09 11:04:40 UTC
view on stackexchange narkive permalink

Le problème avec l'hébergement mutualisé est que:

  1. Vous dépendez de tous les sites Web qui maintiennent leur code à jour. Il est possible qu'un autre compte soit compromis, ce qui permet à un attaquant d'accéder à votre partie du serveur Web. Il y a plusieurs façons d'accomplir cela, en particulier si un panneau de contrôle comme Direct Admin est installé.

  2. Lorsque j'achète un espace Web sur le même serveur, en tant que pirate informatique sur Je pourrais simplement (dans votre cas) télécharger un shell Web PHP et (éventuellement) accéder à tous les sites Web situés sur ce serveur. Cela est même possible si les autorisations de fichiers sont correctement configurées.

La solution n'est pas d'utiliser l'hébergement Web partagé.

Je vous suggère d'acheter un VPS. Un bon VPS (6 Go de RAM - disques SSD) peut être acheté pour 7 $ par mois. Je pourrais vous donner le lien si vous le souhaitez, mais je ne veux pas en faire la publicité ici. De cette façon, vous contrôlez mieux ce qui se passe.

"télécharger un shell Web PHP et (éventuellement) accéder à tous les sites Web situés sur ce serveur" est-il vraiment aussi simple d'accéder à tous les autres sites Web sur le même serveur? Je suppose que pour que cela fonctionne, il doit y avoir une mauvaise configuration du serveur pour permettre une telle chose?
Je sais qu'avec Direct Admin (hors de la boîte) cela fonctionne. Mais il existe d'autres moyens d'énumérer des répertoires personnels / noms de domaine valides lorsque le shell est sur le serveur lorsque ces autorisations sont un peu plus strictes.
Il existe des options d'hébergement partagé où vous pouvez héberger votre site sur un cluster où aucun compte utilisateur sur le même système n'aura de fonctionnalités non statiques disponibles, ce qui soulève certaines de vos préoccupations.
Je sais que vous ne voulez pas en faire la publicité, mais à quel VPS faites-vous référence? "Un bon VPS (6 Go de RAM - disques SSD) peut être acheté pour 7 $ par mois."
Google "VPS Dime" et vous le trouverez.
"Je pourrais simplement (dans votre cas) télécharger un shell Web PHP et (éventuellement) accéder à tous les sites Web situés sur ce serveur. Ceci est même possible si les autorisations de fichier sont correctement configurées" - alors dites-vous que les prisons sont intrinsèquement cassées ou simplement que certains hébergeurs ne les utilisent pas ou les configurent mal (y a-t-il beaucoup de choses à mal configurer? me semble simple)? Je ne suis pas vraiment à la pointe des exploits actuels, mais j'ai supposé qu'ils fonctionnaient comme annoncé, à part d'éventuels bogues dans certaines implémentations qui ne peuvent jamais être exclus.
Bien que de nombreux hébergeurs proposent maintenant des moyens de l'empêcher pour la raison que Jeroen a mentionnée, il est généralement aussi simple que de faire en sorte qu'un script PHP récupère le contenu de ../ S'il est mal configuré, cela renvoie une liste de répertoires d'autres clients. Donc, si un client avait le répertoire de billysautoshop.com, je pourrais simplement créer un script de téléchargement PHP sur mon compte qui télécharge index.php sur ../billysautoshop.com Et parfois vous pouvez le faire pour obtenir un accès complet à la racine du serveur. Ce n'est probablement pas le cas avec son hôte actuel, mais j'imagine que de nombreux hôtes moins connus / inexpérimentés sont toujours affectés.
Ce qui précède est également connu comme une attaque par traversée de répertoire.
Les installations standard prêtes à l'emploi de Direct Admin ne sont pas emprisonnées (il y a au moins quelques années). Ceux qui avaient des problèmes d'autorisation, j'ai créé un script qui lirait le / etc / passwd pour obtenir tous les noms d'utilisateur (/ home / $ username) et le fichier / etc / bind / domains (ou quoi que ce soit). En utilisant une boucle, j'ai cherché s'il était possible de lire /home/$user/$domain/public_html/index.php. De cette façon, il était possible d'énumérer tous les chemins valides sur un système. En utilisant un shell Web, je pouvais lire tous les fichiers config.php et en retour, j'avais accès à toutes les bases de données (légalement bien sûr)
Tim Seed
2016-03-09 21:38:38 UTC
view on stackexchange narkive permalink

Passer à un système de page statique. J'avais aussi WordPress - mais après avoir été piraté 2 fois par "l'armée syrienne libre" (dans un effort pour promouvoir leur situation ...) j'en ai eu marre de Wordpress et j'ai utilisé Nikola .

Simple et facile - Pages Web statiques .... pas de comptes / ports / vulnérabilités SQL etc.

Il y en a d'autres (Forks du même) - cherchez aussi Pelican.

Armée syrienne libre ou armée électronique syrienne? Jamais entendu parler du piratage d'un site par la FSA.
@StackOverflowed C'était en fait le Front populaire de Judée ...
@Mason Je pense que vous voulez dire le Front populaire de Judée ... [pas ces autres scélérats] (https://www.youtube.com/watch?v=vPyiUePXuGQ).
@Mason idem StackOverflowed Très drôle
Vegard
2016-03-09 16:29:55 UTC
view on stackexchange narkive permalink

Digital Ocean propose des machines virtuelles dédiées pour aussi peu que 5 $ / mois. Cela serait comparable à un serveur dédié en termes de comparaison de la solution à VPS.

Le problème sera le plus souvent votre solution logicielle utilisée dans la diffusion réelle du contenu, cependant. Le durcissement des fichiers de configuration de la suite choisie n'est pas trivial, sauf si vous avez de l'expérience avec ce genre de choses.

Le renforcement du serveur en tant que sujet général est énorme, mais si vous avez délimité un ensemble particulier de programmes que vous souhaitez utiliser, Google et ServerFault.SE auront probablement de nombreux conseils sur la façon de les verrouiller. .

Ou comme WoJ le suggère, vous pouvez utiliser une solution d'hébergement plus pré-construite.

L'océan numérique est génial!C'est super facile à installer et si vous êtes étudiant, vous obtenez un coupon de 50 $: D
tylerl
2016-03-11 08:14:11 UTC
view on stackexchange narkive permalink

En règle générale, ce n'est pas l ' hébergeur qui est piraté, c'est votre site. Si vous avez un site sûr, un simple VPS peut vous protéger.

En supposant que vous n’avez pas besoin que votre contenu réponde différemment aux différents visiteurs, un générateur de site statique fonctionnera pour vous. En règle générale, ils sont un peu comme wordpress en ce sens que vous écrivez votre propre contenu personnalisé et qu'il est transformé en site à thème, mais c'est différent en ce que le générateur vit sur votre ordinateur (pas sur le serveur Web) et la seule chose sur le serveur est HTML statique.

Il n'y a donc rien à pirater. Ce n'est pas vivant. Le serveur ne peut rien faire . C'est juste du contenu.

Si vous voulez mettre cela sur votre propre VPS, vous pouvez en obtenir un chez Linode ou Digital Ocean, ou si vous vous sentez courageux, AWS ou Google Compute. Le serveur de niveau le plus bas à tous ces endroits coûte environ 5 $ / mois, ce qui est suffisant pour vos besoins.

Vous pouvez même héberger un tel site sur Pages Github sans aucun frais. .

Finn Årup Nielsen
2016-03-10 16:35:06 UTC
view on stackexchange narkive permalink

Si vous avez déjà de l'expérience avec Wordpress, pourquoi ne pas simplement utiliser le cloud wordpress.com. Espérons qu'ils s'occuperont de l'administration du système, y compris de la sécurité. Il vous suffit de garder le mot de passe en sécurité et d'exporter / sauvegarder régulièrement vos publications. Vous êtes bien sûr à la merci de l'entreprise, - mon blog a été bloqué une fois, mais j'ai réussi à les convaincre de l'ouvrir à nouveau. De plus, tous les plugins dont vous avez besoin ne sont peut-être pas là. Il pourrait également y avoir des problèmes de confidentialité, la question du nom de domaine de votre organisation à but non lucratif et des publicités que wordpress.com pourrait mettre sur votre page d'accueil.

Tim X
2016-03-11 07:26:51 UTC
view on stackexchange narkive permalink

Il y a beaucoup de bons conseils dans les réponses. Cependant, le conseil le plus important est peut-être de n'utiliser qu'une société d'hébergement ayant une bonne réputation. Ne basez pas votre décision sur le coût et optez pour un site à budget basé uniquement sur ces critères.

La réalité est que la gestion d'une société d'hébergement implique des frais de maintenance considérables. Pour réaliser des bénéfices suffisants, des réductions doivent être effectuées quelque part. Malheureusement, ces réductions sont souvent appliquées aux processus de gestion des risques, car il n'y a pas de relation 1 pour 1 évidente entre les dépenses et les recettes. Le résultat est que la sécurité en souffre souvent.

Les grandes organisations où la reutaiton est considérée comme un aspect important de leur rentabilité dépenseront probablement plus dans ces domaines. Ils ont également l'avantage de pouvoir profiter d'économies d'échelle. Si vous n'êtes pas en mesure de gérer vous-même les risques de sécurité, vous devez vous fier à votre hébergeur.

Plusieurs réponses suggèrent d'utiliser un site statique plutôt que wordpress. Un site statique peut aider, mais bien sûr, si le serveur est compromis, cela fait peu de différence. Cependant, les frameworks dynamiques mal entretenus qui ne sont pas mis à jour seront toujours plus risqués qu'un site statique avec la même sécurité d'hébergement.

Wordpress est une solution à haut risque. Il est activement ciblé et il existe un certain nombre de faiblesses dans le système de plugins. Même si vous gardez les plugins à jour, il n'y a aucune garantie. Cette semaine seulement, il y a eu un rapport sur un plugin populaire qui présente des failles de sécurité importantes qui ont été délibérément ajoutées par le nouveau responsable du plugin (c'est un problème courant avec les architectures de plugin - les plugins chrome souffrent du même problème. Vous êtes conscient de la sécurité, vous vérifiez donc les références, la réputation et les rapports des utilisateurs pour un plug-in. Tout semble bon et le développeur a une bonne réputation, alors vous l'installez. Plus tard, le développeur passe à autre chose - soit en vendant le plug-in, soit en le remettant il est confié à une personne qui n'est peut-être pas aussi éthique. Il n'y a aucun mécanisme pour vous alerter de cette modification. Le nouveau propriétaire pose problème et la mise à jour contient un code malveillant. Vous appliquez la mise à jour (ou peut-être que la mise à jour est appliquée automatiquement). game over ).

Si vous ne pouvez pas simplement utiliser un site statique, envisagez peut-être d'utiliser autre chose que wordpress qui n'est pas aussi activement ciblé. ce ne sera pas pratique car cela signifie probablement apprendre un nouveau cadre, mais peut fournir une protection supplémentaire.

L'autre chose à considérer sérieusement, surtout si le budget est tout simplement insuffisant, est de revendre votre réputation de site Web à but non lucratif. Il y a un coût associé à la présence sur le Web. Si l'organisation à but non lucratif ne peut pas se permettre le coût d'un site suffisamment sécurisé, soit elle doit accepter le risque d'être piratée, soit elle doit réduire sa présence sur le Web à quelque chose qu'elle est prête à financer. En général, il existe peu de solutions de sécurité `` bon marché '' - vous en avez pour votre argent (vous pouvez payer trop cher - en particulier avec certains des marchands d'huile de serpent attirés par l'espace de sécurité lucratif, mais si vous faites vos recherches, recherchez de bonnes références. / arbitres, rappelez-vous qu'il n'y a pas de déjeuner gratuit et si cela semble trop beau pour être vrai, ce n'est probablement pas le cas, bla bla bla, vous serez généralement OK).

Ángel
2016-07-03 04:21:43 UTC
view on stackexchange narkive permalink

Tout d'abord, je dois noter que je ne suis pas d'accord avec la prémisse d'être vulnérable simplement pour être sur un hôte partagé. Si votre compte d'hébergement partagé est compromis par un autre utilisateur, c'est parce que soit:

  • La société d'hébergement n'a pas correctement isolé les utilisateurs
  • L'utilisateur a fait quelque chose de stupide (comme ayant 777 fichiers)

Avec un VPS, l'isolation est fournie par une couche différente, ce qui est plus difficile à surmonter. Et encore plus avec un serveur dédié. Donc, je ne suis pas d'accord avec la réponse que Bluehost vous a donnée.

Cependant , si le compromis provient de votre compte (par exemple, un plugin wordpress vulnérable), alors cela n'aura certainement pas d'importance. option d'hébergement que vous utilisez.

Certes, votre fichier logo-small.png semble avoir été téléchargé via votre application.

En ce qui concerne la détection des compromis, je recommande de garder le fichier en version control.It est facile de créer un script qui rsynchronise votre site Web et s'engage par exemple. un dépôt git.

Cela sert de sauvegarde et met également en évidence très clairement les différences lorsque les fichiers sont modifiés.

Plusieurs réponses préconisent l'utilisation de fichiers statiques. Si les fichiers ne changent pas à distance, et en supposant que vous êtes le seul à changer les pages Web (ou qu'elles sont modifiées sur le même ordinateur "maître") un simple rsync -avz --delete website / the-server : reviendrait à la version "propre", si un tel compromis devait survenir. Vous pouvez même synchroniser automatiquement de cette façon "au cas où", bien que si le site Web est en quelque sorte vulnérable, la restauration automatique à partir d'une sauvegarde, bien que rapide, ne soit pas une vraie solution.

Neil Robertson
2016-03-11 17:30:48 UTC
view on stackexchange narkive permalink

Sécurité de l'ordinateur personnel

Selon le formulaire de commentaire AL, la vulnérabilité peut n'avoir rien à voir avec votre site Web ou l'hébergement, mais plus à faire avec des mots de passe volés à partir d'un ordinateur d'administration de site Web compromis ou similaire ou peut-être que l'attaquant a le contrôle d'un compte administratif qui n'a pas été réinitialisé depuis le nettoyage initial.

Abandon de WordPress vs mise à niveau vers un meilleur hôte

S'éloigner de WordPress peut aider, mais trouver un hébergeur avec de meilleures pratiques de sécurité peut être une solution plus efficace.

Je m'occupe d'une cinquantaine de sites Web construit avec un CMS similaire à WordPress et je suis très consciencieux d'appliquer régulièrement des mises à jour. Les sites hébergés sur des hôtes de bonne qualité (par exemple, SiteGround) sont rarement piratés. SiteGround met régulièrement à jour son pare-feu d'application Web pour bloquer les vulnérabilités WordPress, Joomla et autres les plus courantes, bien que vous deviez toujours mettre à jour rapidement votre CMS et tout module complémentaire tiers à mesure que des mises à jour sont publiées.

Hébergement partagé vs VPS

Passer à un VPS peut réduire le risque de contamination d'autres comptes sur le même serveur, mais la sécurité d'un VPS repose sur les compétences de la personne ou des personnes qui le maintiennent, juste le identique à l'hébergement partagé.

Un compte d'hébergement partagé sur un serveur bien entretenu est moins susceptible d'être piraté qu'un VPS mal entretenu.

Précautions de sécurité Common Sense

Quoi que vous fassiez, rien sur le Web n'est jamais sécurisé à 100%. Vous pouvez minimiser le risque de perte de données en exécutant des sauvegardes régulières, en copiant les sauvegardes hors site et en testant régulièrement les sauvegardes.

Découvrez d'autres précautions de sécurité de bon sens telles que:

  • appliquer régulièrement des mises à jour
  • maintenir la version PHP à jour,
  • choisir des logiciels uniquement auprès de développeurs établis et de confiance
  • minimiser le nombre de modules complémentaires lorsque cela est possible
  • minimiser le nombre de comptes administratifs
  • mettre en œuvre un pare-feu d'application Web pour protéger le site Web et / ou activer un réseau de diffusion de contenu (CDN) qui comprend un pare-feu d'application Web

En conclusion

Je dirais que la solution la plus rentable dans votre cas où vous avez un client soucieux de son budget est une solution d'hébergement partagé avec un fournisseur d'hébergement de bonne qualité.



ⓘ
Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...