Mesures, monitoring

Soumis par jpp le lun 28/06/2010 - 16:53

La sécurité des machines Linux est un élément important qui ne doit jamais être négligé. La sécurité ne s'improvise pas, cette préoccupation doit être présente en permanence à l'esprit du responsable/propriétaire d'une machine que ce soit un serveur « professionnel » ou une machine « amateur » connectée à Internet.

Premiers éléments « logiciels »

Une machine est accessible par deux « entrées » principales :

  • les services offerts
  • les actions des utilisateurs 

Chacun de ces éléments présente des risques spécifiques.

Les services offerts :  

Tout service présente deux types de risque :

  • Risque lié au logiciel lui même, peut-il « planter » en créant des dommages.
  • Risque de « bug » dans le service permettant à une personne mal intentionnée d'exécuter des actions  dommageables.

Toutefois dans la pratique ces deux risques peuvent être confondus. La première question
à se poser   doit être : ce service est-il utile ?  Tout logiciel peut présenter des risques, il faut donc s'assurer de la réputation d'un logiciel avant   de l'installer :  

  • Le logiciel est-il activement maintenu ?
  • Existe-t-il une liste des bugs connus ? Est-elle tenue à jour ?
  • Existe-t-il une communauté ? Est-elle active (forum, mailing list) ?
  • Les nouvelles versions et les correctifs sont-ils distribuées rapidement ? 
  • L'installation est-elle facilitée par une documentation ? Est-elle automatisée ?
  • Quels sont les éléments de sécurité à prendre en compte lors de l'installation. Bien penser à ce problème    car il existe encore des sites exploitant un serveur Apache utilisant le compte « root » !    

Bien sûr cette recherche est un peu superflue pour certains logiciels très connus tels Apache ou PostgreSql.   

Il est toujours bon de limiter au plus juste les services actifs sur une machine.

De même un « bon » paramétrage de chacun des logiciels peut apporter un peu plus de sécurité.    Il est par exemple sécurisant d'interdire le login « root » par ssh.      

Les actions des utilisateurs :

Tout utilisateur peut faire des erreurs, il faut donc limiter les « dégats » que chacun peut causer.    Un premier niveau de sécurité est d'utiliser des logiciels « sûrs », un deuxième niveau     est de ne permettre à chacun que les actions qu'il est autorisé à faire et les objets auxquels il peut     accéder. La sécurité « standard » de Unix/Linux assurée par les utilisateurs et groupes permet     déjà de limiter les dégâts. Un logiciel malicieux n'a (en principe) que les droits de celui qui l'utilise,     vous ne travaillez jamais en « root » bien sûr ?          

Accès au système :

On en arrive à la partie « mot de passe » qui est le dernier filtre pour les utilisateurs      autorisés. Des « bons » mots de passe sont difficiles à instaurer car la résistance est forte et peu de personnes arrivent à se souvenir de mots de passe trop compliqués (qui peut se souvenir de plusieurs mots de passe tels que «#Zmqp4G5=q1&2 » ) qui en plus changent périodiquement ? Le risque de stockage des mots de passe sur des supports peu confidentiels (le petit papier collé à coté de l'écran) est important... Il est très difficile de trouver un « bon » compromis.
Il faut toutefois sensibiliser les utilisateurs à l'importance d'utiliser des mots de passe non      significatifs suffisamment longs pour ne pas être trouvés facilement en « brute force ».         

Ne pas oublier que une grande partie des ennuis provient de sources « intérieures » ( #80%?).    

Internet :     

L'accès à Internet est une belle chose, mais c'est aussi une porte ouverte sur le ( vilain? ) monde extérieur. Ici il ne faut pas appliquer le principe «tout le monde il est beau, tout le monde il est gentil ». Il vaut mieux appliquer le principe contraire et n'ouvrir que les accès nécessaires,  un « bon » firewall ne gêne pas les accès légitimes mais interdit tous les autres.     
Traduit en règles « IPTABLES » cela veut dire que les politiques par défaut doivent      impérativement être « DROP » et que les autorisations d'entrée (règles INPUT), de transit (règles FORWARD), et même de sortie (règles OUTPUT) sont accordées en connaissance de cause.     

 Pour certains ports (par exemple ssh) on peut s'amuser à utiliser un logiciel tel que « knock » qui permet d'insérer dynamiquement une règle autorisant l'accès à un pert (ssh par exemple) depuis l'adresse d'appel pour une durée courte (30 secondes c'est pas mal), cela évite d'avoir une liste imposante de « failed password » dans les logs de la machine puisque le port ssh est filtré.
Un petit outil permettant une analyse rapide du log du firewall se réalise rapidement à grand coups de     « grep » si l'on a soigné les messages de log (-j LOG –log-prefix 'un_message_descriptif').         

Une surveillance des ports ouverts peut être un plus (j'aime bien « lsof -Pn | grep TCP » ), un logiciel spécifique peut être utilisé (voir par exemple « TIGER »).     

Système :     

Éléments physiques :

Pour des machines professionnelles la machine elle même doit être sécurisée physiquement car une bonne manière de dérober des données est de « piquer » un disque, si on ne peut pas ouvrir le boîtier c'est beaucoup moins discret car il faut emporter le boîtier (cela est aussi valable pour les postes « clients » ou privés).      

Pour les serveurs l'accès physique aux machines doit être limité au maximum et le boot sur un support externe doit être impossible (difficile !), par exemple avec un mot de passe BIOS, de même le montage de supports externes (qui a dit clef USB?) doit être interdit (on peut s'amuser avec les règles « UDEV »). En effet si l'on peut effectuer une copie d'une partition (ou répertoire) sur un support externe la confidentialité des données est illusoire.

 Sécurité et confidentialité des données :       

Un premier niveau de confidentialité doit être assuré par les droits d'accès (utilisateurs et groupes sous Unix/Linux) mais cela n'est pas forcément facile à gérer. Se rappeler quand même qu'un utilisateur peut appartenir à plusieurs groupes.
On peut assurer la confidentialité des données par l'utilisation d'un encodage (cryptage).     Cela peut être fait au niveau d'un document mais aussi d'une partition cryptée, mais cela impose quelques contraintes, notamment au niveau des performances.
Le RAID c'est pas mal pour la sécurité physique (bien que j'ai vu des disques RAID détruits et inaccessibles) mais cela n'offre aucune sécurité contre la destruction ou la perte de données.      

Sauvegardes :       

Les sauvegardes sont une partie importante de la sécurité des données car elles permettent de récupérer des données détruites (volontairement ou non). Une base de données sur une partition «vérolée » n'est en général récupérable qu'à partir des sauvegardes et des logs (mis bien sûr en sécurité sur un autre support ou même sur une machine différente). Le prix des disques ayant beaucoup baissé la copie de données sur un autre support (ou même une autre machine si l'on en dispose) offre une sauvegarde rapide et fiable. De nombreux logiciels peuvent être utilisés pour remplir cette fonction (« RSYNC », « AMANDA » et divers logiciels de backup). Pour AMANDA voir l'article suivant.
Il vaut mieux pour gérer cela sans difficultés « ranger » ses données selon leur importance et/ou leur type dans des répertoires spécifiques faciles à identifier.      

Je connais quelqu'un qui a perdu plusieurs années de photos numérique lors du crash d'un disque, avis aux amateurs de photos.              

Éléments logiques :

Dans un ordinateur le « nerf de la guerre » c'est les programmes, il faut donc les protéger et les surveiller, un programme modifié ou ajouté peut être dangereux (voir utilisation de « TRIPWIRE » (pour la version libre), « AIDE » par exemple pour remplir cette fonction bien que leur paramétrage soit parfois délicat, le moins connu OSSEC, bien que à moitié libre peut aussi être considéré).
Il faut, au minimum, surveiller les répertoires « bin », « sbin » , « lib » , une surveillance de « etc » n'est pas un luxe car certains paramètres et scripts (vous avez dit /etc/init.d ou /etc/hosts.allow ?) peuvent être critiques.
La mise à jour des programmes doit être effectuée par des personnes qualifiées et disposant des droits adéquats (personne ne travaille en permanence comme « root » n'est-ce pas ?).
Si possible les actions doivent être tracées (« sudo » c'est pas mal pour cela).
Si le système et les logiciels doivent être tenus à jour, sur une machine professionnelle il vaut mieux réaliser des tests auparavant afin de s'assurer des incompatibilités éventuelles.  Je me souviens d'une société ayant installé sans tests et automatiquement une mise à jour du système qui a bloqué son principal logiciel de gestion … avec un coût non négligeable.
Une surveillance des logs système est intéressante (et indispensable dans un environnement professionnel), elle peut être aidée par l'utilisation de logiciels spécifiques (voir par exemple « LOGCHECK » qui dégrossit bien les choses, encore faut-il parcourir les mails qu'il vous envoie et effectuer les actions correctives nécessaires).            

Un petit ajout à logcheck :

  • Ajouter le fichier « auth.log » dans « /etc/logcheck/logcheck.logfiles »
  • Créer un fichier « passwd » dans « /etc/logcheck/violations.d » qui ne contient que le mot « password », cela générera dans les rapports une partie spécifique sur les accès au système.
    S'il y a beaucoup d'accès légitimes remplacer « password » par « Failed password »          pour limiter la taille de la liste.         

Un autre aspect de la sécurité/sureté est lié à la supervision des machines, il s'agit là de la sécurité de fonctionnement visant à limiter la durée des incidents en repérant rapidement le service fautif.  Un crtain nombre d'outils existent dans le monde OpenSource dont le plus connu est probablement NAGIOS. Un nouveau concurrent "SHINKEN" très  "Nagios Like" arrive et je vais tenter de le tester.  

Et le petit dernier (testé) COLLECTD qui vous permet de mesurer les performances de vos matériels et logiciels sous forme de classiques graphes RRD, mais la palette des mesures est assez époustouflante.

Pour les outils liés au réseau voir "Securite".

 

taxonomie