Chimrod

Bonjour à tous, pour mon premier article sur le planet-libre, je voudrais faire part d’une réflexion qui m’interpelle depuis un moment concernant l’univers Linux : le fait que les utilisateurs non administrateurs soient exclus de toute la documentation/prise en main que l’on peut trouver sur le système. Je ne donne ici que quelques aspects de cette réflexion mais je pense qu’elle touche l’ensemble des participants au monde du libre.

La plupart des articles que l’on peut voir sur le net qui concernent l’utilisation du PC sous Linux restent limités à un point : souvent ils oublient le fait que plusieurs utilisateurs puissent être enregistrés sur le PC, et que tous ne soient pas forcément des administrateurs ( ceux qui peuvent avoir des droits root sur la machine ).
Pourquoi donc ? Est-ce que cela signifie que la plupart des linuxiens sont les seuls à utiliser le PC ? C’est possible, mais là n’est pas mon sujet. Je pense que le problème est que les utilisateurs sont pour l’instant invisible de la littérature sur Linux que l’on peut trouver sur le net. À la fois invisible du côté des distributions, et invisible du côté des communautés.

Le problème se retrouve présent dans deux aspects : d’une part dans la documentation s’adressant aux administrateurs, et d’autre part dans la documentaiton s’adressant aux utilisateurs.

Si l’on suit les manipulations que l’on peut trouver un peu partout sur le net, on trouve souvent des modifications qui ont pour conséquences de modifier la configuration générale du système, et l’on trouve plus souvent des modifications dans /etc/ que dans ~/.config/

Suivre les besoins des utilisateurs

Tous les utilisateurs n’utilisent pas forcément l’ordinateur de la même manière et il faut prévoir quels sont leurs besoin avant de se lancer dans une opération générale.
Par exemple, il n’y a pas longtemps était paru sur le planet-libre un article sur privoxy qui se terminait par une manière élégante d’utiliser privoxy sans configuration supplémentaire[1]. Or privoxy est lent pour traiter les sites puisant des ressources un peu partout — par exemple google news ou planet-libre (!) et se transformer en inconfort pour l’utilisateur.

Les mises à jour

Faire une mise à jour est toujours quelque chose de périlleux, et l’on ne sait pas forcément comment le système va réagir; entre le logiciel qui ne fonctionne plus car sa configuration a changé ou celui qui ne fonctionne plus car un bug a été introduit dans la nouvelle version, les risques sont possibles ( je n’ai par exemple pu plus lire de dvd lors de la mise à jour du noyau 2.6.30[2]… )
Je ne veux pas relancer le débat sur le packaging des distributions ( rolling release contre version fixes) mais le problème doit être posé : comment être sûr en faisant une mise à jour que l’on ne va pas casser tel composant ?

En plus des modifications générales sur la configuration que peuvent introduire les modifications, on peut se retrouver dans la situation inverse : l’utilisateur n’a pas le droit de visualiser les fichiers de logs, d’installer un paquet ou de modifier un fichier de configuration et ne pourra donc pas suivre la documentation qu’il peut trouver ici et là sur le net.

Pouvoir utiliser ses propres applications ?

Les distributions n’ont pour l’instant pas de solutions pour gérer l’installation de paquets par un utilisateur normal ( qui irait s’installer dans /opt// par exemple ), pouvant être installés sans droit root, et ne pouvant être exécutés que par l’utilisateur ayant fait son installation.

Utiliser des commandes non root

En fait, ce système que l’on nous décrit ouvert ne l’est réellement que si l’on est admin dessus. Pour les autres, la manipulation se limite à bash, python…
Dans la documentation, on trouve même des exemples demandant à l’utilisateur d’être root alors qu’une commande équivalente peut être lancée par un utilisateur normal ( par exemple $netstat -ie au lieu de #ifconfig )

Ce problème de l’utilisateur non root est pour l’instant contourné ( par exemple en configurant sudo dès l’installation ), mais il reste posé, et n’est jamais attaqué de front.

Le fait que cette situation ne soit jamais évoquée est pour moi significative de l’utilisation faite de linux aujourd’hui : bien loin du grand public. Nous sommes tous ici des utilisateurs bidouilleurs, et ne voyons pas forcément une utilisation quotidienne d’un utilisateur standard. Je ne veux pas en faire une généralisation sur l’avenir de Linux et une remise en cause nécessaire. Je pose juste ici un constat sur une situation qui est pour moi, encore trop souvent invisible.

[2] Artisan Numérique » Se prémunir des “SpyWebs” avec Privoxy
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=557340

On le sait tous, il faut faire des sauvegardes de manière régulière. On le sais également, pour que celles-ci se fasse sur le long terme, il faut que celles-ci se fassent de manière automatique, et sur un autre support que le PC que l’on souhaite sauvegarder. Le problème qui se pose est le suivant : comment concilier ces deux conditions sur un PC de bureau ( ne disposant donc pas d’une série de serveur allumés en permanences et prêt à recevoir nos sauvegardes en continue… ) ?

Pour répondre à tout cela, nous allons mettre en place un système de backup sur disque dur externe, qui se lancera à chaque fois que notre disque sera monté. À chaque fois que le disque dur sera allumé, la sauvegarde s’enclenchera. Cela ne garantie pas, bien sûr que les sauvegardes se feront à un intervalle régulier, mais cela garantie au moins que nous n’aurons pas à nous en soucier. Pour cela nous allons utiliser les outils qui sont disponibles sous un environnement Linux : rsync et hal. Cet article nous présente une base pour faire notre sauvegarde Une sauvegarde améliorée avec rsync. Nous allons juste devoir le modifier un petit peu pour répondre à un problème qui arrive souvent avec les périphériques USB : selon que d’autres périphériques sont déjà montés ou non, nous ne savons pas dans quel répertoire nous allons nous trouve. Il va donc falloir mettre en place une ligne pour récupérer le répertoire dans lequel nous sommes. Il ne nous reste plus qu’à trouver le moyen de l’éxécuter automatiquement pour cela nous allons utiliser halevt. Le script est disponible ici

Comme son nom l’indique, halevt est un gestionnaire d’évènements pour hal. Hal est un gestionnaire d’évènement matériel sous Linux; il envoie des informations à chaque fois que des informations sont envoyées depuis les composants. Cela permet de détecter le branchement d’un périphérique USB et de le monter sur le bureau ( et qui nous simplifie grandement la vie aujourd’hui !!!). Halevt est un démon à l’écoute des informations qui nous sont envoyées par hal, et d’activer des actions en conséquence : par exemple pour lancer l’antivirus sur la clef usb, reconfigurer le mappage du clavier en fonction de la marque que l’on branche etc. Pour notre part, nous allons nous contenter de lancer un script (celui du backup mentionné plus haut ).

Pour commencer nous allons devoir identifier le lecteur à mettre sous surveillance : inutile de se baser sur les noms de montage habituels ( /dev/sda par exemple ) en effet en fonction des périphériques déjà branchés nous n’allons pas obtenir la même configuration. Nous allons utiliser les point de montage défini dans /dev/disk/by-uuid qui permet d’obtenir l’identifiant de notre disque (et qui sera repris par la suite dans la configuration de hal ). Une fois que nous avons relevé quel est le disque concerné, il faut mettre en place une entrée pour notre évènement dans la configuration de halevt :

<halevt:Device match="hal.block.device &amp; hal.block.is_volume = true &amp; hal.volume.uuid = fd20536f-7b80-4a80-8c3d-b5bebe8fb484">
<halevt:Property name="hal.volume.is_mounted">
<halevt:Action value="true" exec="bash $hal.volume.mount_point$/chemin/script/backup-ssh.sh"/>
</halevt:Property>
</halevt:Device>

Cela si halevt est exécuté avec les droits de l’utilisateur lançant le backup. Si on le fait tourner en démon, il faut trouver une autre solution ( sur mon poste j’ai utilisé sudo, mais on peut très bien se baser sur le sticky bit pour donner les droits au script ). De même, dans la configuration mise en place, le script se trouve sur le disque de stockage ( de manière à pouvoir le lancer à la main si le démon n’est pas disponible ), cela peut être adapté en fonction de chacun…

Dans le cas d’une configuration multi-utilisateur, je pense qu’il est nécessaire de passer par un script qui lance les différentes sauvegardes sous le bon groupe de l’utilisateur à chaque fois. ( Ce qui en plus permet d’éviter le problème du sudo ) mais je n’ai pas eu besoin d’aller jusque là pour l’instant ! À vous d’adapter ce que je vous propose en fonction de votre configuration !

Creating the plugin for wminput

There are a lot of tutorials about how to configure cwiid. I let you follow them for getting a functionnal system for your wiimote. You can read the links at the end of this article. Be sure your system works well before continuing.

Thiis is a code that we’ll use as template for the creation of our driver. Used as main, it use pygame for displaying the infrared sources the wiimote can detect, but it is also compatible as plugin for wminput ( even if it does anything for now ).

You can get it here : wm_control.py ( This code is licenced under GPL 3+ )

About the code :

    import wmplugin

This import does not exist, but is created by wminput when executed. It provide the connexion with the wminput core. Just put ( or link ) the script in the wminput plugin path ( on my debian this is the /usr/lib/cwiid/plugins/ )

def wmplugin_init(id, wiimote_arg):
    wmplugin.set_rpt_mode(id, cwiid.RPT_IR | cwiid.RPT_BTN)
    return

def wmplugin_info():
    return [], \
      [("X", wmplugin.REL | wmplugin.ABS, 1024, 0, 0, 0), \
       ("Y", wmplugin.REL | wmplugin.ABS, 768, 0, 0, 0)], \
    []

We instanciate the wiimote object here and configure it in the IR mode. The name is choosen by wminput if we want to use it as plugin. We define that the plugin return the coordonates X and Y in a relative system ( you can get the signification of all the parameters here : actions list)

If we want to define new butons, we just have to name them in the first list, the’ll be accessible in the configuration file as plugin.[buton_name] = ACTION

def wmplugin_exec(messages):
    '''Wiimote callback managing method
    Recieves a message list, each element is different, see the libcwiid docs'''
    x = y = 0

    for msg in messages:
        if msg[0] == cwiid.MESG_IR:
            x, y = ir_sensor.get_movement(msg)
    return [], (x, y)

Here is the core of our driver. The name is choosen by wminput too, as the format value we return. We have in parameter the list of the messages the wiimote has sent.

If we have defined buton we need to return their state here. It is a boolean saying if the buton is pressed ( True ) or not ( False ).

This method doesn’t send any others parameters, and this is a problem when we need to store data between two calls ( ie for saving the cursor position ). One way for passing throught is to use global variables. But it is unelegant and can cause problems if we want to use our code in imports. So we’ill use a list as default parameter and let python save it as you can see here :

>>> def meth(a=[]):
...     a.append(1)
...     print a
...
>>> meth()
[1]
>>> meth()
[1, 1]
>>> meth()
[1, 1, 1]

So the ir_sensor.get_movement method is defined with each parameter we want to save as an optional list

def get_movement(msg, _old_points=[], _old_position = [0, 0]):
    return 0, 0

The get_movement method need to return the difference between the old position of the cursor and the new one in tuple : (0, 0) mean that the cursor didn’t move, (-10, 0) mean a deplacement to the left.

For now, the plugin doesn’t move the cursor, and doesn’t read what the wiimote has sent. But you know everything for creating your own plugin for controlling your wiimote.
You can use all the cwiid method for setting the led, activating the differents modes of your wiimote ( IR, Acc, rumble … ), and define here your own actions.
I’ll explain the core of the movement analysis in IR mode in the next article.

Links :
The cwiid project

Install Cwiid ( Ubuntu Documentation )

La quadrature du net lance un appel à la mobilisation contre le projet de loi Hadopi qui vise à réguler le “piratage” sur le net. non seulement en mettant en place la riposte graduée ( qui conduit à couper l’accès à internet ), mais en autorisant l’enregistrement et l’analyse des différentes communications qui transitent sur le réseau. A la base instaurée pour répondre à la demande des artistes pour lutter contre le piratage, cette loi va plus loin et permet des dérives qui font peur : à l’heure ou nos communication par téléphone, ou notre courrier ou nos sources d’informations passent par internet, il est important de protéger notre espace et de le défendre.

Malheureusement, j’ai l’impression que personne ne chercher à protéger sa liberté sur le net. Les campagnes d’information sur les données personnelles n’empêchent pas les individus de continuer à s’inscrire massivement sur facebook ou d’utiliser msn pour communiquer, par commodité et par pratique, mais en oubliant que derrière tout ces services, il y a un prix à payer : celui de notre anonymat et de notre liberté.

A l’heure il il devient anormal de chercher à protéger sa vie privée même “si l’on n’a rien à se reprocher”, je pense qu’il faut rappeler à tous, que cet espace qui peut sembler si loin, si distant de notre vie, est en fait incrusté dans nos domicilies, nos consoles de jeux ou nos téléphones, et mettre en place des mesures de contrôles sur le net permettent de réduire très facilement les libertés de l’individu

Facilement car :

• Ce contrôle se fait en silence : il est fait de manière automatique sans que l’individu ne s’en rende compte. La dérive étant que l’on ne sait plus très bien quelle est la limite entre ce qui est contrôlé et ce qui ne l’est pas.
• Ce contrôle est global : avec la puissance des machines, il devient possible de surveiller l’ensemble des connexions des internautes, et de voir tout ce qui transite sur les réseaux.
• Ce contrôle est permanent : pour les même raisons.

Avant qu’il ne soit interdit d’utiliser un logiciel non conforme, essayons de préserver notre liberté et d’affirmer ce que nous défendons.

La wiimote est la manette de contrôle de la console wii de Nintendo, un outil merveilleux dont voici un petit résumé de ses fonctionnalités :

• Accéléromètres
• Caméra infrarouge
• Émetteur/Récepteur Bluetooth
• 11 boutons

( voir le détail sur la page de wikipédia )

En disposant d’un récepteur bluetooth, il est possible de se connecter à la télécommande et de récupérer ses informations, mieux, avec le projet cwiid, on peut transformer la wiimote en souris !

Ainsi selon le mode dans lequel se trouve la télécommande, on contrôle notre curseur en inclinant la télécommande, ou en la pointant vers une source infrarouge

La source infrarouge pouvant être la sensor bar fournie avec la console, ou une source externe, bougie lampe ou tout ce dont pouvez disposer diffusant de la chaleur à partir d’un point unique

Le pilote fourni avec cwiid fonctionne mais n’est pas optimisé. Il arrive que la souris parte dans une direction incontrôlée, ou de ne pas pouvoir accéder à certaines parties de l’écran.

La faute est due au pilote intégré qui se contente juste de placer le pointeur sur la source infrarouge, avec quelques petites optimisations.
En effet, le capteur de la wiimote nous indique quelle est la position de toutes les sources infrarouges perçues ( et nous fourni également des informations sur leur intensité ), mais la conversion en pointeur est laissée au pilote :
Quelle source choisir comme référence ?
Comment gérer les cas où une source est sortie du champ de vision ?
Comment réagir quand cette source revient dans le champ de vision ?

Tout ceci doit être pris en compte pour pouvoir offrir une ergonomie au curseur et faciliter le contrôle.

Heureusement pour nous le pilote nous donne la possibilité de réécrire nos propres moteurs, et donc de gérer nous même la manière dont on veut que la souris réagisse. Nous avons même le choix dans le langage ! En effet, nous pouvons choisir entre offrir un plugin compilé ( le pilote est écrit en C ), ou l’écrire en python. C’est cette deuxième option que je vais présenter dans les articles qui suivront.

Suite : mise en pace du plugin (EN)

Il y aurait beaucoup à dire dans l’anthropologie des fêtes et réceptions organisées entre amis. Dans ce domaine, un point qui me parait amusant est celui de l’actualisation de la question du Don dans nos sociétés contemporaines. En effet, alors que je participe à des soirées où ce sont les invités qui sont chargés d’apporter les biscuits apéritifs et les boissons, je constate qu’il y a une circulation des biens, un échange sans cesse renouvelé, mettant en jeu la logique du don, de la consommation et de l’échange.

La question des réceptions répond à une fonction sociale depuis longtemps, et marque un point structurant la socialité, étant associées à des moments de fête et de relations entres individus. Il n’est pas surprenant que ces fêtes soient organisées de manières différentes selon les catégories sociales qui y participent et qu’elles suivent des normes différentes. Ce dont je vais parler ici touche les fêtes organisées par des populations proches du milieu étudiant, jeunes et dans une situation qui n’est pas financièrement stable. Elles ont pour point commun de demander aux invités de se charger d’apporter ce qui concerne l’apéritif et les boissons, et de laisser l’hôte préparer le repas.

Le don

M. Mauss nous à présenté la logique du don et les règles qui y sont associées. Pour que cette logique fonctionne, il y a en effet des règles à respecter qui permettent d’en assurer la cohésion au fil du temps. Il est ainsi nécessaire de :

• Ne pas refuser le don qui nous est fait
• Rendre un objet de nature équivalente à celui qui nous à été donné
• Différer dans le temps ce contre-don
• etc.

Le don ne doit pas forcément être d’une grande valeur, mais doit entrer dans cette logique de l’échange. Dans notre cas des soirées organisées, on conçoit mal quelqu’un souhaitant repartir avec la bouteille qu’il a apporté pour le repas. De même, cela serait remarqué que l’on ramène à un ami les biscuits qu’il nous avait apporté lors de la soirée qu’il organise quelque temps après nous. Par contre la circulation n’interdit pas de les apporter à une autre personne lorsque l’on se fait inviter par des personnes qui ne participaient pas à l’échange qui avait précédemment eu lieu…

Cette circulation oblige le participant à jouer le jeu, selon le principe des règles sociales, ou il peut être mal vu qu’une personne répète trop souvent un manquement dans cette circulation; la règle est transgressée mais celle-ci ne reposant que sur la bonne fois des participants, rien ne peut être reproché à quiconque…

Un vrai mois de novembre, il commence à faire frais, et les jours raccourcissent. C’est agréable de profiter des lumières de la ville, de voir toutes ces couleurs et de profiter du froid… Ça donne envie de prendre son temps et de d’aller boire des chocolats chauds dans les cafés…!

En fait pour moi, c’est plutôt boulot dans la journée et transport entre chien et loup, mais il n’empêche, ça me plaît. J’ai juste envie de dire que je suis bien. J’aimerai que le temps s’écoule plus lentement, avoir davantage le temps de me poser, profiter et ne rien faire.

Il n’empêche, c’est l’automne, le temps ralenti, tout tourne plus lentement, et j’ai envie d’en profiter.

Voici une méthode que j’ai mis en place pour protéger l’accès à mon répertoire /home via Cryptsetup. Il existes de nombreux tutoriels expliquant comment créer une partition chiffrée, je ne vais pas détailler cela ici. L’intérêt du script que je propose ici est qi’il se lance au moment du login, et qu’il va chercher le mot de passe sur une clef USB.

Charger le mot de passe contenu dans la clef USB

Il suffit juste de l’insérer avant de se logguer, et de la retirer une fois l’authentification réussie.

Voici le script en question

#!/bin/sh

#Si la clef n'est pas insérée, refuse le login
[ -b /dev/disk/by-uuid/chemin-de-la-clef ] || exit 1

if [ -b /dev/mapper/home ]
	then
		#Si la partition est deja montée, connecte
		exit 0
	else

		# Monte la clef
		mkdir /tmp/clef/
		mount /dev/disk/by-uuid/chemin-de-la-clef /tmp/clef/ 2>/tmp/out

		# Déchiffre la partition
		/sbin/cryptsetup luksOpen -d /tmp/clef/clef /dev/disk/by-uuid/chemin-de-la-clef home 2>>/tmp/out

		# Démonte la clef, elle peut maintenant être retirée sans pb
		umount /tmp/clef
		rmdir /tmp/clef/

		mount -o defaults -t ext2 /dev/mapper/home /home
		exit 0

fi

Bien sûr, il faut que la clef soit contenue dans le fichier clef sur le périphérique USB.

Mettre le script au login de l’utilisateur

Maintenant, 2ème étape, il s’agit de lancer ce script au moment où l’utilisateur vient de se logguer.
Comme je passe par un login manager sur mon portable ( GDM ), j’ai choisi d’utiliser ses ressources pour lancer le script. En effet, GDM possède des scripts qui sont lancés aux différents moments de la connexion. Ce qui nous intéresse ici se trouve dans le fichier : /etc/gdm/PostLogin/Default
Il suffit d’y coller notre script ( ou d’y faire appel ) , et notre partition sera activée automatiquement lors de la connexion ( et seulement si le mot de passe est valide ).
On peut obtenir des paramètres de la part de GDM dans ce script, nom de l’utilisateur qui se loggue, répertoire de login etc, cela permet de personnaliser notre script si on le souhaite..
Un code de retour en erreur refusera le login, que le mot de passe entré soit bon ou non…

Beaucoup d’articles sont déjà parus sur l’utilisation de fail2ban pour protéger son ordinateur. Je vais parler ici d’une utilisation avancée de fail2ban, couplé avec le pare-feu iptables dans le but de faire plein de joli de choses avec ceux qui tentent d’accéder à nos Pcs !

Pour rappel, fail2ban permet de bloquer certaines IPs en fonction de ce que les logs renvoient comme messages. Il est possible de déterminer les ports sur lesquels les IPs seront bloquées et la durée du blocage. En ce qui concerne les filtres qui déclencheront ou non le blocage, cela se base sur des regex, et on peut déterminer le nombre de tentatives avant qu’un blocage ne soit appliqué.
Dans l’esprit du projet, fail2ban empêche les attaques par force brute, mais nous allons voir qu’il est tout à fait possible de l’utiliser dans d’autres fins.

Créer de nouvelles règles de filtrage

Dans un premier temps, nous allons mettre en place une nouvelle règle de blocage pour, par exemple, bloquer les IPs en fonction des codes d’erreurs d’apache.

Mettre en place une nouvelle règle se fait de manière très simple, il suffit de créer un fichier contenant la regex à appliquer, et de mettre une référence vers ce fichier dans la configuration de fail2ban.

Dans notre cas, pour bloquer les IPs ayant générés une erreur 403 ou une erreur 401 dans apache, notre regex se présentera ainsi :

failregex = :80  .* ".*" 403 = :80  .* ".*" 401

(Celle-ci est bien sûr à adapter en fonction de la manière dont vous affichez vos logs de connexions. )

Dans le fichier de configuration de fail2ban ( /etc/fail2ban/jail.conf ), nous allons demander la lecture de ce fichier en indiquant quelques paramètres supplémentaires :

[apache-block]
enabled = true #Oui on active
port = http #On ne bloque que le port 80
filter  = apache-block # le nom du fichier que l'on a créé juste avant
action  = %(action_)s
logpath = /tmp/log/apache*/*access.log
maxretry = 1 #Nombre de tentatives
banaction = iptables-redirect # L'action à appliquer sur l'IP
bantime = 3600 # Le temps pendant lequel l'ip sera bannie.

Créer de nouvelles actions

Une fois que fail2ban aura lancé une procédure de blocage sur une connexion, il va lancer un script contenant les actions à réaliser sur cette IP. D’habitude ce script contient une règle iptables qui bloque l’adresse, et une autre règle qui supprime ce blocage.
Nous allons maintenant jouer avec iptables pour réaliser quelques effets intéressant avec nos IPs à bannir :

Par défaut, fail2ban retire le blocage sur l’IP une fois que la durée spécifiée est écoulée. Je trouve ceci limité car cela n’empêche pas l’attaquant de continuer ses attaques et se retrouver prêt à refaire une attaque dès que cette durée est écoulée. De plus, cela peut donner une information sur la durée pendant laquelle nous filtrons son adresse.
iptables propose un module, modrecent, permettant de bloquer une IP pendant une durée déterminée, et de réinitialiser cette durée si jamais une nouvelle connexions venait à être réalisée durant cette période.
Pour ceci nous allons devoir une règle iptables, en dehors de fail2ban, qui consistera à bloquer une IP pendant telle période :

Dans fail2ban, nous allons créer un nouveau fichier action, qui se présentera comme suit :

 #On crée une nouvelle table
actionstart = iptables -N fail2ban-<name>
#On bloque les connexions 2 fois sur 3
iptables -A fail2ban- -m statistic --mode random  --probability .33 -j REJECT --reject-with icmp-host unreachable
iptables -A fail2ban-<name> -j DROP
#On insère une nouvelle règle qui met à jour le compteur à chaques nouvelles tentatives tant que le délai n'est pas écoulé
iptables -I INPUT -p  <protocol> -m multiport --dports  <port> -m recent --update --seconds 360000 --name fail2ban-- -j fail2ban-<name>
#Pour bannir une IP, il suffit de l'écrire dans le fichier de configuration de mod-recent
actionban = echo  <ip> > /proc/net/ipt_recent/fail2ban-<name>

On peut décider d’annoncer à notre utilisateur bloqué que nous avons banni son IP. Cela peut être utile si nous avons mis en place des règles de filtrage très strictes et qu’un utilisateur peut se retrouver bloqué sans avoir tenté la moindre intrusion ( mieux vaut être trop prudent que pas assez )
Pour cela, nous allons avoir besoin d’un service qui consistera à afficher le texte sur demande. Hors de question de demander ça à apache ou autre serveur web, nous allons mettre en place notre propre serveur web, qui présentera une page statique, toujours identique.
socat et tout désigné pour cela. Dans notre exemple nous allons le faire tourner en tant que serveur, sur un port ouvert, et avec des droits limités. Notre règle iptables consistera juste à rediriger les connexions entrantes sur le port 80 vers le port où l’on fait tourner socat.

sudo -u nobody socat tcp4-listen:6666,reuseaddr,fork exec:"cat /etc/apache2/banned.html" &

et la règle iptables à mettre en place :

#On crée la règle sur la table de préroutage :
actionstart = iptables -t nat -N fail2ban-<name>
iptables -t nat -A fail2ban-<name> -j RETURN
iptables -t nat -I PREROUTING -p  <protocol> -m multiport --dports <port>-j fail2ban-<name>
iptables -N fail2ban-<name>
iptables -A fail2ban-<name> -j RETURN
iptables -I INPUT -p   <protocol> -m multiport --dports   <port> -j fail2ban-<name>

et pour lancer l’action, là encore, on simule une perte de paquet pour ralentir le temps d’affichage de la page

actionban =  iptables -t nat -I fail2ban-<name> 1 -s  -p tcp -m multiport --dports  <port> -m statistic --mode nth --every 3 -j REDIRECT --to-port 6666
iptables -I fail2ban-<name> 1 -s  -j DROP

Les règles d’unban et de stop se font en symetrique de ban et start, en supprimant des règles crées.

Voilà, cela permet de mettre en place une sécurité personnalisée et adaptée, qui sort déjà des outils et configuration standards ( ce qui est toujours une bonne chose en matière de sécurité ). Les exemples que j’ai donné ne sont que des suggestions, et il possible de faire beaucoup d’autres choses avec un peu d’imaginations. Je vous renvoie au manuel d’iptables qui présente la liste de tous les modules existants, et de regarder un peu les paramètres disponibles parmi les fichiers de configuration de fail2ban. Mon seul regret est qu’à ce jour, ce programme ne gère pas encore les Ip en v6, mais ça n’est – pour l’instant – pas encore critique..