Catégorie : Systeme

Présentation des nouveautés de Glances 1.7

Auteur de l’article Par nicolargo
Date de l’article 10/08/2013
9 commentaires sur Présentation des nouveautés de Glances 1.7

De retour de congés avec dans ma besace une nouvelle version de Glances qui sera la dernière version majeure de la série 1.x. La prochaine version sera donc une 2.x avec notamment un gros travail initial de refactoring/découpage du code en modules car le script initial atteint une taille critique (plus de 4400 lignes) qui commence à le rendre difficilement évolutif.

Mais revenons donc à nos moutons pour parler de cette version de Glances 1.7:

Un peu d’histoire

Pour ceux d’entre vous qui découvrent Glances dans ce billet, c’est un projet que j’ai lancé maintenant il y a 2 ans pour palier à un manque dans les outils de supervision système. En effet, j’utilisais tout un tas de logiciels (netstat, top, ntop, ifstat, dstat…) pour investiguer les éventuels problèmes de performance sur un système d’exploitation. Mais aucun ne permettait une visualisation simple (via un terminal par une connexion SSH) et rapide (sur un seul écran) des statistiques nécessaires. Glances était née.

Cette version apporte, en plus de son lot de corrections de bugs, d’améliorations des performances et de la documentation de nouvelles fonctionnalité que nous allons détailler ensemble

Les « Monitored Processes List »

L’objectif qui se cache derrière cette nouvelle fonction est de pouvoir, en un clin d’oeil, voir l’état d’un ensemble de processus regroupés ensemble sous une même thématique.

Par exemple, sur un machine hébergeant un serveur Web dynamique, la supervision des processus « importants » peut se découper de la manière suivante:

Serveur Nginx: processus NGinx
Serveur PHP: processus PHP-FPM
Serveur de caching des pages: processus Varnish
Serveur de base de données: processus MySQL
Serveur de caching des objets: processus Memcached

On a donc 5 objets à superviser. Dans Glances, la définition de ces objets est faite via le fichier de configuration glances.conf. Chaque objet est défini par:

description: description des processus (au maximum 16 caractères, exemple: Serveur Web Nginx)
regex: expression régulière permettant de regrouper les processus dans l’objet (exemple: .*nginx.*)

et optionnellement par:

command: chemin complet vers un script qui sera executé par Glances à chaque rafraichissement (donc toutes les 3 secondes par défaut) et qui devra retourner une chaine de caractère d’une seule et unique ligne contenant des informations utiles pour cet objet. Attention à ne pas utiliser un script trop consommateur de ressources ou bien d’augmenter le temps de rafraichissement (option -t <secondes>)
countmin: nombre minimal de processus attendus. Un message de warning sera affiché si le nombre de processus passe en dessous de cette valeur.
countmax: nombre maximal de processus attendus. Un message de warning sera affiché si le nombre de processus passe en dessus de cette valeur.

Note: par défaut, Glances par sur le principe ou le groupe ne contient qu’un seul processus (donc countmin = countmax = 1)

Ainsi, la configuration de l’objet n°1 (on peut définir jusqu’à 10 objets) correspondant au serveur Web Nginx est donc la suivante:

[monitor]
list_1_description=Serveur Web Nginx
list_1_regex=.*nginx.*
list_1_command=nginx -v
list_1_countmin=1
list_1_countmax=4

Dans Glances, l’affichage des objets se fait de la manière suivante:

La couleur détermine l’état de l’objet. Si le nombre de processus:

est compris entre countmin et countmax alors Glances affichera l’objet en vert (état OK)
est différent de 0 mais non compris entre countmin et countmax alors Glances affichera l’objet en orange (état WARNING)
est égal à 0 alors Glances affichera l’objet en rouge (état CRITICAL)

Comme pour toutes les autres statistiques importantes de Glances, le changement des états est logué.

En mode client/serveur la liste des items est défini au niveau serveur. Une nouvelle entrée dans l’API permet au client de récupérer la liste sur le serveur.

Supervision de la température des disques

Sur certain système, notamment les NAS, la température des disques est un critére important à surveiller. En partant de ce postulat, MendelGusmao a développé un module optionnel (activable en passant l’option -y au lancement de Glances) permettant d’aller récupérer la température des disques sur le daemon HDDTemp qui doit être lancé sur votre machine (voir ici les instructions d’installation de HDDTemp sur Debian/Ubuntu).

Sur ma machine (qui ne comporte qu’un seul disque dur), j’obtiens l’affichage suivant:

Il est bien sûr possible de définir les seuils d’alertes dans la section [hddtemperature] du fichier de configuration de Glances. Les valeurs par défaut sont: CAREFUL=45 / WARNING = 52 / CRITICAL = 60 (en ° celcus).

Information sur l’état de charge de la batterie

J’ai reçu plusieurs demandes d’utilisateur de Glances souhaitant superviser la capacité de la batterie (notamment dans le cas d’utilisation de nano PC autonomes). Premier problème, PsUtil ne remonte pas ce genre de statistiques (du moins dans la version actuelle 1.0). Après une rapide et non exhaustive recherche sur le net d’une bibliothéque Python permettant d’obtenir simplement les informations disponibles sur les systèmes Linux j’ai du me résoudre à coder moi même quelque chose. C’est donc ainsi que Batinfo est apparu il y a quelques semaines.

L’intégration de la librairie Batinfo a été ensuite une formalité et Glances propose donc, si une ou plusieurs batteries sont détectés, l’affichage du pourcentage de capacité restante au milieu du footer:

Limitation: cette statistique est uniquement disponible sur les systèmes Linux.

Une option pour un Glances « low CPU »

Le traitement de la liste comprenant les processus est un des facteur principaux de la consommation CPU de Glances. Sur certain système (notamment les nanos PC comme les Raspberry Pi), il est conseillé de réduire le taux de rafraichissement des statistiques pour faire baisser cette consommation CPU. Cependant, si vous avez besoin d’un taux de rafraichissement important sans avoir besoin du détail des processus alors l’option -r codé par J.Renner est faite pour vous. En lançant Glances avec l’option -r, vous allez désactiver tout les traitements des processus (liste dynamique, monitored process list…) et ainsi disposer d’un Glances faiblement consommateur de CPU.

Sur ma machine de développement, l’utilisation de cette option fait passer la consommation CPU de 2.9% à 0.3%.

Détail de la CPU au lancement de Glances

Une version précédante de Glances voyait apparaître une option (activable en appuyant sur la touche ‘1’ dans Glances) permettatn d’afficher le détail de la CPU par coeur et non plus globalement. Une nouvelle option sur la ligne de commande (-1) permet de lancer par défaut ce mode d’affichage.

IPv6

Enfin un vrai support IPv6 pour le mode client serveur de Glances.

A tester simplement et localement avec:

glances -s -B ::0

pour lancer le serveur en mode IPv6 avec un bind sur toutes les interfaces.

Puis ensuite on lance le client sur le localhost IPv6:

glances -c ::1

Et puis…

Quelques autre petites nouveautés:

Platform/architecture is more specific now
Add support for local conf file
Add a uninstall script
Add getNetTimeSinceLastUpdate() getDiskTimeSinceLastUpdate() and getProcessDiskTimeSinceLastUpdate() in the API
Add more translation: Italien, Chinese

Conclusion

Tout d’abord un grand merci aux principaux contributeurs de cette nouvelle version:

Ensuite, je compte sur vous pour tester cette nouvelle version qui est dès à présent disponible sous Pypi (les packages Debian, BSD, Windows et Mac ne devrait pas trop tarder).

Installation et mise à jour de Glances 1.7

Si vous avez installé Glances via Pypi (ce que je conseille), une mise à jour peut se faire simplement via la ligne de commande:

sudo pip install --upgrade Glances

Pour une installation toute fraîche (pour les nouveaux venus ayant les droits root):

sudo pip install Glances

ou la commande équivalente pour une installation locale (pour les nouveaux venus sans les droits root):

pip install --user Glances

Si vous préférerez utiliser les packages Debian/Ubuntu, Windows et Mac OS, il va falloir attendre un peu que mes « packagers » attitrés bossent un peu.

J’attend vos retours sur les commentaires suivants ou vos retour de bug/demande d’amélioration sur le site du dépôt officiel.

Étiquettes 1.7, glances

Developpement Open-source Planet-libre Systeme

BatInfo, une lib Python pour vos batteries

Auteur de l’article Par nicolargo
Date de l’article 24/06/2013
Un commentaire sur BatInfo, une lib Python pour vos batteries

Je souhaitais ajouter dans Glances un plugin permettant de superviser l’état des batteries. J’ai donc commencé à chercher une librairie Python permettant de s’acquiter le plus simplement possible de cette tache qui sous un système GNU/Linux consiste à analyser le répertoire /sys/class/power_supply maintenu à jour par le noyau Linux.

Comme je n’ai pas trouvé mon bonheur, j’ai donc décidé de développer un librairie Python: BatInfo.

Les sources de cette librairie sont disponibles sur Github en licence LGPL.

Installation

L’installation sur votre système peut se faire simplement via la librairie Pypi:

sudo pip install batinfo

L’utilisation de la librairie dans vos développement Python est la suivante, on commence par inclure la librairie:

import batinfo

Puis on créé une instance (bat) de la classe principale (batteries):

bat = batinfo.batteries()

On peut récupérer les données brutes (format JSON) en utilisant:

bat.stat

[{"status": "Full", "capacity": 50, "name": "CMB1", "uevent": "POWER_SUPPLY_NAME=CMB1\nPOWER_SUPPLY_STATUS=Full\nPOWER_SUPPLY_PRESENT=1\nPOWER_SUPPLY_TECHNOLOGY=Li-ion\nPOWER_SUPPLY_CYCLE_COUNT=0\nPOWER_SUPPLY_VOLTAGE_MIN_DESIGN=10800000\nPOWER_SUPPLY_VOLTAGE_NOW=12496000\nPOWER_SUPPLY_CURRENT_NOW=0\nPOWER_SUPPLY_CHARGE_FULL_DESIGN=5800000\nPOWER_SUPPLY_CHARGE_FULL=5800000\nPOWER_SUPPLY_CHARGE_NOW=3900000\nPOWER_SUPPLY_CAPACITY=100\nPOWER_SUPPLY_MODEL_NAME=CP293550-01\nPOWER_SUPPLY_MANUFACTURER=Fujitsu\nPOWER_SUPPLY_SERIAL_NUMBER=01A-Z100320001158Z", "alarm": 0, "charge_full": 5800000, "voltage_now": 12496000, "serial_number": "01A-Z100320001158Z", "cycle_count": 0, "current_now": 0, "charge_now": 3900000, "voltage_min_design": 10800000, "path": "/sys/class/power_supply/CMB1", "technology": "Li-ion", "manufacturer": "Fujitsu", "type": "Battery", "model_name": "CP293550-01", "present": 1, "charge_full_design":5800000}]

Les données brutes se présentent sous la forme d’une liste de dictionnaire (un dictionnaire par batterie présente sur votre système). Comme la plupart du temps les machines (portable) ont une seule batterie, on peut avoir le dictionnaire associé à cette première batterie avec:

bat.stat[0]

{"status": "Full", "capacity": 100, "name": "CMB1", "uevent": "POWER_SUPPLY_NAME=CMB1\nPOWER_SUPPLY_STATUS=Full\nPOWER_SUPPLY_PRESENT=1\nPOWER_SUPPLY_TECHNOLOGY=Li-ion\nPOWER_SUPPLY_CYCLE_COUNT=0\nPOWER_SUPPLY_VOLTAGE_MIN_DESIGN=10800000\nPOWER_SUPPLY_VOLTAGE_NOW=12496000\nPOWER_SUPPLY_CURRENT_NOW=0\nPOWER_SUPPLY_CHARGE_FULL_DESIGN=5800000\nPOWER_SUPPLY_CHARGE_FULL=5800000\nPOWER_SUPPLY_CHARGE_NOW=3900000\nPOWER_SUPPLY_CAPACITY=100\nPOWER_SUPPLY_MODEL_NAME=CP293550-01\nPOWER_SUPPLY_MANUFACTURER=Fujitsu\nPOWER_SUPPLY_SERIAL_NUMBER=01A-Z100320001158Z", "alarm": 0, "charge_full": 5800000, "voltage_now": 12496000, "serial_number": "01A-Z100320001158Z", "cycle_count": 0, "current_now": 0, "charge_now": 3900000, "voltage_min_design": 10800000, "path": "/sys/class/power_supply/CMB1", "technology": "Li-ion", "manufacturer": "Fujitsu", "type": "Battery", "model_name": "CP293550-01", "present": 1, "charge_full_design":5800000}

Les statistiques présentes dans le dictionnaire dépende de votre batterie. Mais on retrouve un certain nombre d’informations génériques comme par exemple la capacité restante (en %):

bat.stat[0].capacity

50

la capacité maximale:

bat.stat[0].charge_full

5800000

ou encore la capacité courante:

bat.stat[0].charge_now

3900000

On peut aussi avoir des informations constructeurs:

bat.stat[0].manufacturer

'Fujitsu'

bat.stat[0].technology

'Li-ion'

En espérant que cette librairie soit utile à certains. Si vous avez des remarques/rapports de bug à faire, merci d’utiliser le Github: https://github.com/nicolargo/batinfo/issues

Il ne me reste plus, pour ma part, qu’à intégrer cela dans Glances.

Étiquettes bat, batterie, battery, lib, portable, python

Open-source Planet-libre Systeme

Ma méthode pour gérer les règles IpTables

Auteur de l’article Par nicolargo
Date de l’article 10/06/2013
24 commentaires sur Ma méthode pour gérer les règles IpTables

« Ooopsss… »

Cette phrase a été prononcée au moins une fois par toute personne ayant administré les règles de Firewall d’un serveur. Les conséquences vont du simple blocage d’une application critique (dont on s’aperçoit de l’indisponibilité au prochain « check » sur son serveur de monitoring) à la perte de connexion pure et simple vers la machine (même pour corriger sa boulette).

Pour éviter de se retrouver dans cette situation et ainsi éviter les rires et moqueries des collègues, voici quelques pistes que j’utilise pour administrer mes règles IpTables sur mes serveurs Debian.

1. Regrouper la sécurité dans un script de démarrage

Il y a plusieurs écoles pour gérer les règles de Firewall. Celle proposée par le wiki officiel de Debian repose sur l’utilisation exclusive des commandes iptables-save et iptables-restore qui permettent respectivement de sauvegarder et de restaurer une configuration IpTables existante.

Pour ma part, je préfère inclure ces commandes dans un script de plus haut niveau que je positionne dans le répertoire /etc/init.d et qui sera donc lancé au démarrage du serveur. Ce fichier firewall.sh est disponible sur mon GitHub DebianPostInstall ou via Gist.

En voici une version à ce jour:

Par défait le script met en place les règles suivantes:

autorise les connexions SSH entrantes (pour administrer son serveur à distance)
autorise les connexions HTTP, HTTPs et DNS sortante (pour l’installation et mise à jour du système et des logiciels)
interdiction et log des autres flux, entrant et sortant
et en cadeau bonux (ce qui on plus de 35 ans peuvent comprendre) sécurise un peu plus le kernel Linux

L’utilisation de ce script est standard, ainsi pour appliquer les règles de Firewall:

sudo service firewall.sh start

Pour supprimer les règles de Firewall (attention votre serveur sera ainsi exposé aux attaques extérieures puisqu’aucunes restriction d’accès ne sera appliquée):

sudo service firewall.sh clear

Attention: Il est également possible d’utiliser cette commande avec l’option stop (sudo service firewall.sh stop), mais il faut être conscient que toutes les connexions, entrantes et sortantes seront alors interdites (même votre SSH !!!). Cette commandes est donc à ~~éviter~~ bannir si l’on utilise une connexion à distance pour administrer son serveur…

2. Modifier les règles

On entre ici dans le vif du sujet de ce billet: Comment procéder quand on doit modifier les règles de sécurité ?

La première chose à faire est d’être sûr d’avoir les connaissances nécessaires avant de toucher à quoi que ce soit. Cela peut sembler évident, mais faire des copier/coller de règles trouver sur le net et que l’on ne maîtrisent pas est, sans aucun doute, le meilleur moyen de tout faire planter. Pour modifier les tables IpTables, il faut donc avoir un verni de connaissance général sur le protocole TCP/IP (notamment les notions d’adresses et de port sources/destinations). On trouve pour cela quelques très bon cours en ligne comme celui de chez Developpez.com ou bien la bible de Tanenbaum: Réseaux 5em édition aux éditions Pearson. Bien évidemment, il faut également connaitre les rudiments de la commande IpTables en lisant la documentation officielle (disponible en Français) et notamment la section sur le filtrage de paquets.

On peut passer aux choses sérieuses en identifiant les règles courantes grâce à la commande:

sudo iptables -n -L -v --line-numbers

On obtiendra alors une sortie dépendante des règles actives (exemple pour un de mes serveurs):

Chain INPUT (policy DROP 13 packets, 1398 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1     381M  138G fail2ban-ALL  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           
2     495K   83M fail2ban-SSH  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22 
3     251M   23G fail2ban-HTTP  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:80 
4     380M  138G fail2ban-ALL  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           
5     606M  241G ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
6    64473 3711K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22 
7      12M  653M ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:80 
8        1    44 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:1337 
9    55724 3343K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:4949 
10      85  4064 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:5001 
11   53603 3216K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:61209 
12      13   532 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:123 
13    224K   21M ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:161 
14       0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:5001 
15       0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22 
16    230K   22M ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           
17   4822K  289M ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
18   3684K  435M LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 4 
19       0     0 ACCEPT     tcp  --  *      *       88.190.254.200       0.0.0.0/0           tcp spt:20 

Chain FORWARD (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1      98M  183G ACCEPT     all  --  *      lo      0.0.0.0/0            0.0.0.0/0           
2     253M  912G ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
3        1    84 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           
4        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            195.20.242.89       tcp dpt:80 
5        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            212.211.132.32      tcp dpt:80 
6        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            212.211.132.250     tcp dpt:80 
7      179 10740 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:21 
8      276 14700 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22 
9     1254 75180 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:25 
10   91789 5507K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:80 
11   12940  776K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:443 
12    688K   46M ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpts:1024:65534 
13     90M 5705M ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:53 
14   30171 2293K ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:123 
15       0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            88.190.254.200      tcp dpt:21 
16      78  3120 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 4 
17      78  3120 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable 

Chain fail2ban-ALL (2 references)
num   pkts bytes target     prot opt in     out     source               destination         
1     761M  277G RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0           
2        0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain fail2ban-HTTP (1 references)
num   pkts bytes target     prot opt in     out     source               destination         
1     251M   23G RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain fail2ban-SSH (1 references)
num   pkts bytes target     prot opt in     out     source               destination         
1       10  1568 DROP       all  --  *      *       61.155.150.217       0.0.0.0/0           
2     408K   77M RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

Une fois que vous avez identifié la règle IpTables à ajouter dans votre configuration, il est maintenant temps de passer à l’action.

Ne jamais, jamais, modifier directement la table avec une commande IpTables sur un serveur en production…

Plusieurs solutions sont possibles, personnellement, j’utilise la méthodologie suivantes:

je commence par copier le script firewall.sh dans un autre répertoire (par exemple dans /tmp/firewall.sh)
j’ajoute la règle IpTables dans la copie du script (/tmp/firewall.sh)
je teste les nouvelles règles en utilisant l’option « test » du script ainsi modifié qui va sauvegarder les règles actuelles, appliquer les nouvelles, attendre 30 secondes puis ré-appliquer les règles actuelles (donc au pire au fait une boulette de 30 secondes…)
si tout se passe comme attendu pendant les 30 secondes, alors je copie le fichier /tmp/firewall.sh sous /etc/init.d
et j’applique les règles en production le moment voulu

Les lignes de commandes correspondantes sont:

sudo cp /etc/init.d/firewall.sh /tmp/
sudo vim /tmp/firewall.sh
sudo sh /tmp/firewall.sh test
sudo cp /tmp/firewall.sh /etc/init.d/
sudo service firewall.sh restart

Ainsi, en cas de problème dans les règles, le serveur ne sera indisponible que pendant 30 secondes. Dans le cas « pas de bol » ou le serveur crache durant ces 30 secondes alors les anciennes règles seront rechargées au redémarrage.

Pas de script ?

Si vous ne souhaitez pas mettre en place un tel script de démarrage des règles de Firewall, il est quand même possible (même si je ne le conseille pas pour avoir une vue d’ensemble des règles à appliquer) de reproduire la méthodologie d’écrite dans le chapitre précédant.

Ainsi, il est tout à fait possible d’utiliser une commande du type:

sudo iptables-save > /etc/iptables.backup && sudo iptables <nouvelle regle a appliquer> && sleep 30 && sudo iptables-restore < /etc/iptables.backup

Conclusion

Comment gérez-vous vos règles de Firewall sur vos serveurs GNU/Linux ? Des astuces à partager avec nous dans les commentaires ?

Étiquettes best, iptables, practice

Open-source Planet-libre Systeme

Encore un effort pour la libération du cahier Debian

Auteur de l’article Par nicolargo
Date de l’article 02/06/2013

Mise à jour du billet

La libération du livre est désormais acquise, merci à vous tous !

Il est cependant possible de continuer à y participer pour soutenir un peu plus le projet Debian.

===

Raphaël Hertzog s’est lancé dans un projet qui mérite un petit coup de pouce de la part de la communauté des logiciels libres: la libération du Cahier Debian, la référence littéraire pour les utilisateurs et administrateurs du système d’exploitation Debian (traduction et adaptation de la version originale en Anglais de « The Debian administrator’s Handbook »).

Trois objectifs sont en fait visés:

garantir la libération du livre
effectuer sa mise à jour pour Debian 7
mise en place d’une nouvelle édition en librairie

Pour cela Raphaël et Roland, après négociation préalable avec l’éditeur Eyrolles, sont passés par un système de financement de type « crowfunding ». Ainsi, à partir du site Ulule, il vous est possible de participer à cette aventure en finançant en amont ce beau projet. Pour cela, plusieurs offres sont possibles, de 5€ à 600€+ pour les plus riches :). Pour que celle-ci commence vraiment et que le projet soit réalisé, il faut un minimum de 15.000€.

A l’heure actuelle (2 juin à 18h), il reste encore 4.500€ à trouver.

Je compte sur vous pour donner quelques €€€€.

Cliquez ici pour participer au projet de libération du cahier Debian !

Bonne fin de week-end !

Note: personnellement, je trouve l’offre à 50€ la plus atractive car elle permet d’avoir le cahier au format papier (c’est mon coté old school qui parle).

Étiquettes cahier, debian

Open-source Planet-libre Systeme

De Squeeze à Wheezy…

Auteur de l’article Par nicolargo
Date de l’article 05/05/2013
14 commentaires sur De Squeeze à Wheezy…

Depuis aujourd’hui, Wheezy est officiellement devenue la septième version stable du système d’exploitation GNU/Linux Debian. Nous allons dans ce billet voir une migration simple d’un serveur Squeeze (Debian 6) vers cette nouvelle version de Debian. Cette migration est adapté uniquement aux serveurs avec une configuration standard. Pour des configurations exotiques, je vous conseille fortement de suivre la procédure officielle très bien détaillée sur le site de Debian.

Avant de commencer…

Effectuez la migration à un moment ou vous avez du temps et ou votre serveur n’est pas beaucoup sollicitée (par exemple un dimanche pour un serveur perso).
Sauvegarder vos données avant de commencer.
Préparez une procédure de ré-installation simple et rapide au cas ou quelque chose se passe mal.
Idéalement se faire la main sur un serveur non critique avant de passer aux serveurs critiques.
Pas de panique, ce n’est que de l’informatique.

Se loguer en root (ou avec un user ayant les droit root):

su - root

On commence par préparer le terrain

Avant de procéder à la migration vers Wheezy, il faut s’assurer que votre Squeeze et propre et à jour. Pour cela, on commence par mettre à jour les repos et les packages Squeeze:

$ apt-get update && apt-get upgrade

On doit ensuite et c’est une des étapes les plus lourdes, vérifier que l’ensemble des repos non standards sont disponibles pour Wheezy.

On commence par visualiser le fichier /etc/apt/sources.list:

deb http://debian.mirrors.ovh.net/debian/ squeeze main
deb-src http://debian.mirrors.ovh.net/debian/ squeeze main

deb http://security.debian.org/ squeeze/updates main
deb-src http://security.debian.org/ squeeze/updates main

## DotDeb Package
deb http://packages.dotdeb.org squeeze all
deb-src http://packages.dotdeb.org squeeze all

On peut donc voir que j’utilise les miroirs officiels de Debian fournis par OVH (l’hébergeur de mon serveur de test) qui sont disponibles pour Wheezy ainsi que le repo DotDeb également disponible pour Wheezy.

On poursuit avec les repos disponibles sous /etc/apt/sources.list.d/. Je n’ai personnellement qu’un seul repo qui est compatible avec Wheezy:

$ cat /etc/apt/sources.list.d/10gen.list

deb http://downloads-distro.mongodb.org/repo/debian-sysvinit dist 10gen

Pour les utilisateurs de sudo

Si vous utilisez sudo sur votre système, il faut effectuer les manipulations suivantes avant la mise à jour sous peine de se retrouver sans fichier de configuration valable.

cp /etc/sudoers /etc/sudoers.d/mysettings

On édite ensuite le fichier /etc/sudoers.d/mysettings pour lui enlever les lignes Defaults et #includedir. Lors de l’upgrade, le fichie /etc/sudoers doit être remplacé par le nouveau.

Pour les utilisateurs de php5-suhosin

Le paquet php5-suhosin n’existe plus dans cette nouvelle version de Debian. Il faut donc saisir la commande suivante pour supprimer la configuration correspondante /etc/php5/conf.d/suhosin.ini:

dpkg --purge php5-suhosin

Puis on migre vers Debian 7 (aka) Wheezy

Si tous les repos que vous utilisez sont compatibles, alors il suffit de saisir la commande suivante pour migrer les fichiers de configuration vers Wheezy:

sed -i 's/squeeze/wheezy/g' /etc/apt/sources.list
for i in `ls /etc/apt/sources.list.d/*.list`; do sed -i 's/squeeze/wheezy/g' $i; done

On va ensuite enchaîner la mise à jour proprement dite en faisant:

une mise à jour des sources (repos)
une première mise à jour minimale
une seconde mise à jour totale

apt-get update
apt-get upgrade
apt-get dist-upgrade

Il ne vous reste plus qu’à attendre et vérifier qu’il n’y a pas de problème lors des ces trois étapes. Si vous avez une erreur, attention de bien la résoudre (Google est ton ami) avant de passer à l’étape suivante. PAr exemple, il est possible que certains paquets n’arrive pas à se mettre à jour. Les deux ligne suivantes devraient corriger ce problème:

apt-get -f install
apt-get dist-upgrade

On finalise la configuration en vérifiant que le fichier

Sinon, il ne vous reste plus qu’à redémarrer votre serveur (cette dernière étape étant facultative).

Étiquettes debian, maj, squeeze, upgrade, wheezy

Open-source Planet-libre raspberry Systeme

Raspberry Pi – Faire un backup de sa carte SD

Auteur de l’article Par nicolargo
Date de l’article 22/04/2013
18 commentaires sur Raspberry Pi – Faire un backup de sa carte SD

Ce qu’il y a de bien avec un Raspberry Pi c’est que l’on peut passer d’un système à l’autre en changeant simplement de carte SD et en redémarrant la machine. On peut ainsi avoir une carte avec une distribution classique (Raspbian), une autre avec un média center (OpenELEC ou Raspbmc) ou encore une autre avec un desktop light (ArchLinux). L’idéal étant d’avoir à disposition autant de cartes SD que de systèmes (vu le prix des cartes, ce n’est pas un gros investissement).

Cependant, il est parfois utile, pour des tests ou pour économiser le nombre de ces cartes de sauvegarder puis de restaurer l’image disque sur une machine GNU/Linux classique. C’est ce que nous allons voir dans ce billet.

Sauvegarde intégral d’une carte SD

On commence par insérer la carte SD dans le lecteur du PC GNU/Linux sur lequel on veut faire la sauvegarde.

Pour identifier le périphérique correspondant à la carte SD à sauvegarder sur son système, il suffit de saisir la commande suivante et de regarder le device qui correspond à sa carte SD:

$ sudo fdisk -l
[sudo] password for nicolargo: 

Disk /dev/sda: 320.1 GB, 320072933376 bytes
255 têtes, 63 secteurs/piste, 38913 cylindres, total 625142448 secteurs
Unités = secteurs de 1 * 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Identifiant de disque : 0x000e3a56

Périphérique Amorce  Début        Fin      Blocs     Id  Système
/dev/sda1   *        2048   617170943   308584448   83  Linux
/dev/sda2       617172990   625141759     3984385    5  Étendue
/dev/sda5       617172992   625141759     3984384   82  partition d'échange Linux / Solaris

Disk /dev/sdb: 16.0 GB, 16012804096 bytes
64 têtes, 32 secteurs/piste, 15271 cylindres, total 31275008 secteurs
Unités = secteurs de 1 * 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Identifiant de disque : 0x00014d34

Périphérique Amorce  Début        Fin      Blocs     Id  Système
/dev/sdb1            8192      122879       57344    c  W95 FAT32 (LBA)
/dev/sdb2          122880    31275007    15576064   83  Linux

J’ai donc deux disques détectés sur ma machine:

/dev/sda (disque de 320 Go) qui est mon disque dur système sur mon PC portable. Ce n’est pas ce disque que l’on veut sauvegarder.
/dev/sdb (disque de 16 Go) qui est ma carte SD que je souhaite sauvegarder.

On lance la sauvegarde avec la commande suivante:

sudo dd if=/dev/sdb | gzip -9 > ./raspberry-20130420-sdb.img.gz

Restauration intégrale d’une carte SD

Après avoir inséré la clé USB sur laquelle on souhaite faire la restauration (attention la clé va être effacée), on commence par identifier l’identifiant du périphérique comme dans le paragraphe précédant (/dev/sdb dans mon cas).

Puis ensuite, il suffit de saisir la ligne de commande:

gunzip ./raspberry-20130420-sdb.img.gz | sudo dd of=/dev/sdb

—

Nous allons ensuite voir comment sauvegarder les carte SD partition par partition, ce qui peut être utile si vous ne voulez que sauvegarder le système et pas une éventuelle partition de données.

Sauvegarde partition par patition d’une carte SD

Comme on peut le voir sur les deux dernières lignes de la commande fdisk du premier paragraphe , la carte SD (point de montage /dev/sdb dans mon cas) comporte deux partitions (mais il peut y en avoir plus selon la configuration de votre Raspberry Pi).

Il faut sauvegarder toutes les partitions:

sudo dd if=/dev/sdb1 | gzip -9 > ./raspberry-20130420-sdb1.img.gz
sudo dd if=/dev/sdb2 | gzip -9 > ./raspberry-20130420-sdb2.img.gz

Ces commandes peuvent prendre plus ou moins de temps selon la taille de votre carte SD. J’ai ainsi mis plus d’une dizaine de minute pour faire la sauvegarde de ma carte SD de 16 Go. On voit ici l’avantage de choisir la taille de ses cartes SD en fonction de ses besoins…

Restauration partition par patition d’une carte SD

Nous allons maintenant restaurer la carte préalablement sauvegardée. La procédure consiste à créer les partitions avec la commande fdisk puis ensuite à y écrire les images avec dd.

On part sur le principe ou la carte est vierge est sans partition (sinon utilisé la commande d pour chacune des partitions puis w pour valider):

$ sudo fdisk /dev/sdb

Commande (m pour l'aide): p

Disk /dev/sdb: 16.0 GB, 16012804096 bytes
64 têtes, 32 secteurs/piste, 15271 cylindres, total 31275008 secteurs
Unités = secteurs de 1 * 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Identifiant de disque : 0x00014d34

Périphérique Amorce  Début        Fin      Blocs     Id  Système

On commence par créer le première partition (sdb1):

Commande (m pour l'aide): n
Partition type:
   p   primary (0 primary, 0 extended, 4 free)
   e   extended
Select (default p): p
Numéro de partition (1-4, par défaut 1): 
Utilisation de la valeur par défaut 1
Premier secteur (2048-31275007, par défaut 2048): 8192
Dernier secteur, +secteurs or +taille{K,M,G} (8192-31275007, par défaut 31275007): 122879

Commande (m pour l'aide): t
Partition sélectionnée 1
Code Hexa (taper L pour lister les codes): c
Type système de partition modifié de 1 à c (W95 FAT32 (LBA))

puis la seconde (sdb2):

Commande (m pour l'aide): n
Partition type:
   p   primary (1 primary, 0 extended, 3 free)
   e   extended
Select (default p): p
Numéro de partition (1-4, par défaut 2): 
Utilisation de la valeur par défaut 2
Premier secteur (2048-31275007, par défaut 2048): 122880
Dernier secteur, +secteurs or +taille{K,M,G} (122880-31275007, par défaut 31275007):

Commande (m pour l'aide): p

Disk /dev/sdb: 16.0 GB, 16012804096 bytes
64 têtes, 32 secteurs/piste, 15271 cylindres, total 31275008 secteurs
Unités = secteurs de 1 * 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Identifiant de disque : 0x00014d34

Périphérique Amorce  Début        Fin      Blocs     Id  Système
/dev/sdb1   *        8192      122879       57344    c  W95 FAT32 (LBA)
/dev/sdb2          122880    31275007     15576064  83  Linux

On valide les partitions:

Commande (m pour l'aide): w
Synchronisation des disques.

Ensuite on restaure les images:

gunzip ./raspberry-20130420-sdb1.img.gz | sudo dd of=/dev/sdb1
gunzip ./raspberry-20130420-sdb2.img.gz | sudo dd of=/dev/sdb2

Et voilà le travail !

Étiquettes backup, restore, sd

Open-source Planet-libre Systeme

Glances a son application Android

Auteur de l’article Par nicolargo
Date de l’article 15/04/2013
2 commentaires sur Glances a son application Android

Jon Renner est un des contributeur actif du projet Glances. Il vient de mettre en ligne sur Google Play la première version de son client Glances pour Android (cliquer ici pour télécharger Android Glances).

Ce client permet d’aller directement consulter les statistique d’un serveur Glances à partir d’un smartphone ou d’une tablette Android.

Contrairement au projet MetaGlances (dont j’ai parlé la semaine dernière), il ne necessite pas de machine intermédiaire et utilise une connection directe (via XML RPC) entre un device Android et votre serveur (qui doit bien sûr pésenter une interface publique). Pour cela, Jon a développé une API Glances en Java qui peut être récupéré et utilisé pour d’autres besoins.

Encore un grand bravo/merci pour son travail sur le coeur de Glances et pour le développement de l’ecosystème qui est en train de ce construire autour de Glances.

Quelques liens:

Étiquettes android, glances

Open-source Planet-libre Systeme Web

MetaGlances, une interface pour les gouverner tous…

Auteur de l’article Par nicolargo
Date de l’article 08/04/2013
25 commentaires sur MetaGlances, une interface pour les gouverner tous…

Depuis la version 1.5 de Glances et la mise à disposition d’une API au format JSON XML/RPC, l’écosystème autour de Glances grandit petit à petit. Un des premier projet à avoir vu le jour est MetaGlances, une interface Web « responsive » permettant de centraliser la gestion de ses serveurs Glances.

Développée par Laurent Spinelli (aka spin0us) et distribuée sous licence GPL version 3, cette interface s’installe en quelques commandes sur un serveur Web et permet grâce à un mélange de scripts PHP (pour l’interface JSON XML/RPC avec les serveurs Glances) et HTML/JavaScript/JQuery (pour l’UI):

d’ajouter un nombre illimité de machines à surveiller (ces machines n’ayant comme seul pré-requis d’avoir le Glances serveur lancé et accessible et peut donc surveiller de machines GNU/Linux, BSD, Mac OS ou Windows)
de visualiser les statistiques (pour l’instant limités à la CPU, mémoire, charge, débits des interfaces réseau, entrées/sorties disques et espaces disponibles sur les systèmes de fichiers)
de sauvegarder votre liste de serveurs à surveiller sur un compte « cloud » (enfin de pouvoir retrouver sa configuration d’une machine à l’autre)
de disposer d’une interface « responsive » donc qui s’adapte à votre navigateur (par exemple un screenshot de MetaGlances dans un navigateur Chromium sous Ubuntu puis dans un même navigateur Chromium sur un iPhone 4)

Installer son propre serveur MetaGlances

Si vous disposez d’un serveur Web opérationnel (sinon vous pouvez toujours utiliser ce script d’installation automatique de Nginx) avec par exemple pour racine /var/www alors l’installation nécessite la saisie des commandes suivantes:

cd /var/www
sudo git clone https://github.com/spin0us/MetaGlances
sudo mkdir -p /var/www/MetaGlances/cache/config /var/www/MetaGlances/cache/data
sudo chown -R www-data:www-data /var/www/MetaGlances

Puis saisir l’URL de votre serveur MetaGlances: http://nomdevotreserveur/MetaGlances

La configuration de MetaGlances est centralisé dans le fichier /var/www/MetaGlances/config.php.

MetaGlances est en cours de développement. Pour mettre à jour votre serveur avec la dernière version, il faudra saisir les commandes:

cd /var/www/MetaGlances
sudo git pull
sudo chown -R www-data:www-data /var/www/MetaGlances

Ou tester directement en ligne !

J’ai installé MetaGlances sur un de mes serveurs. Vous pouvez donc directement superviser vos machines disposant d’une interface IP publique et sur lesquelles Glances serveur est lancé (je vous conseille de lancer Glances en configurant un mot de passe et si possible en filtrant à l’aide d’un Firewall les accès entrant venant de mon serveur).

Pour tester MetaGlances cliquez sur le lien suivant: http://metaglances.nicolargo.com

Attention: ce serveur MetaGlances est uniquement mis à disposition pour tester MetaGlances. Ne pas s’en servir pour en production, il peut être arrêté mis à jour ou déplacé sans préavis.

Utilisation de MetaGlances

Grâce au travail de Laurent, l’utilisation est assez intuitive. Je vous la laisse découvrir dans cette série de screenshots:

Ajout d’un serveur à superviser

Saisie des informations sur le serveur Glances

Affichage de la liste des serveurs

Affichage des statistiques d’un serveur Glances

Accès au cloud MetaGlances

Création d’un compte MetaGlances

Sauvegarde ou restauration de la liste des serveurs Glances

Nous avons besoin de VOUS !

MetaGlances est en cours de développement et Laurent Spinelli, le créateur à besoin de bêta testeurs pour améliorer ce logiciel. Si vous rencontrez un bug ou que vous trouvez qu’il manque des fonctions, n’hésitez pas à le dire directement via la page suivante sur le GitHub officiel.

Perso, je suis fan de MetaGlances, il y a un bon potentiel pour en faire un outil simple de supervision système.

Vous en pensez quoi ?

Étiquettes glances, metaglances

Open-source Planet-libre Systeme

Glances 1.6.1 est dans les bacs

Auteur de l’article Par nicolargo
Date de l’article 24/03/2013
4 commentaires sur Glances 1.6.1 est dans les bacs

Evolution pas si mineure que cela pour Glances, l’outil de supervision système, que je viens de publier en version 1.6.1. Cette version est sûrement la plus stable et la plus facile à faire évoluer (en prévision des futures raodmaps 1.7 puis 2.0). Un grand merci à Alessio Sergi, contributeur depuis maintenant pas mal de temps sur Glances et surtout Jon Renner pour cette version qui a effectué un gros et bon boulot.

Quoi de neuf ?

La liste complète est disponible dans le ChangeLog, mais on peut retenir:

le support multi utilisateur du fichier de configuration (il suffit pour cela de créer un fichier de configuration dans votre répertoire $HOME/.config/glances/)
Ajout de la touche ‘t’ pour afficher le trafic réseau sous la forme upload + download
Ajout de la touche ‘u’ pour afficher le trafic réseau non pas en débit mais en cumulé
Ajout de l’option -z (ou –nobold) pour améliorer l’affichage de Glances dans un terminal avec un style solarized
Amélioration de la précision d’affichage des statistiques
Prise en compte du nombre de CPU dans le calcul de la limite CPU des process
Amélioration de l’API pour y intégrer le temps depuis la dernière mise à jour des stats afin de pouvoir calculer des débits cotés clients
Amélioration de l’affichage de l’aide
Reprise totale du code pour ignorer les versions de PsUtil inférieure à la 0.4.1 (gros boulot d’Alessio !)
Ajout d’un script d’init (Debian) pour le serveur Glances
et bien sûr un bon nombre de correction de bug…

Comment mettre à jour | installer Glances

Toutes les informations sont disponibles sur la page officielle de Glances mais pour ceux qui ont installé une ancienne version via Pypi, il suffit de saisir la commande:

sudo pip install --upgrade Glances

D’autres nouvelles de l’écosystème Glances

Ce que j’aime avec Glances, c’est l’écosystème qui est en train de se construire autour de ce projet. J’ai d’ailleurs en préparation un billet pour parler de tous les projets gravitant dans cette sphère. Mais dès aujourd’hui je voudrais en mentionner deux:

PHPGlances que Franck Lefevre (aka) Progi1984 nous présente sur son blog
Java-Glances de John Renner, également contributeur sur cette version et qui travaille sur un client Android pour Glances !

Pour finir

Je suis bien sûr preneur de vos remarques/avis sur cette nouvelles version de Glances.

Les commentaires ci-dessous sont fait pour cela 🙂

Étiquettes 1.6.1, glances

Open-source Planet-libre raspberry Systeme

Mes 5 premières minutes sur un serveur Debian

Auteur de l’article Par nicolargo
Date de l’article 14/03/2013
30 commentaires sur Mes 5 premières minutes sur un serveur Debian

Sur une idée originale pompée honteusement sur le blog de Bryan Kennedy.

La virtualisation ou la possibilité d’acheter des machines à bas prix comme le Raspberry implique le fait que l’installation de serveurs devient une tâche de plus en plus fréquente. Afin d’éviter les grossières erreurs qui peuvent rapidement devenir fatales si la machine est exposée au réseau Internet, voici les actions que j’effectue systématiquement sur mes systèmes d’exploitations Debian ou Ubuntu Server.

Si vous suivez ce blog, vous savez que je suis un gros fainéant pour ce genre de tâches récurrentes. J’ai donc écrit un ensemble de scripts permettant d’effectuer les actions de « post installation ». J’ai également commencé à regarder du coté des systèmes de gestion de configuration comme Puppet qui sont des solutions à utiliser en priorité si vous avez un parc informatique important.

L’objectif de ce billet est donc pédagogique pour partager avec vous les actions à effectuer et, je l’espère, en apprendre de nouvelles.

Assez de palabres, place au clavier…

1) S’occuper de ses comptes

Je parle bien évidemment ici des comptes utilisateurs qu’il va falloir sécuriser. On commence par le compte root qui ne sera PAS (jamais, c’est mal) utilisé directement pour vous connecter sur votre machine. Lors de l’installation du système, il faut saisir un mot de passe sécurisé, c’est à dire assez long avec un mélange de lettres, de chiffres et d’autres caractères mais sans utiliser des mots connus ou des suites de chiffres. Vous n’avez pas besoin de connaitre ce mot de passe par coeur mais il faudra le conserver bien au chaud.

Une fois logué sur la machine (on durant la phase d’installation du serveur), on commence par créer un utilisateur principal que l’on utilisera pour se connecter à la machine.

J’ai choisi morpheus pour illustrer mon billet.

useradd morpheus
mkdir /home/morpheus

La suite des opérations sera donc faite à partir de cet utilisateur.

2) S’occuper de ses portes d’entrées avec SSHd

SSH est devenu le mode d’accès le plus utilisé pour accéder aux serveurs GNU/Linux. Par défaut, il propose un contrôle d’accès par nom d’utilisateur et mot de passe. J’essaye au maximum d’éviter cette solution. J’utilise le système d’authentification par clé publique qui est un peu plus lourde à mettre en oeuvre et à administrer mais qui offre un niveau de sécurité plus important.

Pour ajouter la clé publique de mon PC avec lequel je vais me connecter au serveur, il suffit de lancer la commande suivante à partir de cette machine:

ssh-copy-id morpheus@monserveur

Puis on force l’utilisation de l’authentification par clé publique et on ferme ensuite cette porte à l’utilisateur root:

sudo vim /etc/ssh/sshd_config

PasswordAuthentication no
PermitRootLogin no

Attention: l’authentification par nom d’utilisateur / mot de passe sera désactivée pour les accès SSH.

On relance ensuite le daemon SSH:

sudo service  ssh restart

3) Contrôler les entrées avec Fail2ban

Une fois le daemon SSH sécurisé, il faut ensuite ajouter une couche permettant de contrôler plus finement les accès. J’utilise pour cela Fail2ban que j’ai abordé plus précisément dans un précédant billet. Dans notre sujet du jour, je vais configurer Fail2ban pour bloquer, pendant 5 minutes, l’accès à SSH à un utilisateur qui se trompe 3 fois de mot de passe.

On commence par installer fail2ban:

sudo apt-get-install fail2ban

On va ensuite éditer le fichier /etc/fail2ban/jail.conf pour le configurer comme l’on souhaite:

[ssh]
enabled = true
port = ssh
filter = sshd
action = iptables[name=SSH, port=ssh, protocol=tcp]
logpath = /var/log/auth.log
maxretry = 3
bantime = 300

On relance ensuite le service pour prendre en compte la configuration:

sudo service fail2ban restart

4) Fermer les fenêtres (de votre Firewall)

Comme nous l’avons vu dans le point précédant, Fail2ban utilise le Firewall IPtable qui part défaut laisse passer l’ensemble des flux. J’applique systématiquement une configuration beoucoup plus restrictive qui autorise les flux SSH entrant (pour l’accès à distance) et HTTP/HTTPs/DNS sortant (pour la mise à jour de mon serveur).

J’utilise pour cela un script de démarrage maison:

sudo wget --no-check-certificate -O /etc/init.d/firewall.sh https://raw.github.com/nicolargo/debianpostinstall/master/firewall.sh
sudo chmod a+x /etc/init.d/firewall.sh

que je lance au démarrage de la machine (et aussi immédiatement):

sudo update-rc.d firewall.sh defaults 20
sudo service firewall start

Il est bien sûr possible d’adapter ce script à vos besoins de flux entrants et sortants en éditant les lignes suivantes:

# Services that the system will offer to the network
TCP_SERVICES="22" # SSH only
UDP_SERVICES=""
# Services the system will use from the network
REMOTE_TCP_SERVICES="80 443" # web browsing
REMOTE_UDP_SERVICES="53" # DNS

5) Prendre soin de ses fondations en tenant son système à jour

Maintenir à jour ses serveurs est une tâche à la fois indispensable et rébarbative. Il y a ici deux écoles possibles. La première est d’utiliser un logiciel comme unattended-upgrades qui va installer automatiquement pour vous les mises à jours de sécurités ou même l’ensemble de votre système. C’est une solution élégante mais qui n’est pas sans risque si un pépin arrive suite à une mise à jour alors que vous êtes loin de vous machines. J’opte donc pour la seconde solution, basée sur cron-apt, qui va me notifier par mail les mises à jours à effectuer sur mes machines.

On installe cron-apt avec la commande:

sudo apt-get install cron-apt

Puis on configure l’adresse mail de destination des messages de notifications dans le fichier /etc/cron-apt/config:

MAILTO="bibi+monserveur@gmail.com"

Note: comme vous pouvez le lire, j’utilise une adresse Gmail bibi@gmail.com pour la réception de mes notifications. J’y ajoute +monserveur (qui sera ignoré par Gmail) afin de pouvoir facilement les filtrer.

On relance le service pour prendre en compte la configuration:

sudo service cron-apt restart

Les notifications seront envoyés par défaut toutes les nuits à 4h du matin.

6) Surveiller le tout avec Logwatch

A ce stade vous avez un serveur disposant d’une sécurité de base qui va le protéger de la grande majorité des attaques que l’on peut trouver sur Internet. Il ne reste plus qu’à installer Logwatch, un outil permettant d’analyser les logs et ainsi de remonter par mail des rapports permettant d’analyser des tentatives d’intrusions éventuelles.

La mise en place est assez simple.

sudo apt-get install logwatch

Puis on configure l’adresse mail de destination des messages de notifications dans le fichier /etc/cron-apt/config:

#execute
/usr/sbin/logwatch --output mail --mailto bibi+monserveur@gmail.com --detail high

On relance le service pour prendre en compte la configuration:

sudo service cron-apt restart

Les notifications seront envoyés par défaut toutes les nuits.

7) Conclusion

Nous arrivons à la fin de ce billet avec une machine à l’épreuve d’une exposition à Internet sans risque de se faire hacker par le premier « script kiddie » venu.

A vous de nous faire partager vos techniques, méthodes que vous appliquez sur vos nouveaux serveurs !

Étiquettes debian, install, serveur