Principales règles de sécurité à respecter pour la gestion des systèmes

Les contributions sont les bienvenues, sachant qu'il faut rester dans les "grandes lignes", quitte à faire un lien vers une page qui explique plus en détail les choses.

Généralités

• Choisissez bien vos mots de passe. Protégez vos clés privée (SSH, gpg, etc) avec un mot de passe solide (http://www.certa.ssi.gouv.fr/site/CERTA-2005-INF-001/CERTA-2005-INF-001.html.)

• Toutes les tâches effectuées avec les droits de root demandent la plus haute attention

• N'utiliser que des logiciels recommandés par la DRI (ListeDesLogiciels) dans le cadre des modèles de confirmation (ListeDesModeles)

• Désactiver les fonctionnalités inutiles des logiciels quand c'est possible. Ne pas installer de logiciel inutile
• Ne pas faire de tests sur un serveur en production. Ne jamais installer sur un serveur public un logiciel "pour voir si ça marche" : le tester d'abord sur un réseau privé inaccessible depuis Internet
• Mettre à jour tous les systèmes le plus souvent possible, au moins quotidiennement pour les serveurs
• Faites des sauvegardes des systèmes et des données
• Suivre l'activité des machines afin de détecter les incohérences (augmentation soudaine de trafic, de consultation d'un site web, etc)
• Protéger les équipements contre la chaleur, l'humidité, la poussiere et les aléas de l'alimentation éléctrique

Debian

• Ne jamais considérer les mises à jour comme une tâche automatique. Sinon, on le ferait faire tout simplement par un cron. Il faut analyser les impacts des mises à jour pour chaque paquet proposé par aptitude, consulter le changelog (apt-listchanges est vivement conseillé pour gérer cette partie là) et ensuite, une fois qu'on a l'assurance qu'il n'y aura pas de problème, appliquer la mise à jour. Mais pas avant !

• S'abonner à la liste des Debian Security Announce] (DSA) pour recevoir les informations sur les mises à jour nécessaires de vos serveurs.

• Toujours utiliser toujours des logiciels intégrés à Debian. Les paquets Debian sont suivis par le projet Debian au niveau de leur sécurité : si un bogue de sécurité est découvert, Debian émet une version corrigée du paquet. Si des logiciels ont déjà été installés "à la main" (depuis les sources) alors que Debian les propose, les désinstaller //immédiatement// et installer les paquets Debian correspondants à la place. Tout de suite : quelques heures suffisent pour être découvert comme machine boguée.

• En cas de besoin d'un logiciel non disponible dans Debian, il faut en assurer soi-même le suivi de sécurité : s'abonner à la liste de diffusion des annonces concernant ce logiciel (s'il n'y en a pas, ne pas installer le logiciel ! ) et faire les mises à jour dès qu'un bogue est signalé. C'est d'autant plus important si le logiciel est très utilisé dans le monde et si c'est une application visible sur Internet (exemples : un webmail, un système de gestion de site, un système de groupware, etc.) Avant d'installer un paquet hors Debian (y compris depuis backports.org), contacter la liste tech@auf pour demander l'avis des autres responsables technique, notamment le responsable régional.

Sur Debian, lire : http://www.debian.org/doc/manuals/securing-debian-howto/

Web (Apache/PHP)

• Aucun fichier ou répertoire de toute la machine (pas seulement /var/www ou /srv/www ) ne doit appartenir à www-data ou proposer des droits d'écriture à cet utilisateur. En effet, www-data est l'utilisateur sous lequel tourne le serveur Apache : si Apache est détourné, il ne faut surtout pas qu'il puisse écrire n'importe où !

• Cependant, certaines applications Web (écrites en PHP ou autre) nécessitent parfois d'écrire des données sur le disque. Dans ce cas, il faut s'assurer que seul le répertoire où elles doivent écrire est accessible par l'utilisateur www-data, pour limiter les risque. C'est le cas de logiciels comme SPIP ou Lodel.

• Toujours concernant PHP, désactiver le moteur PHP là où il n'est pas utilisé, et notamment sur les répertoires ouvert en écriture (voir ci-dessus). Ainsi, même si un pirate arrive à mettre un fichier .php sur le site, si c'est dans un répertoire où PHP est désactivé cela limite la casse. Désactiver aussi les fonctions comme mail, éventuellement. Vérifier enfin que PHP est en "safe_mode"

Sur PHP, lire : http://www.php.net/manual/fr/features.safe-mode.php et http://www.php.net/manual/fr/security.php

Bases de données (MySQL/PostgreSQL)

MySQL

• N'accorder le droit file_priv que quand c'est absolument nécessaire. En effet, ce droit autorise entre autres choses d'utiliser la fonction load_file(...) ce qui permet de lire n'importe que fichier accessible par l'utilisateur exécutant le service MySQL. Un exemple typique d'abus de ce droit est la lecture de code source de fichier CGI (PHP ou autre) sur un serveur web, ce qui peut alors révéler des données sensibles comme par exemple des mots de passes de connexion.

Courrier électronique

• Installer un système de filtrage intelligent (anti-spam et anti-virus)

Postes clients

• Utiliser des SE libres, comme Ubuntu.

• S'abonner à la liste diffusant les annonces de correction de bogue de sécurité : Ubuntu Security Notice] (USN)

Réseau

• Installer un pare-feu général en tête de réseau (mieux) ou au minimum du filtrage sur chaque serveur.
• En règle générale les accès vers et depuis une machine doivent être parfaitement contrôlés, surtout sur un serveur. On omet souvent à tort de filtrer les accès sortants, souvent par manque de temps car cela demande plus d'étude. Cela permet pourtant d'empêcher des comportements réseau imprévus (sortie intempestive de courriels par exemple).
• Le filtrage des connexions dépend aussi et surtout de la politique réseau choisie : on peut avoir besoin d'un réseau plus ou moins ouvert suivant les cas. Pourtant il faut aussi s'assurer que nos réseaux ne soient pas détournés de leurs objectifs d'origine. Il y a donc un minimum de filtrage à assurer ***[...] faire une page dédiée ?***

Pannes

• dans tous les cas faire un mini compte-rendu de la panne, ceci afin de garder une trace et repérer les pannes récurrentes, ce qui pourrait indiquer des problèmes matériels importants

• panique (crash) d'un serveur :

  • en cas de plantage complet, prendre une photo numérique des messages affichés sur la console avant de le redémarrer ; à défaut d'appareil photo numérique, recopier tout « à la main »
  • afin d'éviter d'avoir à prendre en photo ou recopier les informations sur la console, il est intéressant de paramétrer le service de journalisation du serveur pour envoyer une copie de ses alertes vers un autre serveur (par exemple un service central de journalisation), afin de pouvoir en garder trace même en cas de panne du disque local
  • si vous ne l'êtes pas vous-même, consultez un collègue spécialiste de serveurs Linux avant de tenter le redémarrage ; ceci pour comprendre le problème afin d'essayer d'éviter qu'il ne revienne peu de temps après
  • ne redémarrer le serveur que s'il n'y a aucune autre solution (service indispensable totalement interrompu)

Sauvegardes

à venir...

• CatégorieProcédure