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 ;) .

3 comments
Commentaires
avatar
Un aspect de la sécurité qu'on m'a aussi enseigné est aussi lié à une sécurité physique. Laisser sa salle serveur libre d'accès n'est surement pas une bonne idée par exemple ou bien mettre l'UPS en dessous du système de refroidissement de la salle car s'il se met à faire pipi, ça va faire des flammes (même si souvent c'est l'effet inverse qui se produit :P )

Il m'a aussi été dit que le social engineering est quelque chose à prendre en compte. Faire attention que vos end-user ("la couche 8 du modèle OSI" ou encore "l'interface clavier/chaise") ne donnent jamais leurs mots de passes, même si la personne se prétend du service informatique.

Les éduquer à prendre un mot de passe sécurisé par exemple (14 caractères aléatoire avec minuscule, majuscule, chiffre et caractères spéciaux), même si c'est compliqué. Et faire en sorte qu'ils ne le marquent pas sur un post-it collé à l'écran ensuite... Mais tout dépend de la politique de l'entreprise.
avatar
alex
Administrateur
Tu as bien raison, je n'ai pas couvert la sécurité physique ni le social engineering. Faut dire que l'article concernait surtout un serveur web plus que la sécurité d'un réseau complet.

Et comme tu sembles un t'y connaitre toi aussi, tu sais donc que la sécurité on pourrait écrire une encyclopédie à ce sujet :P

Merci pour tes commentaires, peut être un jour je referai un article pour couvrir plus d'aspects :)
avatar
En fait pour le moment je suis en formation, mais je compte bien être consultant un jour, le temps de me faire mon expérience.

De rien pour le commentaire. Je ne connais que trop bien la frustration d'écrire et de ne pas savoir si on est vraiment lu et apprécié. Malgré les stats
Connectez-vous ou postez en tant qu'invité:
Your Name Your Email


Vérification: 0190
Go to Top