3
Posted by alex on May 5th, 2008

Un petit survol des aspects de sécurité de base sur un serveur.

Première étape: Les applications

Bien lire la documentation des applications. Générallement, il est préférable d'utiliser les versions les plus récentes puisqu'elles corrigent bien souvent les failles connues. Après avoir lu la documentation rigoureusement, assurez vous de bien configurer les applications pour qu'elles répondent parfaitement à vos besoins et qu'elle soit sécurisée. La configuration par défaut est la pour fonctionner out of the box, pas pour être utilisé en production. Utiliser la loi du gros bon sens: Le root ne devrait jamais pouvoir se connecter directement au serveur (ssh), de même qu'AUCUN compte ftp ne devrait avoir une racine plus haute que son dossier personnel. Pour php pensez à l'open_basedir et à interdire l'execution de programmes externes (ou chrooté votre serveur, voir plus bas) et ce même si votre machine n'est pas partagé (Une faille dans VOTRE application pourrait tout détruire). Une étape importante est l'obscurcissement. Ne laissez pas trainer la moindre information qui pourrait aider un hacker : cacher les versions de vos applications, cachez les chemins de vos scripts critiques (par exemple un phpinfo ne devrait pas montrer le chemin de votre application principale). De même qu'un compte admin ne devrait jamais s'appeler root ou admin. (Je pense ici surtout au serveur de base de données).

Deuxième étape: Les permissions et attributs des fichiers

Une fois les fichiers de configuration personnalisés, vous devez règler les bonnes permissions et les bons attributs si vous ne voulez pas que n'importe qui puisse les lire ou pire les modifier. En règle générale, une permission de 0400 suffit pour les fichiers de configuration d'un démon ou d'un service et le propriétaire doit être root:root puisque c'est lui qui démarre les services. Une protection supplémentaire est de rendre le fichier immuable. Cela va empêcher même le root de le modifier, à moin qu'il enlève explicitement l'attribut immuable. Excellente protection contre les fausses manipulations et les failles ftp / injections.

Troisième étape: La surveillance

Lire les logs n'est pas une tâche très intéressante je vous l'accorde. Mais vous devez le faire. Évidement il est plus judicieux d'utiliser des analyseurs de logs ou bien d'écrire vous même vos scripts afin de repèrer rapidement une activité suspecte. La surveillance du système entier est très importante. Pourquoi ? Parce qu'un pirate sérieux ne posera peut être pas d'acte de vandalisme, il va simplement se laisser un backdoor (une porte dérobée) afin de pouvoir se reconnecter facilement à votre serveur, et ce, même si la faille utilisée est bloquée entre temps. Pourquoi ferait-il cela ? Si un jour il a besoin d'une passerelle dans le but de commettre des actes illégaux (envois de spam, piratage, déni de service) visant quelqu'un d'autre, il va déjà avoir accès à votre machine. Un hacker talentueux va même aller jusqu'à installer un rootkit afin de masquer leurs présence et les backdoors installées. Les rootkits sont très difficiles à détecter, sauf si on le détecte pendant son installation (voir watchdog plus bas). Une analyse forensique (après l'incident) permet de reconstituer les actions et les motivations d'un intrus. Cela consiste bien souvent à récuperer des données ayant été effacés (logs).

Quatrième étape: Le chien de garde

Ou outil de surveillance système en temps réel. Vous ne pouvez pas toujours être devant votre ordinateur à surveiller les logs ou le système. C'est pourquoi un watchdog peut être utilisé (codé par vous ou bien déja fait tel que monit) afin de surveiller l'activité des services. Par exemple il pourrait redémarrer un service qui aurait planter, ou en tuer un qui s'emballe afin de le redémarrer. Il peut surveiller périodiquement les fichiers critiques et restaurer une copie originale (situé dans un endroit protegé) si il détecte une modification innatendue. Dans l'extrème il pourrait même mettre le système en alerte et bloquer tous les accès en attendant l'administrateur si il trouve une activité suspecte. Le watchdog peut aussi surveiller les connexions ssh en temps réel. Bref le watchdog fait ce que vous voulez, faut juste penser à le faire ;) .

Cinquième étape: Limiter les dégats

Bon, une catastrophe se produit et un pirate s'infiltre ! Même si vous pensez avoir tout prévu, une faille peut être trouvé à n'importe quel moment dans une application que vous utiliser. C'est pourquoi il est important de limiter les dégats si un utilisateur réussit tout de même à infiltrer le système. Si votre watchdog est bien conçu, il va réussir à bloquer l'accès à l'intrut assez rapidement. Mais il ne faut pas s'y fier. Ici encore les notions de permissions de fichiers sont très importantes. Pensez à cacher, ou à rendre le plus difficilement accessible la moindre information critique. Une solution afin de "limiter" les dégats est le chroot. Si vous chrooter vos applications, le pirate sera coincé dans sa prison "virtuel" pour lui la racine / sera le dossier que vous aurez choisis, et non pas la racine de votre serveur ;) . Ça augmente aussi énormément la sécurité si vous pensez laisser vos utilisateurs executer des CGI. Sous BSD il y a les Jails qui sont BEAUCOUP plus puissantes. Il est aussi très important de bien concevoir vos scripts: Prenons un script de sauvegarde automatisé comme exemple. J'ai un script qui lit periodiquement dans une base de données afin de faire une sauvegarde sur demande. Il récupère le nom du dossier dans la base, et fait à peu près ça "tar czvf $dossier/backup/backup-`date +%F`.tar.gz $dossier". Si un pirate infiltre ma base, il pourrait facilement modifier le $dossier par ";rm -Rf /" et ainsi tout détruire. Et tout ça, juste en trouvant le mot de passe admin de ma base de donnée, sans même avoir accès au serveur. Le cryptage des données sensibles est aussi essentiel. Si vous avez une entreprise vous ne voulez pas qu'un pirate ait accès aux données de vos clients, parce que pour vous, ça serait la faillite assurée !.

Sizième étape: Les ressources

La gestion et le partage équitable des ressources font aussi partie de la sécurité d'un serveur. Pensez aux fs quotas, aux userlimits et aux règles du limit.conf par exemple. Ne négligez jamais cette étape, c'est sans doute une des plus importante sur un environement partagé. De même qu'une fork bomb pourrait vous forcer à redémarrer si vous ne controller pas ça !

Dernière étape: Le réseau

Votre système est stable et fonctionnel. Tout vas bien et vous êtes confiant en votre sécurité logiciel. Mais avez vous bien sécurisé la couche réseau ? Si une attaque de Déni de service, ou pire de Déni distribué de service, survient est-ce que votre serveur va tenir le coup ? Qu'en est-il d'un ping flood ? Il faut aussi appliquer un minimum de protection contre le spoofing IP (entre autre pour les authentifications qui se base sur un IP et le DoS).

Une attaque survient:

Il est important de tout de suite mettre hors-service la machine dès qu'on a conscience d'une attaque. Pourquoi est-ce que c'est si important ? Parce que si on attend trop longtemps, les données sensibles (tel que les logs ayant été effacé par le pirate) ne seront pas récupérable. Après avoir mis le système hors service, il faut d'abord mesurer l'ampleur des dégats. Trouvez ce qui a été modifier, quelles données ont été récuperés par le pirate, etc. Souvent cela consiste à faire une recherche par horodatage. Bref il faut reconstituer les événements dans le temps, et dans un ordre chronologique. Une fois cela fait ça va vous aider à comprendre les motivations du pirate mais surtout de comprendre comment il est entré.

Conclusion:

Le travail d'administrateur réseau/système, outre le fait de s'assurer que tout fonctionne correctement, est de se mettre dans la peau d'un pirate afin d'essayer d'infiltrer son propre système. Il doit connaitre les techniques utilisés par un pirate afin de comprendre et d'éviter les attaques potentielles. Il doit se tenir informé des nouvelles versions de ses logiciels et connaitre leurs vulnérabilités. On peut résumé tout le texte ci dessus en quatre mots (et je les répète à plusieurs endroits sur ce blog) : Vous devez être paranoïaque.

Malgré toutes les précautions que vous pouvez prendre, il va toujours y avoir quelqu'un plus fort que vous quelque part. Non, votre orgueil ne rend pas l'échec impossible. J'ai dit NON vous n'êtes PAS le plus fort :( . C'est pourquoi les sauvegardes dans un endroit sécuritaire et isolé sont très importantes. Il faut aussi garder les logs de connexions, afin de pouvoir porter plainte contre un éventuel hacker. Mais je ne vous mentirai pas, il est très peu probable que votre plainte soit prise au sérieux. Comme mentionné en début d'article, ce n'est qu'un survol et cet article ne contient rien de très concrêt dans les actions à prendre. Il ne fait que raconter brivement chacun des aspects de la sécurité d'un serveur. De toute façon il y a tellement de méthodes employés par les pirates qu'un seul article (même une centaine) ne suffierait pas ;) .

Read more...
3 comments
2
Posted by alex on May 3rd, 2008

Savez-vous quelle est la qualitée la plus importante lorsque l'on veut devenir hébergeur (amateur) ? L'intelligence ? non. La compétance ? non plus. (Même que ça l'air d'être facultatif dans le domaine :-? )

C'est la patience. Il faut avoir une patience énorme pour répondre au support technique :| .

Je suppose que c'est pareil partout : Il faut respecter une règle essentielle quand on offre un service à la clientèle : "Le client a toujours raison". Mais dans la réalité ça se résume plus comme "Le client pense qu'il a raison et qu'il est meilleur que vous mais il a souvent tord".

J'en vois de toutes les couleurs en partant du type qui m'insulte parce que je refuse d'héberger ses warez jusqu'au mec qui nous critique parce qu'à cause de son incompétance il n'arrive pas à configurer son domaine.

Tien, hier j'ai même reçu un ticket sur le support d'un gars qui me disait que mon hébergement fonctionnait mal parce qu'il n'arrivait pas à se connecter à son compte mail avec hotmail.

Oui oui, il s'était fait un compte courriel sur mon hébergement sonnom@sondomaine.com et il ne comprenait pas pourquoi il ne pouvait pas s'y connecter avec hotmail et windows live messenger.

J'ai essayé de lui expliquer le plus poliement possible qu'il fallait un Passport .Net pour utiliser avec WLM, et qu'avec hotmail c'était impossible de faire ce qu'il voulait ... Et depuis silence total, il ne répond plus.
Ou encore ceux qui écrivent à la moindre petite coupure pour dire "Mon site est indisponible, est-ce que c'est normal ? Est-ce que ça arrive souvent ?" ... Ben oui toi, c'est évidement que j'vais répondre "Oui c'est normal je m'amuse à couper le serveur sans avertir personne et puis oui oui nous sommes les pires hébergeurs du monde, toujours en panne, je vous conseille fortement d'aller ailleurs."... Je peux comprendre que le monde s'inquiète, mais voyons donc...

Oui parce que dans un support technique en plus de voir des personnes incompétantes vous dire comment faire votre boulot, on ne reçoit jamais de remerciement. Enfin si, mais rarement.. très rarement. Une fois sur trois la demande d'aide est faite dans une forme correcte et tout à fait polie. Un autre tiers des fois c'est fait impoliment du genre "Sa march pa arange sa" (fautes comprises). Et le reste du temps c'est carrément des accusations.

Attention ne vous méprennez pas, je sais que le client ne peut pas tout savoir. C'est pas leurs job à eux de règler les problèmes, mais la mienne. De toute façon si c'était le cas, il n'y aurait pas de support technique ;) . Non le problème se situe dans la façon que le client demande de l'aide. En fait il ne la demande pas, il l'exige. Ça ne s'applique pas qu'au support technique on dirait, J'ai remarqué cela sur le forum de phpcs (réseau codes-sources). Des gens demandent de l'aide de manière totalement impolie, si la solution fait leur affaire on ne les revoit jamais (pas de merci, rien), mais si ça ne fonctionne pas ooooh tu peux être certain qu'ils reviennent se plaindre :) . Par contre il faut mentionner que beaucoup de clients sont très agréables, ça contre balance le tout !

En fait je dirais que la plus grande qualité qu'un hébergeur devrait posséder c'est de savoir déléguer. De confiez ce genre de job à des sous-fifres qui seraient ravis de faire ça pour vous juste pour dire qu'ils font parti de l'équipe :) La patience est une vertue qui s'apprend y parait :P .

Bon je sais que cet article et celui d'Ubuntu peuvent laisser croire que j'avais besoin de me plaindre. C'est en partie vrai, mais cet article n'en est pas moin valable. Mon blog est la pour donner des astuces techniques, mais surtout pour expliquer ce qu'il faut faire (et ne pas faire) pour être hébergeur, et de raconter un peu comment ça se passe pour moi. En partant de ça, je pense qu'il est important de ne pas négliger que quand on a un hébergement, il faut aussi penser aux temps qu'on va consacrer aux clients et pas juste au coté technique !

Read more...
2 comments
1
Posted by alex on Apr 25th, 2008

Vous rappelez vous de votre enfance, alors que les jeux vidéos en 2 dimensions étaient VRAIMENT amusants ? Aujourd'hui si vous donnez le choix à un enfant entre jouer à Halo3 et à Super Mario World, il risque de choisir Halo3. Je n'ai rien contre Halo, c'est l'un de mes jeux préférés, mais je trouve ça triste. Peut être suis-je nostalgique, ou peut être suis-je trop "Nerd" pour m'être adapté à la nouvelle ère des jeux en trois dimensions, mais je préfère mes bon vieux jeux Super Nintendo. Bon je n'ai plus de super nintendo, mais la plupart des bons jeux ont été portés sur la GameBoy Advance :) .

Je me souviens du jour où ma mère nous avait offert un Super Nintendo pour Noël avec les jeux Super Mario World, Street Fighter II et Donkey Kong Country. Je peux vous dire que j'en ai passé des soirées à jouer à Super Mario afin d'essayer de battre enfin le boss finale ! Je me souviens du jour ou j'ai terminé Street Fighter avec mon ami, ayoye j'pense qu'on en a parlé pendant deux semaines... De toute façon je ne suis pas un grand gamer. En tant que geek, je me tanne souvent après seulement quelques minutes de jeux.

Biensur j'aime aussi plusieurs jeux en 3D (plutot old school) tel que Quake 3, Moto GP, Zork Grand Inquisitor, Halo, Starwars Racer, Tomb Raider, Burnout, Lego Island, etc. Mais.... Plus j'y pense et.... Plus je me dis que je vais me racheter une SNES, et vous ?

Read more...
1 comment
1
Posted by alex on Apr 25th, 2008

Cet article a pour but de résumer un peu quels sont les principaux systèmes d'exploitations pour un serveur, quand les utiliser et quand ne pas le faire.

blog.alexou.net.jpg

Je vous laisse aussi quelques liens utilent vers des comparaisons et des benchmarks !

FreeBSD

FreeBSD est un excellent système d'exploitation de la belle famille des Unix. Il descend directement du Unix de AT&T. Il est bien de mentionner que FreeBSD apporte une compatibilité binaire avec Linux ! Bon passont aux choses sérieuses: Oui FreeBSD est plus stable que Linux. D'après de multiples benchmarks, et de part sa conception interne ce système d'exploitation méconnue est plus stable que Linux. Et sur certains aspects il est plus performant (dans sa dernière version 7.0 on parle même de 15% de gain au moin). Évidement il ne faut pas prendre sa stabilité pour acquise, la différence avec Linux n'est pas énorme non plus. D'après Netcraft, FreeBSD est l'un des systèmes qui revient le plus souvent sur les serveurs ayant le plus grand uptime (aucun reboot). Sa conception est plus rigoureuse puisqu'elle est maintenu par une plus petite équipe de développeurs qui vérifie et effectue la plupart des changements au kernel. De plus les "ports" sont développés en parrallèle avec le kernel. FreeBSD est donc un système à part entière contrairement à Linux qui n'est qu'un kernel. Je pense donc, personnellement, que FreeBSD est un excellent choix comme système d'exploitation pour un serveur web.

Linux

blog.alexou.net.jpgOn ne le présente plus, GNU Linux est l'un des (si ce n'est LE) systèmes ouverts les plus utilisés de nos jours. Il a été écrit à partir de rien par Linus Torvalds et est aujourd'hui maintenu par des centaines de développeurs. Il y a de nombreuses communautés de personnes pour nous aider sur le web si on rencontre un problème. De plus la plupart des applications serveur open-source fonctionnent parfaitement sur cet OS. Mais sa conception est moin "stricte" que FreeBSD, n'importe qui peut modifier et soumettre des changements au kernel ce qui est une force, mais aussi une grande faiblesse. Je le recommande donc égallement comme système d'exploitation pour un serveur de production.

Microsoft Windows 2003

Microsoft Windows est depuis toujours critiqué pour sa stabilitée douteuse et ses nombreuses vulnérabilités. Mais les temps ont changés et il n'en est rien ! En effet il faut mettre les choses aux claires: Si beaucoup d'utilisateurs se plaignent de la sécurité de windows, c'est qu'ils sont STUPIDES. Ils cliquent partout, téléchargent n'importe quoi et après ils se demandent pourquoi ils ont des virus... Adopter ce même comportement en étant connecté en root sur un système Unix, je suis persuadé que vous allez bousillez votre système tout aussi efficacement ;) . Windows NT5 est donc un excellent système d'exploitation, il est sécuritaire et relativement stable. Il est toutefois très important de bien comprendre la sécurité du système, parce que le manque de droits et de permissions sur les fichiers peuvent vite mener à une catastrophe. Lorsqu'on décide d'utiliser ce système sur un serveur de production, il faut le faire pour les bonnes raisons. En effet ce système montre son plein potentiel couplé à IIS ainsi qu'aux technologies ASP .NET. Pas en utilisant Apache et PHP, qui eux, ne sont pas du tout adaptés à la plateforme.

Conclusions

Peu importe le système que vous choisierai, vous devez le faire pour les bonnes raisons. Si vous avez besoin de technologies libres tel que Apache, PHP, Perl, Python, etc alors il serait stupide d'aller vers un serveur Windows. Pourquoi ? Parce que cet OS n'est pas adapté à ça, il ne donnera pas son plein potentiel et ne sera pas totalement sécuritaire. Si vous avez besoin de technologies propriétaires telles que l'ASP .Net, IIS, le C# et autres, alors allez vers Microsoft Windows. Pour ce qui est des serveurs de jeux, en générale, c'est équivalent des deux cotés mais bien souvent on peut privilégier Windows puisque les serveurs sont souvent développés en premier pour cette plateforme, ils sont souvent plus stables et plus aboutis que leurs versions Unix.

Pour le choix FreeBSD vs Linux: Personnellement j'utilise les deux dans différentes circonstances. Le seul conseil que je peux vous donner: C'est d'essayer les deux. Linux est (beaucoup) plus simple à utiliser que FreeBSD. En fait il faut comprendre que FreeBSD est Unix, Linux n'est pas Unix, il est compatible POSIX et reprends les idées d'Unix mais ne l'est pas. Ensuite faut voir si les applications que vous souhaitez utiliser sont compatibles ! Mais globalement, les deux systèmes se ressembles.

Je vous laisse un petit lien vers un comparatif des trois (Windows Linux FreeBSD), il est plutôt vieu et il est publié sur le site de FreeBSD, ce qui nous permets de remettre en doute l'impartialité de l'auteur. Mais je dois avouer qu'avec mon (peu d') expérience, la plupart des arguments sont justes. http://www.freebsd.org/marketing/os-comparison.html

Un excellent bench Linux vs *BSD

Différences entre Linux et FreeBSD (J'ai pas tout lu, mais ça semble intéressant !)

Read more...
1 comment
Go to Top