Catégories
Open-source Planet-libre Systeme

Terminator, le terminal ultime sous GNU/Linux

Une des grande différence entre un Linuxien et un Windowsien est le temps passé devant le terminal (console en mode graphique). Si les terminaux fournis par défaut sous GNU/Linux sont à des années lumières des pauvres consoles CMD ou PowerShell de Microsoft, ils sont encore loin derrière le logiciel dont je vais vous parler dans ce billet.

Terminator (logiciel libre sous licence GPL) propose les fonctions suivantes:

  • configuration de la fontes et des couleurs avec gestion de la transparence (association dans des profils)
  • division horizontale et verticale de la fenêtre pour disposer de plusieurs terminaux
  • chaque terminal peut disposer d’un profil différent
  • possibilité d’envoyer les lignes de commandes saisies au clavier sur un groupe de terminaux
  • capture d’écran du terminal en 2 clics de souris
  • scroll bar infinie
  • possibilité de lancer des commandes automatiquement au démarrage du terminal

Voici donc un aperçu de la bête:

Comme vous pouvez le voir, il est possible de mixer des divisions horizontales et verticales et d’associer un profil différent pour chaque terminal. Par exemple, j’ai trois profils différents:

  • default: le profil par défaut que j’utilise sur ma machine (fond bleu foncé, texte blanc)
  • tiny: un profil optimisé pour l’affichage des logs (fontes plus petite)
  • b&w: un profil monochrome

La configuration des profils est stockées dans le fichier ~/.config/terminator/config et peut donc facilement être importée entre vos différents ordinateurs.

Autre fonction très utile, le regroupement. Vous allez pourvoir diffuser, en parallèle, les commandes saisies au clavier sur un ensemble de terminaux.

Imaginons que vous deviez mettre à jour 3 serveurs. Vous commencez donc par diviser horizontalement l’écran en 3 terminaux à partir desquels vous allez vous connecter en SSH sur vos serveurs (1 serveur = 1 terminal). Vous allez ensuite regrouper les 3 terminaux en faisant un clic droit  > Regroupement > Diffuser tout. Il ne reste plus qu’à saisir une seule fois les commandes de mises à jour !

Pratique, rapide, libre, indispensable.

Catégories
Developpement Open-source Planet-libre Systeme

Préparer l’arrivée de Precise Pangolin avec un script de postinstall

Si vous suivez régulièrement ce blog, vous savez que je suis un informaticien fainéant, j’ai horreur de faire plusieurs fois la même chose. C’est une des raison pour laquelle je développe des scripts d’auto (ou post) installation que vous pouvez trouver sur mon espace GitHub.

Nous allons, dans ce billet, parler de la nouvelle version du script de post installation de la version Ubuntu Precise Pangolin (aka 12.04 LTS).

Heu, c’est quoi un script de post install ?

C’est un script que l’on lance à la fin d’une installation « standard » (« out of the box ») d’un système d’exploitation et qui va s’occuper de le configurer pour répondre au mieux à nos besoins.

On peut par exemple automatiser les tâches suivantes:

  • ajouter les dépôts de logiciels
  • installer les logiciels que vous jugez indispensables
  • supprimer les logiciels inutiles
  • télécharger et installer des thèmes pour votre interface graphique
  • configurer vos applications (BASH, prompt, Vim…)
  • faire toutes les actions en ligne de commande qui vous passe par la tête !

Historique du script UbuntuPostInstall

Les dernières versions de ce script (pour les distributions Ubuntu 11.04 et 11.10) étaient développées en Shell Script (BASH). Afin de simplifier le développement, j’ai donc décidé de re-développer complètement le script en Python en lui apportant une fonction de personnalisation par fichier de configuration.

C’est donc sur cette base que le script pour la version 12.04 d’Ubuntu est développé.

Comment fonctionne le script ?

Le script, disponible sous GitHub ou à partir de sa page officielle, est autonome et fonctionne directement à partir d’une installation standard d’Ubuntu 12.04 LTS. Pour le télécharger, il faut saisir les commandes suivantes:

wget https://raw.github.com/nicolargo/ubuntupostinstall/master/ubuntu-12.04-postinstall.py
chmod a+x ubuntu-12.04-postinstall.py

Pour fonctionner, le script utilise un fichier de configuration qui permet de spécifier les « choses à faire ». Par défaut, si aucun configuration n’est spécifiée dans la ligne de commande, il va télécharger le fichier suivant sur mon GitHub: post-installation pour Unity.

Donc pour lancer une post-installation standard sur une toute fraiche distribution Ubuntu 12.04 LTS, il faut lancer la commande:

sudo ./ubuntu-12.04-postinstall.py

Le script va faire les chose suivantes:

  • Ajouter des dépôts PPA utiles (voir la liste dans la section repos)
  • Ajouter des applications indispensables aux geeks (classées par thème: dev, multimedia, réseau, système…)
  • Ajout de thèmes pour GTK, des icônes…
  • Configuration de BASH (.bashrc, prompt, alias), Vim (.vimrc) et Htop (.htoprc)

Voici un aperçu du script en cous d’exécution:

Le script génère également un fichier de log dans le répertoire /tmp qui va détailler toutes les actions effectuées (et vous permettre d’identifier les éventuels problèmes).

D’autres fichiers de configuration sont disponibles sur mon GitHub et peuvent être spécifiés dans la ligne de commande. Par exemple, si vous préférez utiliser Gnome Shell en lieu et place d’Unity:

sudo ./ubuntu-12.04-postinstall.py -c https://raw.github.com/nicolargo/ubuntupostinstall/master/ubuntu-12.04-gnomeshell-postinstall.cfg

ou si vous êtes plutôt Cinnanon (le fork de Gnome 2):

sudo ./ubuntu-12.04-postinstall.py -c https://raw.github.com/nicolargo/ubuntupostinstall/master/ubuntu-12.04-cinnamon-postinstall.cfg

Comment éditer votre propre fichier de configuration ?

Bien que les fichiers fournis en standard répondent aux besoins de la plupart des geek qui lisent ce blog, il peut être intéressant de l’adapter plus finement à vos besoins.

Le plus simple est donc de « forker » la configuration par défaut qui s’approche le plus de votre environnement (Unity, Gnome Shell ou Cinnanon). Puis d’éditer le fichier de configuration et enfin de l’utiliser avec l’option -c du script (qui peut prendre en paramètre une URL ou un fichier local).

Par exemple, si vous êtes un fan de Gnome Shell, vous pouvez télécharger le fichier suivant puis l’éditer en suivant les consignes disponibles sur le site officiel.

Comme vous allez le voir, le fichier de configuration permet, en plus des actions détaillées au début de ce chapitre, de lancer des lignes de commandes en début (section preactions) ou fin de script (section postactions).

Conclusion

Si vous avez des remarques ou des demandes spécifiques sur ce nouveau scripts ou que vous vouliez partager vos fichiers de configurations personnels, les commentaires ci-dessous sont là pour ça !

Catégories
Blog Open-source Planet-libre Systeme Web

Shelr, un service de screencast pour votre terminal

Shelr propose un outil pour enregistrer, rejouer et diffuser les commandes et leurs résultats saisies dans votre terminal favori (console). L’avantage par rapport à un screencast classique est que le termcast sauvegarde non pas une vidéo mais juste le texte.

Il est possible de fonctionner de manière autonome en gérant vous même vos enregistrements (ce qui peut par exemple être très pratique pour une présentation ou un cours à des élèves). Si vous souhaitez diffusez ces enregistrements sur Internet, il faut passer par le site Shelr.tv: l’inscription prends quelques secondes et l’hébergement de vos termcasts est gratuite.

Cerise sur le gâteau, les outils Shelr sont fournis sont licence GPL v3 dans un GitHub.

Installation Shelr sur votre système

Voici la procédure à suivre sur une distribution Ubuntu. Les seuls pré-requis sont d’avoir ruby et rubugems installés sur son système d’exploitation:

sudo apt-get install ruby rubygems
sudo gem install shelr

Comment utiliser le logiciel Shelr

Le logiciel en question se présente sous la forme d’un executable unique: shelr qui propose dans sa version actuelle les options suivantes:

# shelr 

Usage: shelr command [arg]
Commands:
    setup API_KEY   - setup
    record          - record new shellcast
    push RECORD_ID  - publish
    list            - print list of records
    play RECORD_ID  - play local record
    play RECORD_URL - play remote record

Enregistrement de votre premier termcast

Il suffit de saisir la commande suivante:

shelr record

Shelr va alors vous demander le nom (description) à associer à votre enregistrement puis lancer un fork de votre shell courant ou vous pourrez taper en toute transparence vos commandes à enregistrer.

Pour terminer l’enregistrement, il faut appuyer sur la combinaison CTRL-D (ou saisir la commande exit).

Afficher la liste des termcast stockés sur votre système

L’option list permet d’afficher la liste des termcasts que vous avez enregistrez:

$ shelr list

1333815250: A Glances 1.3.7 demo
1333815271: A Glances 1.3.7 demo
1333815112: A first test

Le chiffre qui précède la description est l’identifiant unique de votre termcast.

Rejouer un termcast

On utilise shelr avec l’option play suivi du numero d’identifiant:

shelr play 1333815112

Le terminal devrait s’animer tout seul, comme par magie.

Petite remarque: seul l’affichage est rejoué, pas l’exécution des commandes !

Il est également possible de fournir en argument de la commande play, l’URL d’un termcast stocké sur le site Shelr.tv

Diffuser vos termcasts sur le site Shelr.tv

Pour partager vos termcast à partir dur site Shelr.tv, il faut d’abord créer un compte en vous rendant sur la page suivante. Si vous avez un compte GitHub, Twitter ou Facebook, il est alors facile de créer un compte en quelques secondes.

Après la création du compte, vous aller obtenir un code d’API:

Il faut alors saisir la commande « shelr setup CODEAPI » dans un terminal pour associer votre ordinateur à votre compte Shelr.tv.

Pour diffuser sur le site un termcast enregistré sur votre disque il faut saisir la commande (en remplaçant l’identifiant par celui obtenu par la commande shelr list):

shelr push 1333815112

Il est également possible de diffuser le dernier enregistrement en utilisant l’alias:

shelr push last

Vous pouvez voir de nombreux exemples de termcasts sur le site Shelt.tv.

Visualiser un termcast Shelr.tv depuis une console

Une fois diffusé, vous aller obtenir l’URL de votre termcast que l’on pourra rejouer dans sa console. Par exemple, pour voir une démonstration de la dernière version bêta de mon logiciel Glances:

shelr play http://shelr.tv/records/4f81498796608031bf000003.json

Notez le .json à la fin de l’URL…

Visualiser un termcast Shelr.tv depuis un navigateur

Il est également possible, pour ceux qui non pas encore Shelr installé sur leur système, de voir le termcast directement depuis un navigateur internet depuis la page suivante: http://shelr.tv/records/4f81498796608031bf000003

Conclusion

Voilà une « killer application » qui va sûrement envahir les blogs techniques dans les prochains mois !

PS: Le compte Shelr.tv du blog de Nicolargo est disponible ici.

Catégories
Developpement Open-source Planet-libre Systeme

En route vers Puppet, Chef, CfEngine…

  

Derrière ce titre un peu pompeux se cache une problématique que tout administrateur système s’est ou se posera un jour ou l’autre: Comment gérer l’installation, la mise à jour et la configuration de toutes les machines de son parc informatique ?

Ce billet a pour objectif de poser le problème de base et d’aborder quelques unes des solutions possibles. Il servira d’introduction à une série d’article sur ce vaste et intéressant sujet.

Introduction

Imaginons donc un responsable informatique disposant de trois administrateurs système: Michel, David et Jean-Pierre. Il leurs demande de travailler sur les solutions de déploiement des logiciels dans le système d’information de  l’entreprise. Quelques jours plus tard, il leur demande de présenter leurs solutions…

Première solution: « à la mimine »

La première solution pour répondre à la question posée est celle Michel, sysadmin de base (fort en technique mais moins en processus et en communication): lire la documentation du système (ou logiciel) à installer (ou mettre à jour), Googlelifier si la documentation est trop longue (ou seulement en Anglais), tester sur un environnement de développement (Jean-Pierre est quand même un garçon prudent) puis appliquer la dite procédure sur l’ensemble des machines.

On trouve également certains Michel (ceux qui ont passé la certification ISO) qui vont documenter leur installation dans un beau document (ou encore mieux un Wiki). Comme Michel travaille souvent seul, le document ne sera jamais partagé ou enrichie, il deviendra donc obsolète à la prochaine version du système (ou logiciel).

Cette première solution apporte quelques avantages: Michel peut maîtriser de manière unitaire toutes les installations et donc facilement identifier les problèmes, il a une connaissance précise et réelles des briques de ses machines.

D’un autre coté, Michel demande un certain temps pour déployer ou mettre à jour vos logiciels sur les 100 machines de votre parc et il deviendrait complètement débordé, voir incompétent,  si ce nombre passait à plusieurs centaines voir milliers de machines…

Deuxième solution: « script, script, script… »

Michel a un collègue, David, qui adopte une méthode similaire dans les premières étapes (lecture de la documentation, recherche sur Internet, test dans un environnement de développement). Mais qui, au lieu de faire lui même les opérations sur les machines, passe par un script Shell qui va automatiser ces taches. Si vous suivez ce blog, vous savez que j’utilise souvent cette méthode pour installer des composants sur mes machines persos (et quelques fois professionnelles).

David bichonne ses beaux scripts dans un repos Git. Ses procédures sont rodées: connexion en SSH, récupération du script et le exécution.

Tout semble parfait mais les développements de ces scripts peuvent vite devenir une vrai galère quand on s’attaque à un parc multi-distribution (ceux qui ont essayé de développer un script d’installation multi-plateforme/distribution doivent me comprendre…).

Troisième solution: « gestionnaire de configuration des machines »

Bienvenu dans le monde de Jean-Pierre. Lui, il utilise un gestionnaire de configuration des machines. Ces systèmes apportent une couche d’abstraction entre ceux que l’on veut faire (les besoins) et comment ces besoins sont concrètement résolus sur les machines cibles.Un pseudo langage de programmation permet de définir les actions à effectuer et le moteur de configuration des machines va s’occuper du déploiement, de l’exécution et de la génération d’un rapport sur chacune des machines cibles.

Plusieurs solutions existent, des propriétaires (comme IBM Tivoli, BSM ou HP Operations Manager i) et des libres (Puppet, Chef, CfEngine). C’est bien sûr sur ces dernières que Jean-Pierre, grand partisan des solutions libres, a donc porté son choix.

Il ne reste plus qu’à commencer à jouer avec le bébé en travaillant sur un environnement de développement/Cloud (teasing pour les prochains billets :)).

Conclusion

Je ne connais pas assez ces solutions pour avoir un avis tranché sur la meilleure solution libre. Après quelques recherches sur le net et la consultation des 3 sites internet officiels, je trouve que le projet Puppet est très bien structuré et documenté. Je pense donc partir sur cette solution pour mes prochains billet sur le sujet.

La discussion est cependant ouverte (et les commentaires sont fait pour cela).

Je suis preneur de retours d’expériences sur ces 3 solutions libres !

Sources ayant inspiré ce billet:

 

Catégories
Open-source Planet-libre Reseau Systeme

Un PPA pour Glances

Grâce à Arnaud Hartmann (un grand merci à lui), un PPA est maintenant disponible pour installer la dernière version stable de Glances sur votre système Ubuntu (ou dérivé).

Le PPA en question couvre les versions d’Ubuntu depuis la 9.10 (Karmic) jusqu’à la future 12.04 (Precise Pangolin).

Pour installer Glances sur votre système via ce PPA, il suffit d’effectuer les actions suivantes:

[cc lang= »bash »]

sudo add-apt-repository ppa:arnaud-hartmann/glances-stable

sudo apt-get update

sudo apt-get install glances

[/cc]

A la date de la rédaction de ce billet, la dernière version stable disponible est la 1.3.7. Pour les plus téméraires, il est possible, en parallèle de cette installation, de tester la version expérimentale (1.4b) en utilisant le PPA suivant en lieu et place du stable: ppa:arnaud-hartmann/glances-unstable

Petit bonus pour les lecteurs qui sont arrivés jusqu’ici, la lecture d’un billet (en anglais) de présentation de Glances que je trouve assez bien fait.

Catégories
Open-source Planet-libre Systeme

Ubuntu 12.04 – Participez à la conception du script de post-install

Dans quelques semaines, la version 12.04 (alias Precise Pangolin) de la distribution Ubuntu va sortir. C’est une version LTS (« Long Time Support ») qui sera intéressante pour une utilisation aussi bien personnelle que professionnelle. L’orientation grand-public de Canonical (l’éditeur d’Ubuntu) est, je le pense, un bien pour la promotion et la diffusion des systèmes GNU/Linux.

D’un autre coté, pour nous, les geeks/hackers, il est nécessaire d’effectuer pas mal d’actions après l’installation du système (« post-installation ») pour disposer d’un environnement adapté à nos besoins. Depuis la version Ubuntu 11.04, je mets à disposition sur un GitHub un script de post-installation qui va permettre d’automatiser ces actions de post-installation.

Je vous propose donc de travailler ensemble sur la conception de la prochaine version du script qui sera dédié à Ubuntu 12.04.

Structure générale du script

La prochaine version du script sera développé en langage Python (BASH pour les ancienne verison) en se basant sur un squelette commun que j’utilise pour d’autres scripts.

Ce dernier effectuera les actions suivantes:

  • ajout de certains dépôts officiels et non-officiels
  • installation d’une liste de paquets (logiciels, librairies…) non présents dans la distribution standard
  • mise à jour du système
  • configuration de l’interface graphique (Gnome Shell actuellement mais il est possible aussi d’ajouter des customs pour Unity), Conky…
  • configuration VIM (.vimrc)
  • configuration SHELL (alias, prompt…)

Liste des dépôts à ajouter

Voici la listes des dépôts que le script ajoute à votre système:

  • ppa:gstreamer-developers (le PPA officiel des développeurs de GStreamer)
  • ppa:shutter (pour avoir la dernière version de Shutter, l’outil de capture d’écran)
  • ppa:chromium-daily/dev (le daily build de Chromium, le navigateur Web libre basée sur WebKit)
  • ppa:ubuntu-wine (Wine, pour exécuter certains programme Windows sous Ubuntu)
  • ppa:tualatrix/ppa (pour une version toute fraiche d’Ubuntu Tweak)
  • ppa:gnome-terminator/ppa (le terminal ultime…)
  • ppa:nilarimogard/webupd8 (le site WebUpd8 maintient ce PPA avec pas mal de logiciels)
  • ppa:webupd8team/jupiter (si vous avez un portable, ce PPA est fortement conseillé pour augmenter l’autonomie)
  • ppa:clipgrab-team/ppa (convertisseur vidéo ClipGrab)
  • ppa:stebbins/handbrake-releases (Handbrake)
  • http://repository.spotify.com (Spotify)
  • http://archive.getdeb.net/ubuntu (GetDeb, le projet maintien à jour une liste importante de logiciels libres)

Pour Gnome 3 (Gnome Shell):

  • ppa:gnome3-team/gnome3 (le PPA officiel des développeurs de Gnome 3)
  • ppa:webupd8team/gnome3 (pas mal d’extensions en plus)
  • ppa:webupd8team/themes (des thèmes pour Gnome Shell)

Listes des paquets à installer

Les logiciels suivants sont installés.

Développement:

[cc]

build-essential

vim

subversion

git git-core

rabbitvcs-nautilus

textadept

geany

wine

ubuntu-tweak

terminator

pyjupiter

nautilus-dropbox xclip zenity dropbox-share

[/cc]

Multimédia:

[cc]

vlc

x264

ffmpeg2theora

oggvideotools

istanbul

shotwell

mplayer

hugin

nautilus-image-converter

pavucontrol

gimp

gimp-save-for-web

ogmrip

transmageddon

guvcview

wavpack

mppenc

faac

flac

vorbis-tools

faad

lame

nautilus-script-audio-convert

cheese

sound-juicer

picard

arista

nautilus-arista

milkytracker

mypaint

libdvdread4

clipgrab

handbrake-gtk handbrake-cli

spotify-client-qt

shutter

[/cc]

Réseau:

[cc]

iperf

ifstat

wireshark

tshark

arp-scan

htop

netspeed

nmap

netpipe-tcp

[/cc]

Système: 

[cc]

preload

gparted

lm-sensors

compizconfig-settings-manager

hardinfo

fortune-mod

libnotify-bin

compiz-fusion-plugins-extra

ubuntu-restricted-extras

[/cc]

Web:

[cc]

chromium-browser chromium-browser-l10n chromium-codecs-ffmpeg-extra chromium-codecs-ffmpeg-nonfree

pidgin

pidgin-facebookchat

pidgin-plugin-pack

flashplugin-downloader

xchat

googleearth-package lsb-core ttf-mscorefonts-installer

[/cc]

Gnome 3:

[cc]

gnome-shell gnome-tweak-tool gnome-documents

conky-all ttf-ubuntu-font-family

[/cc]

Comment participer à la conception ?

Tout simplement en laissant un commentaire en bas de ce billet. Les actions à mener sont:

  • ajouter des dépôt manquants (attention, il ne faut proposer que des dépôts stables et pérennes)
  • ajout d’applications/librairies obligatoires (au sens geek du terme :))
  • autres actions à mener en post-install (merci de détailler)

Update:

Le script est disponible en version alpha (bien sur il ne faut pas le lancer sur votre machine mais seulement dans des VMs !):

Il est donc possible de le forker et de participer plus pratiquement à son évolution (par exemple en suivant ce billet).

J’attends vos idées !

Catégories
Open-source Planet-libre Reseau Systeme Web

Protéger son serveur en utilisant Fail2Ban

Comme toutes les machines exposées au réseau Internet, mon serveur Web est continuellement la cible de tentatives d’attaques basiques de type brute force et DOS. J’avais déjà abordé le sujet sous la forme de billets tel que « Sécuriser son blog WordPress » ou « Détection des attaques DOS/DDOS avec Nagios« . Nous allons aujourd’hui parler d’une solution de protection active se déclenchant automatiquement lors d’une de ces attaques: Fail2Ban.

Comment marche Fail2Ban ?

Développé en langage Python, Fail2Ban est un logiciel libre permettant d’analyser des fichiers de logs et de déclencher des actions si certaines choses suspectes sont détectées. La grande force de Fail2Ban est sa grande modularité que cela soit au niveau des mécanismes de détections basées sur les expressions régulières ou sur les actions à mener qui peuvent aller de l’expédition d’un mail à la mise en place de règles de Firewall.

Fail2Ban se base sur un système de prisons (jails) que l’on peut définir, activer ou désactiver dans un simple fichier de configuration (/etc/fail2ban/jail.conf).

Une prison (jail) est composée, entre autres, des éléments suivants:

  • Nom du fichier de log à analyser.
  • Filtre à appliquer sur ce fichier de log (la liste des filtres disponibles se trouve dans le répertoire /etc/fail2ban/filter.d). Il est bien sûr possible de créer ses propres filtres.
  • Paramètres permettant de définir si une action doit être déclenchée quand le filtre correspond (« match »): Nombre de « matchs » (maxretry), intervalle de temps correspondant (findtime)…
  • Action à mener si nécessaire. La liste des actions se trouve dans le répertoire /etc/fail2ban/action.d. Il est également possible de créer ses propres actions.

Installation de Fail2Ban

On commence par installer Fail2Ban sur son système. Il se trouve dans la grande majorité des distributions GNU/Linux et BSD. par exemple pour l’installer sur une machine Debian 6, il suffit de saisir la commande suivante (en root ou bien précédée d’un sudo):

apt-get install fail2ban

Protection contre les attaques « brute force » SSH

Un exemple étant toujours plus parlant, nous allons configurer notre Fail2Ban pour bloquer automatiquement les adresses IP des machines essayant des attaques de type « brute force » sur notre port SSH (cette attaque est à la portée de n’importe quel « neuneu ». On trouve de très bon tutoriaux sur le sujet sur le net).

Si une machine cliente échoue 3 fois de suite lors de la saisie du couple login/password sur le serveur SSH alors on bloque l’accès au port TCP/SSH pendant 15 minutes. On analyse pour cela le fichier de log /var/log/auth.log en lui appliquant le filtre /etc/fail2ban/filter.d/sshd.conf puis, si nécessaire, l’action /etc/fail2ban/action.d/iptables.conf. La définition de cette prison (jail) est à faire dans le fichier /etc/fail2ban/jail.conf:

# SSH
# 3 retry ? > Ban for 15 minutes

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

Un fois le filtre activé en relançant Fail2Ban avec la commande (en root):

service fail2ban restart

On peut rapidement voir son efficacité en regardant le fichier de log (par défaut sous /var/log/fail2ban.log):

Protection contre les attaques DOS (HTTP/GET)

Dans ce deuxième exemple nous allons voir comment lutter efficacement contre les attaques de type DOS ciblant vos serveurs Web. Ces attaques se caractérisent par un nombre inhabituel de requêtes HTTP venant d’un même client (du moins d’une même adresse IP source).

Le plus difficile est de trouver les bons paramètres correspondants à un comportement « inhabituel ». Dans l’exemple suivant, je considère comme « inhabituel » le fait qu’un client effectue plus de 360 requêtes en 2 minutes (soit une moyenne de supérieurement à 3 req/sec) sur mon serveur Web. Dans ce cas, je bloque l’accès au port HTTP pendant une durée de 10 minutes.

La prison (jail) correspondante est la suivante (à ajouter dans votre fichier /etc/fail2ban/jail.conf):

# Protect against DOS attack
# 360 requests in 2 min > Ban for 10 minutes

[http-get-dos]
enabled = true
port = http,https
filter = http-get-dos
logpath = /var/log/varnish/varnishncsa.log
maxretry = 360
findtime = 120
action = iptables[name=HTTP, port=http, protocol=tcp]
mail-whois-lines[name=%(__name__)s, dest=%(destemail)s, logpath=%(logpath)s]
bantime = 600

En regardant de plus près cette prison, on remarque qu’elle utilise en entrée le fichier de log au format NCSA généré par le système de cache Varnish que j’utilise en frontal sur mes serveurs Web (/var/log/varnish/varnishncsa.log). Il est bien sûr possible d’utiliser directement le log de votre serveur Apache ou Nginx. Le filtre http-get-dos n’est pas fourni par défaut. Il faut donc éditer le fichier /etc/fail2ban/filter.d/http-get-dos.conf avec le contenu suivant:

# Fail2Ban configuration file

#

# Author: http://www.go2linux.org

#

[Definition]

# Option: failregex

# Note: This regex will match any GET entry in your logs, so basically all valid and not valid entries are a match.

# You should set up in the jail.conf file, the maxretry and findtime carefully in order to avoid false positives.

failregex = ^<HOST>.*\"GET

# Option: ignoreregex

# Notes.: regex to ignore. If this regex matches, the line is ignored.

# Values: TEXT

#

ignoreregex =

Enfin, en cas de « match », on applique deux actions:

  1. blocage du port HTTP avec l’action iptables définie dans /etc/fail2ban/action.d/iptables.conf
  2. envoie d’un mail signalant le blocage avec l’action mail-whois-lines. L’adresse du mail est défini dans la variable destemail à modifier dans le fichier jail.conf.

Un fois le filtre activé:

service fail2ban restart

On peut regarder le fichier de log (/var/log/fail2ban.log)…:

$ tail -f /var/log/fail2ban.log

2012-02-22 11:36:59,134 fail2ban.actions: WARNING [http-get-dos] Ban 107.---.---.---

… et/ou attendre la réception des mails:

Conclusion

Ce billet est une simple introduction à l’utilisation de Fail2Ban qui peut être configuré de manière beaucoup plus personnalisé et en fonction de vous besoins. Si vous avez d’autres exemples d’utilisation, les commentaires ci-dessous sont fait pour cela !

Catégories
Open-source Planet-libre Systeme

Configurer votre prompt BASH

S’il y a bien une chose que nous, geeks du monde libre, regardons en longueur de journée, c’est bien notre cher prompt (vous savez: $, # …). C’est en lisant ce billet que je me suis dit que mon prompt actuel avait besoin d’un ravalement de façade:

Je souhaite mettre un peu de couleur dans mon nouveau prompt ainsi que des informations sur le dossier en cours. Quand ce dernier est un dossier de développement sous Git, je veux afficher la branche en cours d’utilisation et aussi savoir si mon répertoire est dans l’état « staging » (c’est à dire si je dois faire un commit).

Sans plus attendre, voici un aperçu de mon nouveau prompt (version 2 lignes):

Ce dernier se décompose en deux lignes:

  • user@host:folder (je garde cette structure pour simplifier les copier/coller en SSH, puis l’état Git (avec [le nom de la branche] en couleur rouge si staging, vert sinon)
  • le prompt proprement dit (là ou l’on va taper la commande :)) précédé de $ si on est un utilisateur standard et # si root

Pour la première ligne, j’utilise la variable BASH nommé PROMPT_COMMAND qui a le gros avantage d’être exécuté à chaque fois que le prompt est affiché (pas seulement à l’initialisation). La seconde ligne utilise la variable PS1.

Pour disposer de ce prompt, il est nécessaire d’insérer le code suivant à la fin de votre fichier .bashrc (il est aussi disponible sous GitHUB):

[cc lang= »bash »]

# Colors

NoColor= »\033[0m »

Cyan= »\033[0;36m »

Green= »\033[0;32m »

Red= »\033[0;31m »

Yellow= »\033[0;33m »

# Chars

RootPrompt= »# »

NonRootPrompt= »$ »

# Contextual prompt

prompt() {

USERNAME=`whoami`

HOSTNAME=`hostname`

CURRENTPATH=`pwd`

LEFTPROMPT=$Cyan$USERNAME@$HOSTNAME »: »$Yellow$CURRENTPATH

let LEFTSIZE=$(echo -n « $USERNAME@$HOSTNAME:$CURRENTPATH » | wc -c)

RIGHTPROMPT= » »

let RIGHTSIZE=0

GITSTATUS=$(git status 2> /dev/null)

#echo $GITSTATUS > /dev/null 2>&1

if [ $? -eq 0 ]; then

echo $GITSTATUS | grep « not staged » > /dev/null 2>&1

if [ $? -eq 0 ]; then

RIGHTPROMPT=$Red

else

RIGHTPROMPT=$Green

fi

BRANCH=`git describe –contains –all HEAD`

RIGHTPROMPT=$RIGHTPROMPT »[Git branch « $BRANCH »] »

let RIGHTSIZE=$(echo -n « [Git branch « $BRANCH »] » | wc -c)

fi

let BLANCKSIZE=${COLUMNS}-${LEFTSIZE}-${RIGHTSIZE}

RIGHTPROMPT=$RIGHTPROMPT$NoColor

echo -e -n $LEFTPROMPT

printf « %$(($BLANCKSIZE))s »

echo -e $RIGHTPROMPT

}

# Main prompt

PROMPT_COMMAND=prompt

if [ $EUID -ne 0 ]; then

PS1=$NonRootPrompt »  »

else

PS1=$RootPrompt »  »

fi

[/cc]

Update (20/02/2012): Je viens également d’ajouter une version allégée (en une seule ligne) de ce prompt. Le fichier de configuration BASH correspondant se trouve ici.

Update (21/02/2012): David Olivier vient de modifier  le script (version deux lignes) pour fonctionner avec SVN. A retrouver sur le GitHub.

Et vous, comment est votre prompt ?

 

Catégories
Open-source Planet-libre Systeme

Mon desktop 201202

Cela fait un moment que je n’ai pas tagué un billet avec le tag desktop. La raison est assez simple, mon environnement de travail que ce soit sur mes PC Debian, Ubuntu ou Mint évolue peu depuis ma migration vers Gnome Shell. Après les tâtonnements du début, j’ai pris mes marques et je dois avouer que je ne ferais plus marche arrière.

C’est donc la lecture de ce billet qui a provoqué les dernières modifications de détail que je vous montre sur mon PC portable sous Linux Mint 12:

Description de l’environnement:

Pour installer les thèmes / icônes, il faut suivre la procédure suivante:

cd `mktemp -d`
wget http://www.deviantart.com/download/189180645/boomerang_by_ghogaru-d34mspx.zip
unzip boomerang_by_ghogaru-d34mspx.zip
cd Boomerang_GTK_by_ghogaru
tar zxvf Boomerang.tar.gz
tar zxvf Boomerang\ Deux.tar.gz
sudo mv Boomerang Boomerang\ Deux /usr/share/themes/
cd ..
wget http://www.deviantart.com/download/255099649/faience_icon_theme_by_tiheum-d47vo5d.zip
unzip faience_icon_theme_by_tiheum-d47vo5d.zip
tar zxvf Faience.tar.gz
tar zxvf Faience-Azur.tar.gz
tar zxvf Faience-Claire.tar.gz
tar zxvf Faience-Ocre.tar.gz
sudo mv Faience Faience-Azur Faience-Claire Faience-Ocre /usr/share/icons
wget http://www.deviantart.com/download/255097456/gnome_shell___faience_by_tiheum-d47vmgg.zip
unzip gnome_shell___faience_by_tiheum-d47vmgg.zip
mv Faience ~/.themes/

Et vous il donne quoi votre desktop du moment ?

A vous de nous montrer vos écrans
(par exemple en utilisant yFrog puis en partagant l’URL) !

Catégories
Open-source Planet-libre Systeme

Apprentissage de Qemu/LibVirt par l’exemple

La rédaction des billets de ce blog nécessite de travailler sur plusieurs systèmes d’exploitations différents. Plutôt que de monter une salle machine dans ma maison (pas sur que ma compagne soit d’accord), j’ai donc opté pour un virtualisation sur un serveur dédié OVH qui a le gros avantage de disposer d’une RAM conséquente de 16 Go (pour une machine en l’an 2012). Travaillant la plupart du temps du temps sous Linux, mon choix c’est donc porté sur la solution Qemu/KVM (Kernel-based Virtual Machine).

Installation de Qemu/KVM

Pour que Qemu/KVM ait des performances acceptables, il faut vérifier que votre processeur soit compatible avec les extensions de virtualisation. Sous Linux, il est facile de vérifier cela avec la ligne de commande suivante.

[cce lang= »bash »]

egrep ‘^flags.*(vmx|svm)’ /proc/cpuinfo >/dev/null && echo OK || echo KO

[/cce]

Sur mon serveur de test (Kimsufi 16G chez OVH) pas de problème de ce coté là. J’obtiens un beau OK.

Le serveur peut donc supporter la virtualisation hardware. Chez OVH, le noyau par défaut est statique, il n’est donc pas possible d’ajouter dynamiquement des modules (comme le kvm_intel par exemple). Il faut donc suivre cette procédure. La dernière version des noyaux semble intégrer par défaut les modules KVM.

On peut ensuite passer à l’installation des briques logicielles (environ 257 Mo à télécharger):

  • qemu-kvm – Full virtualization on x86 hardware
  • virtinst – Programs to create and clone virtual machines
  • libvirt-bin – the programs for the libvirt library

On utilise les versions disponibles dans les dépôts Debian:

[cc lang= »bash »]

sudo apt-get install qemu-kvm virtinst libvirt-bin

[/cc]

Un petit reboot de la machine pour être sûr que tous les modules sont chargés avant de poursuivre.

Création de sa première machine virtuelle (VM)

Nous allons commencer par créer une machine virtuelle avec comme système hôte une Ubuntu Desktop 11.10. Une machine virtuelle a besoin d’un conteneur dans lequel elle va pourvoir s’exécuter: ce conteneur s’appelle une image disque. Ensuite, il faudra installer le système hôte à l’intérieur de cette image disque.

Il est possible d’utiliser la ligne de commande pour effectuer ces opérations (ce qui ouvre la voie à une automatisation par scripts). Nous aborderons cela un peu plus loin dans l’article. Pour commencer, nous allons utiliser le module libvirt-manager qui propose une interface graphique (GTK) permettant d’administrer à distance (via un tunnel SSH) son serveur d’hypervision Qemu/KVM.

On commence par vérifier que le daemon d’administration est bien lancé sur le serveur d’hypervision (ce qui devrait être le cas si vous avez suivi les étapes d’installations de ce billet):

[cc lang= »bash »]

sudo /etc/init.d/libvirt-bin status

Checking status of libvirt management daemon: libvirtd running.

[/cc]

Ensuite il faut ajouter votre utilisateur (nicolargo dans mon cas) dans les groupes ‘libvirt‘ et ‘kvm‘:

[cc lang= »bash »]

sudo usermod -a -G libvirt nicolargo

sudo usermod -a -G kvm nicolargo

[/cc]

Sur la machine GNU/Linux cliente (disposant d’une interface graphique), il faut installer les packages (par exemple sous Debian/Ubuntu):

[cc lang= »bash »]

sudo apt-get install virt-manager

[/cc]

Au lancement du client, il faut cliquer sur le menu File > Add connection…

Puis paramétrer la connexion vers votre serveur:

Notre serveur est alors disponible dans la liste, on peut alors configurer ses propriétés:

On configure le type de réseau que l’on va utiliser. Comme je ne dispose que d’une seule adresse publique sur mon serveur OVH Kimsufi, j’utilise la translation d’adresse (voir l’explication dans un chapitre suivant) qui est configurée par défaut:

Puis on configure les répertoires ou l’on pourra trouver les ISOs pour l’installation des machines hôtes:

 

 

Et voila le résultat après téléchargement de quelques images ISO depuis le répertoire ~/iso (le serveur disposant d’une accès 100 Mbs direct sur Internet, cela va assez vite !).

On peut passer à la création de la VM proprement dite en cliquant sur le bouton « Create a new virtual machine ». On accède alors à un wizard:

On entre le nom de la VM (sans espace):

Puis l’image ISO qui va nous servir pour l’installation du système d’exploitation (le « Browse » sur le serveur peut prendre un certain temps):

On défini ensuite les ressources de la VM (CPU et mémoire). A noter que la limite à 2 Go de RAM sur ma configuration de test:

On donne ensuite la taille de l’image disque qui contiendra notre VM. Je conseille 16 Go pour les OS récents.

Enfin on finalise la configuration coté réseau (NAT) et hyperviseur (KVM):

Une fenêtre avec un déport d’affichage devrait alors s’afficher et l’installation du système guest (Ubuntu 11.10) commencer:

 Il ne vous reste plus qu’à finaliser l’installation !

Utilisation de sa VM

Une fois l’installation de la VM effectuée (voir le chapitre précédant). Celle-ci devrait apparaître dans la liste proposé par Virtual Machine Manager. Pour la lancer, il faut sélectionner la VM puis cliquer sur le bouton ‘play’ (Power On the virtual machine):

Et voilà le travail:

Niveau performance ?

Il ne faut pas s’attendre à des miracles. La virtualisation par Qem/KVM bien qu’aillant fait de gros progrès dans les dernières versions restent en dessous d’une solution comme VmWare ou Xen. Elles sont par contre suffisante dans mon cas ou je souhaite valider des procédures et des logiciels système et réseau.

Gestion en ligne de commande

Création de l’image disque

On commence par créer un répertoire ~/vm qui va contenir toutes mes images disques:

[cc lang= »bash »]

mkdir ~/vm

[/cc]

Puis on utilise la commande qemu-img pour générer l’image disque « vierge »:

[cc lang= »bash »]

cd ~/vm

qemu-img create -f qcow2 debian6server.qcow2 16G

[/cc]

Cette dernière commande va donc générer une image disque nommée debian6server.qcow2 de type qcow2 (voir ci-dessous la liste des types disponibles sous Debian 6) avec une taille maximale de 16 Giga octets.

Sur mon système, la liste des « types » d’image disque est la suivante:

  • raw: pas de compression, l’image disque est directement « dumpée » dans un fichier
  • host_device
  • qcow2: format par défaut de Qemu (Qemu Image Format)
  • qcow: ancien format utilisé par Qemu (ne pas utiliser pour la création de nouvelle image disque)
  • vdi: format compatible avec VirtualBox
  • vmdk: format compatible avec VMWare
  • vpc: format compatible avec VirtualPC

Il est possible de convertir une image d’un format à un autre. Par exemple, si vous avez une image au format VMWare et que vous voulez la convertir vers un format Qcow2, il suffit de saisir la commande suivante:

[cc lang= »bash »]

qemu-img convert -f vmdk disk.vmdk -O qcow2 disk.qcow2

[/cc]

Création de la VM

Pour installer la VM, nous avons besoin de l’image ISO du système d’exploitation à installer (Debian 6 server dans mon exemple). On va donc télécharger cette image sur notre serveur (c’est dans ces moments là que l’on est heureux d’avoir un serveur avec une connexion à 100Mbps vers Internet…):

[cc lang= »bash »]

mkdir ~/iso

cd ~/iso

wget http://cdimage.debian.org/debian-cd/6.0.3/i386/iso-cd/debian-6.0.3-i386-CD-1.iso

[/cc]

Maintenant que nous disposons de l’image disque ~/vm/debian6server.qcow2 et du média d’installation ~/iso/debian-6.0.3-i386-CD-1.iso, nous allons créer la machine virtuelle en utilisant la couche d’abstraction libvirt.

Pourquoi utiliser libvirt plutôt que d’utiliser directement les commandes équivalentes Qemu ? Si demain vous décidez de changer votre système de virtualisation, vos procédures/scripts resteront les mêmes. En effet libvirt communique de manière transparente vers un grand nombre de systèmes de virtualisation en proposant en bonus une API de développement (notamment en Python).

On utilise donc la commande suivante pour créer la VM:

[cc lang= »bash »]

virt-install –ram=2047 –name=debian6server –file=/home/nicolargo/vm/debian6server.qcow2 –cdrom=/home/nicolargo/iso/debian-6.0.3-i386-CD-1.iso –hvm –vnc –noautoconsole

[/cc]

Note: la commande virt_install ne semble pas trop aimer les ~ dans les paths. Il faut donc donner le chemin absolu.

Note2: La taille maximale de RAM que je peux allouer est de 2047Mo.

Cette commande va donc créer une VM nommée debian6server qui disposera de 2 Go de RAM (d’ou l’avantage de faire tourner votre hyperviseur sur une machine disposant de pas mal de RAM / 16 Go dans mon cas sur une Kimsufi 16G).

Si tout est ok, le message suivant devrait s’afficher:

Domain installation still in progress.

You can reconnect to the console to complete the installation process.

Pour l’accès à la console (déport VNC via un tunnel SSH), je vous conseille d’utiliser l’interface d’administration de libvirt que vous pouvez lancer sur un PC client disposant d’une interface graphique.

Gestion du réseau par translation

Mon serveur dispose d’une seule adresse IP publique. Les VM auront donc des adresses IP privées et l’on utilisera la translation s’adresse (NAT) pour permettre au VM de sortir sur Internet (voir ce billet pour la création d’un réseau par NAT).

Certaines configurations sont à faire sur votre serveur:

[cc]

sudo sh -c « echo 1 > /proc/sys/net/ipv4/ip_forward »

[/cc]

[cc]

sudo vi /etc/sysctl.conf

# Uncomment the next line to enable packet forwarding for IPv4

net.ipv4.ip_forward=1

[/cc]

Si vous utilisez des règles Iptables alors il faut ajouter les lignes suivantes dans votre scripts (attention de bien vérifier que votre script ne repositionne pas la valeur net.ipv4.ip_forward à 0… je me suis fais avoir):

[cc]

# Qemu rules (NAT VM and allow VM to DHCP)

/sbin/iptables -t nat -A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -j MASQUERADE

/sbin/iptables -A INPUT -i virbr0 -j ACCEPT

/sbin/iptables -A OUTPUT -o virbr0 -j ACCEPT

/sbin/iptables -A INPUT -i virbr0 -p udp -m udp –dport 53 -j ACCEPT

/sbin/iptables -A INPUT -i virbr0 -p tcp -m tcp –dport 53 -j ACCEPT

/sbin/iptables -A INPUT -i virbr0 -p udp –dport 67:68 –sport 67:68 -j ACCEPT

/sbin/iptables -A FORWARD -d 192.168.122.0/24 -o virbr0 -m state –state RELATED,ESTABLISHED -j ACCEPT

/sbin/iptables -A FORWARD -s 192.168.122.0/24 -i virbr0 -j ACCEPT

/sbin/iptables -A FORWARD -i virbr0 -o virbr0 -j ACCEPT

echo 1 > /proc/sys/net/ipv4/ip_forward

[/cc]

Petite note pour les guests « BSD »

Pour un guest sous OpenBSD, il faut penser à effectuer les actions suivantes pour faire fonctionner correctement la carte réseau:

  • arrêter la VM
  • éditer le fichier /etc/libvirt/qemu/OpenBSD_5.0.xml

[cce]

<interface type=’network’>

<model type=’e1000′>

</interface>

[/cce]

  • Relancer la VM

Sources utilisées lors de la rédaction de cet article: