Cela fait déjà quelques temps – environ 2 ans en fait – que j'ai monté mon premier home server "Sihaya I" pour enfin pouvoir profiter d'une machine distante connectée 24h sur 24 au Net et totalement esclave de ma volonté (voir "Le rêve geekien" dans l'article précédent).
Au début, avec une installation fraîche et propre, tout tourne bien, c'est rapide, et toute requête est exécutée sans discussion. Puis on commence à ajouter des services divers et variés, un serveur FTP par ci, un noeud Tor par là, qui sont chacun des consommateurs de ressources CPU, RAM, réseau, et parfois toutes à la fois.
Et vient le moment où les limites de la machine – ou celles de sa connexion Internet – sont atteintes et où toute opération devient brutalement soumise à des délais de réponse de plus en plus importants. En termes techniques "ça lagge à mort". Il devient alors indispensable de surveiller la consommation des ressources au plus près, afin d'avoir les billes nécessaires permettant d'optimiser le tout. Et tant qu'à faire, autant par du temps-réel que par des journaux horodatés.
Vient aussi le moment (et ce n'est souvent qu'une question de temps) où la machine devient la cible d'attaques plus ou moins acharnées sur un ou plusieurs de ses services (SSH, HTTP, FTP, …). Même si certains outils comme fail2ban se chargent de limiter (sans empêcher totalement) l'effet de ces attaques, il reste conseillé de vérifier régulièrement leurs journaux afin de prendre des mesures actives si cela devient nécessaire (ne serait-ce que changer les services de port, pour commencer).
Dans les deux cas énoncés précédemment, on touche alors aux outils de monitoring, dont bon nombre sont de petites applications très légères mais d'une redoutable efficacité, capables en deux secondes de trouver le processus occupant 400Mo de RAM, ou utilisant à lui tout seul la moitié du débit montant de la connexion.
La liste qui suit est une présentation succinte et non-exhaustive de tels outils. Ce n'est pas un tutorial, je n'y aborderai donc pas le détail des configurations à effectuer quand il y en a.
Les outils "temps-réel"
htop
Si la commande top est connue de toute personne ayant touché à une machine UNIX dans sa vie, celle-là reste bizarrement peu répandue malgré les fonctionnalités évoluées qu'elle propose.
Ce qui se remarque immédiatement lorsqu'on la lance pour la première fois, ce sont les couleurs ! Alors c'est vrai qu'on perd immédiatement 2 points de charisme geek en n'étant plus obligé de déchiffrer les informations monochromes chères à top, mais on gagne 5 points en décoration (super pratique en période de fêtes).
On retrouve donc en haut à gauche l'utilisation du processeur (ou plus exactement des cores logiques), de la RAM (en vert : occupée, en bleu : les buffers, en jaune : le cache), et de la partition de swap si on en possède une. À droite le nombre de tâches, la charge moyenne à 1, 5 et 15 minutes et le traditionnel uptime de la machine.
Au dessous, c'est l'indispensable tableau des processus avec toutes leurs informations associées. Il est possible d'inverser l'ordre par appui sur [F4], de passer en affichage en arborescence avec [F5], et plein d'autres choses encore.
Quand on y réfléchit, on peut considérer un peu htop comme le Midnight Commander du monitoring de ressources systèmes, c'est à dire à la limite entre l'application graphique qui attire étrangement la main vers la souris et le terminal qui à contrario la retient sur le clavier. Et si je parle de souris ce n'est pas totalement innocent : en effet, cet outil accepte les interactions directes par la souris. Il devient alors possible de modifier le tri du tableau par simple clic sur une colonne, ou de sélectionner un des processus pour le conserver en surbrillance même si sa place dans le tableau vient à évoluer au fil du temps.
On l'aura compris : htop, l'essayer c'est l'adopter.
iftop
Maintenant que la consommation de CPU et de RAM est sous contrôle, passons au réseau. Cette commande nous permet de visualiser l'intensité du trafic entre notre machine et des hôtes distants en fonction des ports (affichables par simple pression des combinaisons [Shift+S] pour les ports sources, et [Shift+D] pour ceux de destination).
La syntaxe de base est :
iftop -i <interface>
Un trafic anormalement élevé observé sur le port X ? Associé à un petit
netstat -np | grep :X
vous saurez retrouver le processus en cause, et ainsi peut être stopper ce comportement si cela se révèle nécessaire.
Le reverse-DNS intégré permet également d'un rapide coup d'oeil de vérifier la provenance des connexions : si 30% du trafic est utilisé par des machines basées en Russie, c'est peut être louche. Si un client de P2P tourne sur la machine, alors c'est tout à fait normal ^^
bmon
On reste dans le réseau mais on s'éloigne de la couche Transport du modèle OSI et de ses ports pour se limiter à constater la forme générale des débits montants et descendants sur chacune de nos interfaces. Cette commande permet de voir en temps-réel l'évolution du trafic sur une interface choisie, et d'en garder la trace générale sur les 60 dernières secondes.
Inutile de dire que cet outil ne sera pas d'une aide très précieuse s'il est utilisé seul dans la recherche d'anomalie. Néanmoins, il offre un résumé appréciable du trafic réseau, à la lecture simple et efficace, et comme toujours, autant utilisable en local que par SSH.
multitail
Un point crucial sur un système UNIX/Linux est la puissance des fichiers de logs cachée sous une apparente simplicité. Le dossier /var/log est une véritable mine d'informations et bien souvent le point de départ de toute analyse d'anomalie a posteriori.
Alors l'astuce que je vais présenter ici n'est pas réellement un outil ni une commande à part entière. Il s'agit simplement d'une utilisation possible de multitail, version "évoluée" du bien connu tail. Cette commande, en plus de gérer plusieurs fichiers simultanément en split-screen (d'où le préfixe "multi"), ajoute la coloration syntaxique, et fournit en standard plusieurs templates prédéfinis (Apache, kernel, …) qu'il est possible de compléter selon ses besoins.
Grâce à multitail donc, on peut choisir une liste de fichiers de log à tracer en temps-réel afin de surveiller la bonne marche de la machine. Je m'en sers personnellement lors de la définition de nouvelles règles iptables en parallèles des tests de connectivité, les paquets rejetés étant inscrits dans le fichier kern.log par exemple.
Voici un exemple de "script" (hem) tout prêt que j'ai placé dans /usr/local/bin et nommé "syslog". Un simple appel à cette commande m'affichant ainsi instantanément les dernières lignes des fichiers syslog, daemon.log et kern.log.
#!/bin/sh
# /usr/local/bin/syslog
multitail -f -i /var/log/syslog -i /var/log/daemon.log -i /var/log/kern.log
Ce n'est pas grand chose, mais comme d'habitude sous Linux, c'est avec les plus petites commandes qu'on produit les meilleurs résultats.
Les outils pour analyse différée
Maintenant que nous sommes capables de surveiller la machine en temps-réel, il faut penser aux (nombreux) moments où nous n'aurons pas les yeux sur les outils précédents. Il faudra alors être capable de retrouver les événements importants survenus au cours d'une période définie, et potentiellement les anomalies qu'ils révèlent.
logwatch
Cet outil, c'est un assistant qui nous envoie chaque matin par mail les logs complets de la machine, mais filtrés sous forme de résumé des actions importantes. Petite liste non-exhaustive, tirée de mon propre serveur :
- Les commandes CRON exécutées (avec le nombre d'exécutions pour chacune),
- Les notifications de blocage de fail2ban,
- Les connexions au serveur IMAP/POP3 et leur source,
- Les requêtes HTTP menant à des codes d'erreurs,
- Les paquets filtrés par iptables/netfilter,
- Les connexions par SSH (et notamment celles échouées) avec les adresses IP sources,
- L'état d'occupation des partitions
La liste obtenue dépend évidemment des services installés sur la machine en question, mais cet exemple illustre bien le champ d'application de logwatch. C'est tout simplement un must-have sur toute machine connectée en permanence à Internet. À chacun ensuite de décider quand lire ces rapports, mais une chose est sûre : la forme est très digeste et leur intérêt loin d'être nul.
Monitorix
Dans la catégorie "graphiques et courbes avec plein de couleurs", Monitorix représente ce que j'ai trouvé de mieux pour conserver une trace générale de la santé de la machine par son activité système. Pas d'informations ultra-précises ici, mais une collection de graphiques colorés accessible via un simple navigateur, et répartis en différentes sections telles que "Utilisation du CPU", "Capteurs de température", "Utilisation des disques", "Charge réseau", etc.
Un job CRON exécuté toutes les minutes se charge de relever les informations sur tout le système. Ces données sont ensuite compilées lors d'un accès à la page afin de produire ces dizaines de courbes. Il est possible de choisir sur la page d'accueil si l'on souhaite consulter les statistiques des dernières 24h, des 7 ou 30 derniers jours, ou carrément des 12 derniers mois pour apprécier l'évolution des différents chiffres.
Toutes les données collectées sont configurables via le fichier /etc/monitorix.conf et il est fortement conseillé d'y jeter un oeil avant toute utilisation intensive car les options par défaut sont génériques et donc peu adaptées à la machine (services inutilisés, interfaces réseau incorrectes, etc.).