Alors que le mois de d?cembre se termine, la s?curit? des serveurs de hosting mutualis? est plus que jamais ? l?ordre du jour. En effet, c?est durant ce mois que se tiennent les plus grands concours d?agression contre des syst?mes en ligne : sites web, serveurs, applications? etc. Les syst?mes attaqu?s sont, le plus souvent, scrut?s et ?valu?s durant les mois pr?c?dents et puis attaqu?s de mani?re destructive le moment venu. Les attaquants sont des cybervoyous agissant en bandes de malfaiteurs tr?s bien organis?s.

Clairement, l?attaque et la destruction de syst?mes informatique sont des crimes graves punis de lourdes peines d?emprisonnement dans la plupart des pays. Ce sont des crimes relevant du vandalisme pur et simple. Un site internet, au-del? des scripts et des codes qui le constituent, est d?abord un outil de travail au m?me titre qu?une voiture, une boulangerie ou un fourgon de la compagnie du t?l?phone. Les destructions de sites ou de serveurs occasionnent des pr?judices lourds non pas ? des scripts, mais ? des humains. Un site de eCommerce d?truit peut signifier des gens au ch?mage, des couples bris?s, des enfants qui ne partent pas en vacances? si ce n?est pas un crime de sang, ?a y ressemble.

Les serveurs d?h?bergement mutualis?s sont parmi les plus difficiles ? s?curiser. Pour ?tre totalement honn?te, il est impossible de totalement les s?curiser. La s?curit? d?un serveur peut se comparer ? la s?curit? d?une serrure de porte. Il y a des grosses et des petites serrures mais toutes ont une limite au-del? de laquelle elles cassent. Quand une serrure c?de, il y a ? c?t? un cambrioleur qui risque des ann?es de prison pour s?emparer des biens des autres. Quand un serveur c?de, il y a ?galement une personne pr?te prendre des risques tr?s lourds pour nuire aux autres.

A moins que vous n?inventiez un nouveau syst?me d?exploitation, les serveurs de hosting utilisent actuellement soit Windows, soit un des nombreux clones Unix. Il ne faut pas dire qu?un des syst?mes est plus s?curis? que l?autre. Quand les attaquants sont d?termin?s ou que des erreurs de configuration sont commises, tous les syst?mes sont de vuln?rabilit? ?gale.

Un syst?me de hosting mutualis? est un environnement partag? entre de nombreux utilisateurs qui veulent tous avoir le maximum de droits et le maximum de s?curit?. La demande est contradictoire et s?apparente ? la quadrature du cercle pour les administrateurs. En effet, sur un serveur d?h?bergement, les utilisateurs ont de tr?s nombreux droits et en r?clament toujours plus. Pour donner un exemple, il est devenu impossible de vendre des h?bergements avec le safe mode on. Les clients demandent le safe mode sur off ou ils vont ailleurs. Pourtant, mettre le safe mode sur off c?est tout simplement autoriser un utilisateur ? manipuler des fichiers qui ne sont ? lui ! Or, sur un syst?me de hosting, toute la s?curit? repose sur le fait que les fichiers ont un propri?taire et donc des autorisations de lecture, d??criture et d?ex?cution. Si n?importe qui peut lire n?importe quoi, il est difficile de parler de s?curit?.

Les attaques viennent rarement de l?int?rieur, mais il faut y songer tout de m?me. Rien n?interdit ? une personne malintentionn?e de passer commande d?un h?bergement chez-vous et d?utiliser son statut d?utilisateur pour abuser des droits qui lui sont attribu?s. Il est donc important de faire un screening des commandes et de ne jamais ouvrir de comptes ? des personnes qui donnent de fausses informations. De nombreuses compagnies t?l?phonent dans 100% des cas afin de s?assurer de l?identit? de l?utilisateur. Une personne ayant une mauvaise id?e derri?re la t?te, donne rarement ses vraies coordonn?es. D?autres compagnies, plus rares, exigent que les clients faxent des pi?ces d?identit?. Cette solution est lourde et pas efficace.

Dans la quasi-totalit? des cas, les attaquants prennent le contr?le du compte d?un utilisateur l?gitime afin de remonter et de pirater les autres comptes, y inclus les comptes des administrateurs. Donc l?identit? de l?utilisateur peut ?tre v?rifi?e, mais rien n?emp?che que sont compte soit d?tourn? plus tard.

Sur un syst?me de hosting chaque utilisateur installe ses propres scripts. Ca peut ?tre des scripts home made, des scripts gratuits, commerciaux, anciens, r?cents, des versions compl?tes, des versions beta, voir alpha? Sans compter les installations avort?es ou abandonn?es en chemin. Un serveur de hosting moderne compte plusieurs dizaines ? plusieurs centaines de milliers de scripts de toute sorte. Il n?est pas possible ? un administrateur syst?me de les contr?ler tous contre les diverses failles de s?curit?. Il est ?galement utopique d?esp?rer que chaque utilisateur fasse le m?nage dans son compte.

Une action globale s?impose. Tout en offrant le maximum de ressources aux utilisateurs, l?administrateur doit faire en sorte que les scripts h?berg?s ne puissent pas ?tre exploit?s ou abus?s au-del? d?une certaine limite. Ceci impose des restrictions, mais ?galement un travail continu de gestion.

Les restrictions sont sur les droits et les fonctions PHP et autres. Par exemple, il est inutile et dangereux d?activer le CGI de mani?re syst?matique. Moins d?un utilisateur sur cent utilise les scripts CGI alors qu?une fois d?tourn?s ou utilis?s abusivement ces scripts ont la plus forte capacit? de nuisance. En effet, alors que le PHP reste un simple script, le CGI est un mini serveur travaillant pour son propre compte. S?il est exploit?, il peut permettre d?envoyer des millions de spams en quelques heures ou de pirater tout le contenu d?un serveur. Pour cette raison, ces scripts ne peuvent ?tre install?s que dans le dossier cgi-bin pour pouvoir les contr?ler, les retrouver et ?viter qu?un CGI upload? dans un dossier images ou avatars, par exemple, ne puisse ?tre ex?cut?. En cas de doute, ne proposez pas de CGI dans vos packs d?h?bergement. Le peu de personnes qui en ont besoin peuvent trouver des solutions plus s?res en utilisant du PHP. C?est de la mauvaise gestion d?autoriser un CGI juste pour un compteur de hits.

Pour PHP, le mieux est de restreindre l?acc?s aux fonctions les plus puissantes. Par exemple : exec, passthru, proc_open, proc_close, shell_exec, system, popen? Ces fonctions permettent de faire ex?cuter des commandes Unix en les passant au syst?me dans des scripts PHP. Ce sont les fonctions les plus m?chantes et peu de scripts l?gitimes les utilisent. Vous pouvez les bloquer sans d?clancher un toll? g?n?ral.

Pour le syst?me, il est recommand? de garder les programmes du serveur ? jour (Os, panneau de contr?le, Apache, PHP?) et de bien configurer son syst?me. Par exemple, une simple partition /tmp configur?e pour refuser les ex?cutables peut d?j? rendre de tr?s grands services.

Il faut installer un firewall d?s qu?un serveur est ligne. Un firewall ne pr?vient pas la premi?re attaque, mais il prive l?attaquant d?une ressource importante : le temps. Avec un syst?me sans firewall, un attaquant peut essayer toutes les possibilit?s ? sa discr?tion. S?il lui faut essayer pendant 6 mois pour craquer un mot de passe, il aura ses 6 mois. Avec un firewall en place, d?s la d?tection des premi?res tentatives, l?IP est bannie et l?attaquant doit en trouver une autre. Il est ?galement int?ressant de bannir d?avance les IPs des pays ? risques. Par ailleurs, si vous avez de nombreux serveurs, vous devez copier les IPs bloqu?es par une machine dans tous les autres firewall. De cette mani?re, il suffit qu?une personne s?attaque ? une machine pour ?tre bannie de toutes les autres.

Il est important ?galement de lire r?guli?rement les logs. Si vous ne lisez pas les logs, votre serveur sera comme une cabane isol?e avec une grosse serrure. Les attaquants pourront y travailler ? loisir. Un log important est celui d?Apache, c?est le fichier error_log qui se trouve dans le dossier /var/log/httpd. Id?alement, il doit ?tre vide. Il ne l?est jamais et recueille les requ?tes que Apache n?a pas pu servir. Les tentatives d?attaques ou tests provoquent des erreurs que l?ont voit dans ce log. Leur trace est trop faible pour ?tre d?tect?e par le firewall. Il est donc important de v?rifier les IPs qui provoquent des erreurs suspectes en les ajoutant manuellement au firewall.

A suivre?

Koureissi

CEO MALIHOSTING



mardi, décembre 21, 2010





« Retour

Powered by WHMCompleteSolution