Lire la Suite »]]> Fort de ma nouvelle autorité, je commencerai par montrer au peuple français mon réalisme. Il est impossible de s’imaginer les problèmes du peuple sans soi-même faire partie du peuple. Or, le peuple ne se vautre pas dans la luxure. Le salaire français moyen est légèrement supérieur à 1000€. Comment peut-on comprendre son peuple quand soi-même on gagne près de 20 fois plus ? Comment peut-on savoir si toutes les taxes qu’on impose à un pays peuvent être déboursées par ses citoyens ?

Ma première action consiste à réduire significativement mon salaire de « dirigeant » du peuple français. Un salaire de 20 000€ mensuels n’est qu’une apparence, un artifice. Cela ne sert qu’à montrer le pouvoir qu’on a sur son peuple. Je déciderai donc de porter mon salaire à 1000€ nets mensuels. Après tout, un « Président » de la république dispose manifestement de bon nombre d’autres avantages. Inutile de gagner plus.

Ma seconde action va être de changer la terminologie du chef du gouvernement. « Président » me semble être doté d’une connotation négative, inspirant la supériorité, l’assise d’un pouvoir sur le peuple. En tant que nouveau chef d’État, je me considère comme le guide du peuple français. Sans majuscule. Parce que si je suis à la tête des français aujourd’hui, c’est pour les guider vers des jours meilleurs.

Ma troisième action va consister à supprimer tous les élus, tous les représentants du peuple. Je supprime les maires, les députés, les sénateurs. Je veux redonner le pouvoir aux français. Je veux que les français participent à nouveau activement à la vie politique du pays. Je crois que si les bureaux de votes se vident, c’est d’une part à cause du nombre d’intermédiaires trop élevé, et d’autre part parce qu’ils ont le sentiment de ne pas être écoutés, que le gouvernement fait de toute manière ce qu’il a décidé, peu importe ce que dit le peuple.

Je veux instaurer une vraie démocratie. LA vraie démocratie. Je veux rendre impossible l’adoption d’une loi, d’un traité, ou d’un décret, sans le consentement du peuple français. Pour y parvenir, je mettrais en place une plateforme permettant à tout un chacun de consulter librement toute proposition qui sera faite, et d’y donner son avis. La proposition ne sera adoptée qu’en cas de majorité absolue. C’est ainsi, et seulement de cette manière, qu’un gouvernement peut être qualifié de démocratique. Pas en permettant à des intermédiaires de répondre du peuple, qui les ont choisi en fonction de campagnes coûteuses, et menées dans l’unique but de se vendre. Je suis persuadé que redonner son pouvoir à la voix des français sera une motivation suffisante pour que le vote redevienne un acte de pure volonté.

La réduction du salaire du chef de l’État, la suppression de ces intermédiaires, la récupération puis la revente des biens appartenant à l’État prêtés aux intermédiaires et jugés somptuaires, permettra de réaliser des économies substantielles. Et pour une fois, pas en saignant les français.

Ma quatrième action sera l’arrêt pur et simple de la coopération avec toute entreprise ou organisme dont les méthodes ou les convictions vont à l’encontre de la liberté de l’individu, qu’il soit français ou résident de pays étranger. Il est intolérable que notre ancien gouvernement ait pu tisser des liens avec des entreprises fournissant des solutions informatiques à des chefs d’États leur permettant d’espionner leur peuple.

Par extension, je supprime tout organisme étatique voué à la seule sécurité du gouvernement au mépris de son peuple. Je récupère une France scindée en deux : le peuple se sent aujourd’hui oppressé, menacé par ses dirigeants, alors que le rôle de tout gouvernement est de protéger son peuple, et il en a toujours été ainsi. Nous vivons des jours sombres, où les peuples n’ont plus aucune estime de leur chef d’État ; pire encore, ils le craignent. Tous ne s’avouent pas dictateur, et pourtant, tous sont manipulés par la possession et la richesse.

Je supprime donc la Hadopi, et tous ses employés. Je supprime tout lien avec la société Amesys, et avec toutes les autres entreprises avec lesquelles notre ancien gouvernement a pu être en relation, et dont les activités sont en désaccord avec les droits fondamentaux de l’Homme.

Je supprime également toutes les taxes injustifiées, illégales, immorales, et inutiles. Après tout, les économies réalisées sur la suppression des intermédiaires et la forte réduction de mon salaire et de mes avantages ne peuvent que conduire à une réduction du poids fiscal sur le peuple français. Comment notre ancien gouvernement a-t-il pu se rincer sur le dos de son peuple ? Comment peut-on faire preuve d’aussi peu de respect envers le peuple qui l’a choisi ?

Parmi les taxes dont je parle, j’évoque notamment les taxes sur les carburants, sur les produits de grande consommation, mais aussi la taxe sur la copie privée, absolument inutile et injustifiée. De quel droit l’État taxe-t-il  un produit sur lequel il n’a aucun pouvoir décisionnel ? Est-ce que le gouvernement participe à la fabrication du lait ? À celle de l’essence ? Pourquoi l’État devrait encore toucher presque 50% du prix de vente du pétrole, alors qu’il ne l’extrait pas, ni ne le raffine, ni ne le transporte ? De quel droit l’État s’arroge-t-il presque 50% du salaire de ses citoyens, répartis entre impôts, taxes, cotisations obligatoires, etc. ? Jusqu’aujourd’hui, qu’a exactement fait l’État pour mériter une telle somme ?

Je compte mettre en place une forme de méritocratie. Le rôle du gouvernement est de protéger son peuple. Pas seulement en cas de guerre, mais aussi quand d’autres gouvernements s’attaquent à son intégrité. Et par intégrité, j’entends liberté individuelle. La liberté de vivre, de s’exprimer, de s’indigner, d’être heureux, insouciant, concerné. La liberté d’écrire, de composer, de développer. La liberté d’accéder à toute forme de culture ou de science.

Car c’est en partageant culture et sciences que les civilisations, que LA civilisation humaine a pu se développer, grandir, survivre, jusqu’à conquérir les océans et les étoiles. Notre ancien gouvernement a tout tenté pour empêcher le partage libre de la culture et de la science. Notre ancien gouvernement estimait que certaines civilisations valaient mieux que d’autres. Je crois que c’est précisément ce manque de discernement qui a causé la chute des anciennes civilisations, et des plus grandes. Je crois que c’est la soif de pouvoir et de richesses qui a causé leur déclin. Et c’est précisément ce dans quoi tombent les dirigeants de notre époque.

Après tant d’oppression, tant de mal causé aux peuples, tant de viols de leur liberté et de leur intégrité, il ne peut y avoir qu’un avenir radieux, parce que désormais, il ne peut plus y avoir que des dirigeants bons avec leurs peuples. Et c’est ce à quoi je vais m’employer.

Pour y parvenir, je l’ai dis, le peuple français aura la parole sur toute décision politique ; les intermédiaires seront supprimés, tout comme les lois, les organismes et les entreprises allant à l’encontre des libertés ; la culture et la science seront libres d’accès à tous : tout le monde pourra contribuer au savoir et à la connaissance. Et je me ferai un devoir d’inciter les autres gouvernements à suivre la même voie, et d’insister jusqu’à leur faire entendre raison. Et si ces gouvernements restent intangibles, nous accueillerons ceux qui veulent vivre libres.

Peut-être suis-je utopiste. Peut-être que vous vous dites que jamais je n’y arriverai. Je pense que la liberté des Hommes vaut bien qu’on essaye. Nous avons longtemps critiqué les chefs d’État, sans vraiment proposer d’alternative, ou, quand on le faisait, elles étaient rejetées. Voulez-vous réellement sacrifier un espoir de retrouver notre liberté, simplement parce que la tâche parait trop ardue ? En ce qui me concerne, et en tant que guide, j’ai la force de tenter ma chance, parce que je crois encore en l’Homme, et je crois qu’il est encore capable de bonnes choses.

Lire la Suite »]]> On continue notre nouvelle série d’articles. Après avoir créer un pare-feu de base que nous complèterons au fil des articles, après avoir mis en place une autorité de certification, puis un serveur DNS et un serveur mail, nous nous attaquons maintenant à l’installation du serveur apache.

Apache devra pouvoir desservir des pages aussi bien en HTTP qu’en HTTPS, permettre l’utilisation de langages comme PHP et les scripts CGI, tout en assurant une bonne réactivité et un degrés certain de sécurité.

Un serveur HTTP(S) nous permettra de mettre en place une grande variété de services : dans un premier temps, un outil pour gérer notre base de données et un client mail, puis par la suite, un blog, un wiki, un lecteur de flux RSS, etc.

Il nous permettra également de mettre en place un proxy pour simplifier l’accès à des applications offrant une interface web, partager et accéder aux fichiers, et bien d’autres choses encore. Rappelons que l’objectif est de s’affranchir de tout outil du Cloud, proposé par de grandes entreprises telles que Google. Apache en sera un moyen d’y accéder facilement.

Ce petit rappel effectué, on peut organiser les sites desservis par apache de la manière suivante :

/var/www			Racine
/var/www/exemple.fr		Racine du domaine
/var/www/exemple.fr/mail	Racine du sous-domaine mail
/var/www/exemple.fr/mail/www	Racine du site hébergé
/var/www/exemple.fr/mail/log	Journaux
/var/www/exemple.fr/www		Racine du domaine principal
/var/www/exemple.fr/www/www	Racine du site hébergé
/var/www/exemple.fr/www/log	Journaux

Une telle arborescence permet d’organiser correctement les différents sites qui pourront être desservis par Apache, tout en ayant rapidement à portée de la main les journaux pour chaque sous-domaine. Cela nous permettra également de confier ces journaux à une application telle que awstats pour une analyse plus efficace que si tous les journaux étaient regroupés dans le même fichier.

Avant toute chose, installons quelques paquets, stoppons apache, et supprimons les hôtes virtuels par défaut :

apt-get install apache2 libapache2-mod-php5 php5 php5-mysql php5-mcrypt php-mdb2 php-mdb2-driver-mysql
/etc/init.d/apache2 stop
a2dissite default && rm /etc/apache2/sites-available/default
a2dissite default-ssl && rm /etc/apache2/sites-available/default-ssl
cd /etc/apache2

On désactive ensuite totalement la journalisation dans apache :

rm conf.d/other-vhosts-access-log
nano apache2.conf

Commentez la ligne :

ErrorLog ${APACHE_LOG_DIR}/error.log

Comme on va également faire appel à SSL, on active le port 443 :

mv ports.conf ports.conf-orig
nano ports.conf

NameVirtualHost *:80
NameVirtualHost *:443
Listen 80
Listen 443

On va continuer en créant quatre arborescences différentes, pour quatre sites différents.

Le premier pourrait être simplement qualifié de bonne pratique : afin d’accélérer le chargement des pages, il convient de confier certains éléments à un sous-domaine particulier, desservi par un hôte virtuel ne journalisant pas ses accès, et contenant des éléments statiques, tels que des images ou des scripts. On économise ainsi plusieurs cycles d’écriture à chaque chargement de page.

Domaine static

Créons la première arborescence :

mkdir -p /var/www/exemple.fr/static/www

On créé ensuite notre premier hôte virtuel :

cd /etc/apache2/sites-available
nano static.exemple.fr

<VirtualHost *:80>
	ServerName static.exemple.fr
	ServerAdmin contact@exemple.fr

	DocumentRoot /var/www/exemple.fr/static/www
</VirtualHost>

Rien de bien sorcier : on déclare un nouvel hôte virtuel écoutant sur toutes les interfaces configurées dans apache (*) sur le port 80. On déclare également le nom de domaine affecté à cet hôte virtuel, en indiquant éventuellement (ce n’est pas une obligation) l’adresse email du responsable. Enfin, la dernière directive défini la racine du site, là où se trouveront les fichiers. Pour le moment, il n’y en a aucun, mais au moins, on a un hôte virtuel destiné à stocker les fichiers statiques, c’est déjà ça.

Domaine www

Le domaine (sous-domaine plus exactement) www est un peu particulier dans la mesure où il est plus utilisé par habitude que réel besoin : on se passe très bien de la partie www dans www.exemple.fr. Cela nous donne toutefois deux bonnes occasions : conserver notre arborescence de base saine, et voir comment créer un alias de domaine.

Notre objectif sera de faire en sorte que, peu importe si on accède à notre site principal via http://exemple.fr ou http://www.exemple.fr, on devra tomber sur la même page. On aura recours, pour cela, à la directive ServerAlias.

On créé donc notre second hôte virtuel avec son arborescence :

mkdir -p /var/www/exemple.fr/www/{www,log}
nano www.exemple.fr

<VirtualHost *:80>
	ServerName exemple.fr
        ServerAlias www.exemple.fr
	ServerAdmin contact@exemple.fr

	DocumentRoot /var/www/exemple.fr/www/www

        CustomLog /var/www/exemple.fr/www/log/access_log
        ErrorLog /var/www/exemple.fr/www/log/error_log
</VirtualHost>

Par la même occasion, on en a profité pour spécifier le chemin vers le journal des accès et le journal des erreurs. Il faudra procéder de même pour tout hôte virtuel créé à l’avenir.

Pour le moment, nous n’utiliserons pas ce domaine : c’est vous qui déciderez ce que vous voulez en faire : blog, portail privé, etc.

Domaine mysql

Le nom de ce sous-domaine importe peu. J’ai choisi mysql, comme j’aurai pu choisir pma, phpmyadmin, admin ou tout autre. Cependant, en consultant régulièrement mes logs, j’ai constaté que certains s’amusent à scanner certains sous-domaines-clés, pour éventuellement tomber sur un script d’administration non-sécurisé. J’ai vu passer toutes sortes de sous-domaines, mais assez étonnamment, peu tentent mysql.exemple.fr.

Ce domaine servira à accéder justement à phpMyAdmin, script php probablement le plus utilisé pour administrer graphiquement ses bases de données. Outre l’aspect pédagogique de sa présence dans cet article, puisque c’est un bon prétexte à l’introduction à SSL avec apache, ce sera également un outil très pratique pour la création de futures bases de données, mais aussi pour des tâches plus triviales comme la population de notre première base créée, MailServer.

Créons l’arborescence et l’hôte virtuel :

mkdir -p /var/www/exemple.fr/mysql/www

nano mysql.exemple.fr

<VirtualHost *:80>
	ServerName mysql.exemple.fr
	Redirect / https://mysql.exemple.fr/
</VirtualHost>

<VirtualHost *:443>
	ServerName mysql.exemple.fr

	DocumentRoot /var/www/exemple.fr/mysql/www

	SSLEngine On
	SSLCertificateFile /scripts/certificate_authority/apache/mysql.exemple.fr.crt
	SSLCertificateKeyFile /scripts/certificate_authority/apache/mysql.exemple.fr.key
</VirtualHost>

Ici, nous créons un hôte virtuel écoutant sur le port 80, dont l’unique objectif sera de forcer la redirection vers le même hôte virtuel, mais écoutant sur le port 443 (le port HTTPS). La connexion à mysql.exemple.fr sera donc forcément chiffrée.

On va tout de suite créer le certificat et la clé qui vont bien :

/scripts/certificate_authority/make_request apache mysql.exemple.fr
/scripts/certificate_authority/sign_request apache mysql.exemple.fr
chown www-data:www-data /scripts/certificate_authority/apache/*

On va ensuite télécharger et installer phpMyAdmin. À l’heure où j’écris ces lignes, la dernière version disponible est la 3.4.9.

cd /usr/src
wget http://freefr.dl.sourceforge.net/project/phpmyadmin/phpMyAdmin/3.4.9/phpMyAdmin-3.4.9-all-languages.tar.gz
tar zxf phpMyAdmin-3.4.9-all-languages.tar.gz
cp -Rv phpMyAdmin-3.4.9-all-languages/* /var/www/exemple.fr/mysql/www/
mkdir /var/www/exemple.fr/mysql/www/config/
chown -R www-data:www-data /var/www/exemple.fr/mysql/www

Après avoir décompressé l’archive, on a copié les fichiers extraits dans le répertoire racine du sous-domaine mysql, puis on a créé le répertoire config qui va nous servir à paramétrer phpMyAdmin. Enfin, on a attribué les bons droits à l’ensemble de l’arborescence.

chown -R www-data:www-data <fichier ou répertoire>

Pour le moment, notre serveur n’est pas accessible depuis l’extérieur, nous nous occuperons donc de la configuration de phpMyAdmin plus tard. En attendant, créons notre dernier hôte virtuel.

Domaine mail

Revenons dans le répertoire de configuration des hôtes virtuels :

cd /etc/apache2/sites-available

Et créons la nouvelle arborescence :

mkdir -p /var/www/exemple.fr/mail/{www,log}

Nous allons combiner tout ce que nous avons vu jusqu’à présent pour créer le fichier de configuration de cet hôte virtuel :

nano mail.exemple.fr

<VirtualHost *:80>
	ServerName mail.exemple.fr
	Redirect / https://mail.exemple.fr/
</VirtualHost>

<VirtualHost *:443>
	ServerName mail.exemple.fr

	DocumentRoot /var/www/exemple.fr/mail/www

	SSLEngine On
	SSLCertificateFile /scripts/certificate_authority/apache/mail.exemple.fr.crt
	SSLCertificateKeyFile /scripts/certificate_authority/apache/mail.exemple.fr.key

        CustomLog /var/www/exemple.fr/mail/log/access_log
        ErrorLog /var/www/exemple.fr/mail/log/error_log
</VirtualHost>

On créé notre couple clé/certificat :

/scripts/certificate_authority/make_request apache mail.exemple.fr
/scripts/certificate_authority/sign_request apache mail.exemple.fr
chown www-data:www-data /scripts/certificate_authority/apache/*

Pour la consultation des mails, on va faire appel à l’excellent RoundCube, actuellement en version 0.7.1.

cd /usr/src
wget http://freefr.dl.sourceforge.net/project/roundcubemail/roundcubemail/0.7.1/roundcubemail-0.7.1.tar.gz
tar zxf roundcubemail-0.7.1.tar.gz
cp -Rv roundcubemail-0.7.1/* /var/www/exemple.fr/mail/www/
cp roundcubemail-0.7.1/.htaccess /var/www/exemple.fr/mail/www/
chown -R www-data:www-data /var/www/exemple.fr/mail/www/

La configuration de RoundCube peut se faire depuis Internet, mais encore une fois, notre serveur n’est pas encore accessible depuis l’extérieur. On va donc patienter encore un peu.

On active maintenant nos hôtes virtuels fraîchement créés :

ln -s /etc/apache2/sites-available/www.exemple.fr /etc/apache2/sites-available/default
a2ensite default
a2ensite www.exemple.fr
a2ensite static.exemple.fr
a2ensite mysql.exemple.fr
a2ensite mail.exemple.fr
/etc/init.d/apache2 start

Consultez les journaux des différents hôtes (en particulier les journaux d’erreurs) pour vous assurer que tout fonctionne bien du côté d’apache.

DNS

On édite le fichier de configuration de notre domaine :

nano /etc/bind/db.exemple.fr

A la fin du fichier, rajoutez les lignes suivantes :

www		IN	CNAME		ns
*		IN	CNAME		ns

Ces deux lignes définissent un alias (CNAME) du domaine www et de tout autre sous-domaine vers l’adresse IP attribuée au sous-domaine ns. Dans notre cas, tous ces sous-domaines pointent vers l’adresse principale de notre serveur (1.1.1.1, pour réutiliser l’exemple de départ).

On redémarre bind :

/etc/init.d/bind9 restart

Firewall

nano /scripts/firewall

Entre les lignes :

##### Configuration personnalisée #####

Et :

##### Fin : Configuration personnalisée #####

Rajoutez les lignes suivantes :

${IPT} -A SERVICES -p tcp --dport 80 -j ACCEPT
${IPT} -A SERVICES -p tcp --dport 443 -j ACCEPT

Configuration de phpMyAdmin

Rendez-vous à l’adresse http://mysql.exemple.fr/setup/ et laissez-vous guider. Une fois que vous avez modifié votre configuration, déplacez le fichier à la racine :

mv /var/www/exemple.fr/mysql/www/config/config.inc.php /var/www/exemple.fr/mysql/www/
chown www-data:www-data /var/www/exemple.fr/mysql/www/config.inc.php

Je vous recommande la lecture de cette page qui va vous permettre de paramétrer phpMyAdmin beaucoup plus finement que ce que permet l’interface web.

Une fois terminé, supprimez le répertoire config :

rm -r /var/www/exemple.fr/mysql/www/config/

Configuration de RoundCube

Maintenant que phpMyAdmin est installé, il vous sera plus simple de créer l’utilisateur et la base de données pour RoundCube. Ouvrez donc phpMyAdmin (http://mysql.exemple.fr), et cliquez sur l’onglet « Utilisateurs« , puis sur le lien « Ajouter un utilisateur » en bas de page.

Donnez-lui le nom de RoundCube, pour le client localhost, et générez un mot de passe. Cochez également la case « Créer une base de données portant son nom et donner à cet utilisateur tous les privilèges sur cette base« .

Rendez-vous ensuite à l’adresse https://mail.exemple.fr/installer/. Sur la première page, vous verrez la liste des dépendances de RoundCube. S’il en manque l’une ou l’autre, installez-la (via apt-get install <paquet> ou pear install <paquet> si la première méthode ne donne rien) et redémarrez apache. Une fois que tout est bon, cliquez en bas sur Next.

Petit exercice : remplissez les différents champs en prenant en considération que :

• Le port SMTP est le 465 (via tls, pas ssl)
• Le port IMAP est le 993 (via ssl, pas tls)
• L’adresse du serveur est 127.0.0.1

Touches finales

Une fois RoundCube correctement configuré, créez-vous votre propre adresse email via phpMyAdmin, dans la base de données MailServer, et dans la table users. Pensez à sélectionner le type MD5 lorsque vous saisirez votre mot de passe.

Par la même occasion, allez dans la table aliases, et créez deux enregistrements, dont le champ source sera respectivement root et postmaster, et destination l’adresse email que vous venez de vous créer. Cela vous permettra de recevoir les mails administratifs envoyés automatiquement par les différents services de votre serveur.

Nous avions précédemment configuré une liste blanche d’expéditeurs, toujours autorisés à vous envoyer des mails. Cette liste correspond à la table access_sender de la base de données MailServer. Nous allons nous servir de RoundCube pour peupler automatiquement cette table, dès que vous enverrez un message.

Éditez la configuration de RoundCube :

nano /var/www/exemple.fr/mail/www/config/main.inc.php

Cherchez le terme « plugins » (via la combinaison de touches Ctrl+w).

Complétez la liste présente, en rajoutant :

"automatic_addressbook"

Modifiez ensuite le plugin en question :

nano /var/www/exemple.fr/mail/www/plugins/automatic_addressbook/automatic_addressbook.php

Aux alentours de la ligne 110, cherchez le code suivant :

foreach($all_recipients as $recipient) {
    // Bcc and Cc can be empty
    if ($recipient['mailto'] != '') {
        $contact = array(
            'email' => $recipient['mailto'],
            'name' => $recipient['name']
        );

Rajoutez après :

$con = mysql_connect("localhost", "MailServer", "MotDePasse");
mysql_select_db("MailServer");

mysql_query("insert into access_sender (`source`,`access`) values ('" . $contact["email"] . "','OK')");
mysql_close($con);

Pensez à modifier le mot de passe (il s’agit de celui de l’utilisateur MailServer).

Enregistrez et fermez. Désormais, dès que vous écrirez à quelqu’un, son adresse sera automatiquement ajoutée à la liste blanche.

Si vous le souhaitez, vous pouvez également éditer directement cette liste, en modifiant le contenu de la table access_sender.

Vous avez maintenant à votre disposition les fondements les plus importants pour la mise en place de votre cloud. Votre serveur est sécurisé via un script iptables restrictif, vous disposez d’un serveur de noms de domaine, d’un serveur de base de données, d’un serveur mail, et d’un serveur HTTP(S). Enfin, vous disposez d’une interface pour gérer facilement votre base de données, et d’un client mail agréable à utiliser.

Dans les prochains articles, nous verrons (dans le désordre) :

• Comment installer une alternative à facebook/twitter/Google+
• Comment installer une alternative à twitpic
• Comment installer une alternative à Google Calendar
• Comment installer une alternative à flickr/Picasa
• Comment stocker des fichiers sur votre serveur comme si celui-ci était sur votre réseau local
• Comment partager des fichiers avec le monde entier
• Comment sauvegarder et restaurer votre serveur

Lire la Suite »]]> Le quatrième article de la nouvelle rubrique va donc traiter de l’installation de son propre serveur mail, élément indispensable de la chaîne de communication. Il existe déjà de nombreux tutoriels sur Internet, parfois très bien faits, parfois incomplets ou inadaptés. Je ne prétends pas que mon article sera mieux que les autres, j’espère seulement qu’il trouvera son public.

Notre serveur mail devra être sécurisé : nous ferons appel au chiffrement, ainsi qu’à diverses applications permettant de filtrer spam et virus, le plus efficacement possible, sans pour autant bloquer les correspondances légitimes (il m’est arrivé que certaines personnes utilisant un serveur SMTP wanadoo (sic) se retrouvent bloquées par mon serveur, à cause d’un non respect du protocole SMTP…).

Nous utiliserons le serveur SMTP postfix, aux côtés duquel tournera le serveur IMAP dovecot. Le filtrage sera confié à Spamassassin, amavis et clamav. Nous aurons recourt à une base de données de type MySQL. Même si vous ne gérerez qu’un seul domaine, virtualiser les utilisateurs et les domaines n’est pas plus consommateur de ressources : MySQL (ou tout autre serveur de bases de données, j’aurai pu traiter de postgreSQL s’il ne me manquait pas de l’expérience) sera installé tôt ou tard, autant l’utiliser tout de suite. Et si par la suite vous acquérez un autre domaine et que vous vouliez proposer un service mail pour ce domaine, vous n’aurez pas de migration fastidieuse à effectuer.

Lorsque debconf vous demandera un mot de passe pour MySQL (et par extension, chaque fois que vous devrez saisir un mot de passe dans les prochains articles), vous devriez considérer utiliser un générateur de mot de passe. En utilisant un tel outil, vous pourrez générer des mots de passe complexes, de la longueur et de la complexité que vous voulez.

Sous debian donc, on installe les paquets suivants :

apt-get install amavisd-new arj bzip2 cabextract clamav clamav-freshclam clamav-daemon cpio dovecot-imapd gzip lha mysql-server p7zip pax postfix postfix-mysql postfix-pcre ripole rpm tar unrar-free unzip xz-utils zip zoo

Outre postfix, dovecot, l’anti-virus et l’anti-spam, on installe également quelques utilitaires appelés par amavis/clamav pour analyser les pièces jointes aux futurs mails qui seront envoyés ou reçus par votre serveur. On passe ensuite à la configuration de MySQL.

MySQL

debconf vous a probablement demandé de choisir un mot de passe pour l’utilisateur root (celui de MySQL). Vous devez maintenant créer un nouvel utilisateur pour la première base de données que nous allons créer, et qui sera exploitée par notre serveur mail.

mysql -u root -pVotreMotDePasse

Saisissez alors les commandes suivantes, en remplaçant NouveauMotDePasse par un nouveau mot de passe, différent de celui de root (là encore, pensez à utiliser le générateur de mots de passe) :

CREATE USER 'MailServer'@'localhost' IDENTIFIED BY 'NouveauMotDePasse';
GRANT USAGE ON * . * TO 'MailUser'@'localhost' IDENTIFIED BY 'NouveauMotDePasse';
CREATE DATABASE IF NOT EXISTS `MailServer` ;
GRANT ALL PRIVILEGES ON `MailServer` . * TO 'MailServer'@'localhost';

Nous avons créé un nouvel utilisateur nommé MailServer, et une base de données dans laquelle il a tout privilège. Créons ensuite la structure :

USE MailServer;

CREATE TABLE `access_sender` (
 `source` varchar(128) CHARACTER SET utf8 NOT NULL DEFAULT '',
 `access` varchar(128) CHARACTER SET utf8 NOT NULL DEFAULT '',
 `created` datetime NOT NULL,
 `modified` datetime NOT NULL,
 `active` tinyint(1) NOT NULL DEFAULT '1',
 UNIQUE KEY `source` (`source`)
 ) ENGINE=MyISAM DEFAULT CHARSET=latin1 COMMENT='Virtual Sender Restrictions';
CREATE TABLE `aliases` (
 `id` int(11) NOT NULL AUTO_INCREMENT,
 `source` varchar(255) CHARACTER SET utf8 NOT NULL,
 `destination` varchar(255) CHARACTER SET utf8 NOT NULL,
 PRIMARY KEY (`id`)
 ) ENGINE=MyISAM DEFAULT CHARSET=latin1;
CREATE TABLE `domains` (
 `id` int(11) NOT NULL AUTO_INCREMENT,
 `name` varchar(255) CHARACTER SET utf8 NOT NULL,
 PRIMARY KEY (`id`)
 ) ENGINE=MyISAM DEFAULT CHARSET=latin1;
CREATE TABLE `users` (
 `id` int(11) NOT NULL AUTO_INCREMENT,
 `email` varchar(255) CHARACTER SET utf8 NOT NULL,
 `password` varchar(32) CHARACTER SET utf8 NOT NULL,
 PRIMARY KEY (`id`)
 ) ENGINE=MyISAM DEFAULT CHARSET=latin1;
quit;

Nous avons créé respectivement la table qui contiendra les adresses emails toujours autorisées à nous envoyer quelque chose, quelle que soit la politique de filtrage de notre postfix, la table contenant les futurs alias, celle contenant les domaines et enfin celle qui contiendra nos utilisateurs. La base de données est configurée, nous pouvons passer à la suite.

Postfix

Pour que Postfix utilise la base de données que l’on vient de créer, il faut créer quelques fichiers de configuration que nous allons placer dans le répertoire /etc/postfix/mysql :

/etc/init.d/postfix stop
mkdir /etc/postfix/mysql

Créez ensuite les fichiers suivants (n’oubliez pas de renseigner à chaque fois la variable password avec le mot de passe que vous avez attribué à l’utilisateur MailServer) :

cd /etc/postfix/mysql
nano alias.cf

user = MailServer
password =
hosts = 127.0.0.1
dbname = MailServer
query = SELECT destination FROM aliases WHERE source='%s'

nano domains.cf

user = MailServer
password =
hosts = 127.0.0.1
dbname = MailServer
query = SELECT 1 FROM domains WHERE name='%s'

nano email2email.cf

user = MailServer
password =
hosts = 127.0.0.1
dbname = MailServer
query = SELECT email FROM users WHERE email='%s'

nano maps.cf

user = MailServer
password =
hosts = 127.0.0.1
dbname = MailServer
query = SELECT 1 FROM users WHERE email='%s'

nano senders_whitelist.cf

user = MailServer
password = B3v2sAD6A3mYeFDf
hosts = 127.0.0.1
dbname = MailServer
query = SELECT access FROM access_sender WHERE source='%s' AND active = '1'

Nous venons simplement de créer les fichiers permettant de communiquer avec les tables créées précédemment. Modifions ensuite la configuration principale de postfix, à commencer par le fichier main.cf. Nous allons créer une nouvelle configuration en partant de rien, on va donc déplacer le fichier d’origine et en créer un nouveau :

cd ../
mv main.cf main.cf.orig
nano main.cf

Copiez-y ensuite la configuration suivante :

mynetworks = 127.0.0.0/8

# Dovecot settings
virtual_transport = dovecot
dovecot_destination_recipient_limit = 1

# MySQL settings
virtual_mailbox_domains = mysql:/etc/postfix/mysql/domains.cf
virtual_mailbox_maps = mysql:/etc/postfix/mysql/maps.cf
virtual_alias_maps = mysql:/etc/postfix/mysql/alias.cf,mysql:/etc/postfix/mysql/email2email.cf

# SASL
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes

# TLS
smtp_tls_CAfile = /scripts/certificate_authority/ca.crt
smtpd_tls_CAfile = /scripts/certificate_authority/ca.crt
smtpd_tls_cert_file = /scripts/certificate_authority/exemple.fr.crt
smtpd_tls_key_file = /scripts/certificate_authority/exemple.fr.key
smtpd_tls_received_header = yes
tls_random_source = dev:/dev/urandom
smtp_tls_security_level = may
smtpd_tls_security_level = may
smtp_use_tls = yes
smtpd_use_tls = yes
smtpd_tls_auth_only = no
#smtpd_tls_wrappermode = yes
smtpd_tls_loglevel = 1

# Filtering
content_filter = smtp-amavis:[127.0.0.1]:10024
receive_override_options = no_address_mappings

# Restrictions
unknown_address_reject_code = 554
unknown_hostname_reject_code = 554
unknown_client_reject_code = 550
unverified_sender_reject_code = 554
smtpd_helo_required = yes
strict_rfc821_envelopes = yes

smtpd_recipient_restrictions =
    reject_non_fqdn_sender,
    reject_unknown_sender_domain,
    reject_non_fqdn_recipient,
    reject_unknown_recipient_domain,
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination,
    check_helo_access pcre:/etc/postfix/helo_checks.pcre,
    reject_invalid_helo_hostname,
    reject_non_fqdn_helo_hostname,
    check_sender_access mysql:/etc/postfix/mysql/senders_whitelist.cf,
    reject_rbl_client zen.spamhaus.org

Il faut créer le fichier helo_checks.pcre. En utilisant les expressions rationnelles, cela permettra à postfix d’opérer un filtrage sur la commande helo du protocole SMTP.

nano helo_checks.pcre

/^localhost$/            550 Don’t use localhost
/^(base\.)?(exemple\.fr|exemple2\.fr)$/ 550 Don’t use my own domain/hostname
/^\[?88\.190\.15\.133\]?$/
   550 Spammer comes to me \
       Greets me with my own IP \
       His mail I shall not see.
/^[0-9.-]+$/
   550 Your software is not RFC 2821 compliant: \
       EHLO/HELO must be a domain or an \
       address-literal (IP enclosed in brackets)

On modifie ensuite le fichier master.cf :

nano master.cf

Dé-commentez la ligne (située en début du fichier) :

smtps inet n - - - - smtpd

Et rajoutez les lignes suivantes :

dovecot unix - n n - - pipe
    flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -d ${recipient}

smtp-amavis unix - - n - 2 smtp
    -o smtp_data_done_timeout=1200
    -o smtp_send_xforward_command=yes
    -o disable_dns_lookups=yes
    -o max_use=20

127.0.0.1:10025 inet n - n - - smtpd
    -o content_filter=
    -o smtpd_restriction_classes=
    -o smtpd_delay_reject=no
    -o smtpd_client_restrictions=permit_mynetworks,reject
    -o smtpd_helo_restrictions=
    -o smtpd_sender_restrictions=
    -o smtpd_recipient_restrictions=permit_mynetworks,reject
    -o smtpd_data_restrictions=reject_unauth_pipelining
    -o smtpd_end_of_data_restrictions=
    -o mynetworks=127.0.0.0/8
    -o smtpd_error_sleep_time=0
    -o smtpd_soft_error_limit=1001
    -o smtpd_hard_error_limit=1000
    -o smtpd_client_connection_count_limit=0
    -o smtpd_client_connection_rate_limit=0
    -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks
    -o local_header_rewrite_clients=

Ces lignes servent à interfacer dovecot et amavis avec postfix. Il nous reste encore à créer les certificats.

/scripts/certificate_authority/make_request postfix mail.exemple.fr

Signez ensuite le certificat :

/scripts/certificate_authority/sign_request postfix exemple.fr

La configuration de postfix étant terminée, on s’occupe des filtres.

Filtres

/etc/init.d/amavis stop
/etc/init.d/clamav-daemon stop
/etc/init.d/clamav-freshclam stop
adduser clamav amavis
adduser amavis clamav

On édite ensuite la configuration de amavis :

nano /etc/amavis/conf.d/15-content_filter_mode

Dé-commentez les lignes dans ce fichier pour qu’il ressemble à ceci :

use strict;

@bypass_virus_checks_maps = (
   \%bypass_virus_checks, \@bypass_virus_checks_acl, \$bypass_virus_checks_re);

@bypass_spam_checks_maps = (
   \%bypass_spam_checks, \@bypass_spam_checks_acl, \$bypass_spam_checks_re);

1;  # ensure a defined return

Puis :

nano /etc/amavis/conf.d/20-debian_defaults

Vers la ligne 68, assurez-vous d’avoir les directives de configuration suivantes :

$final_virus_destiny      = D_DISCARD;  # (data not lost, see virus quarantine)
$final_banned_destiny     = D_BOUNCE;   # D_REJECT when front-end MTA
$final_spam_destiny       = D_BOUNCE;
$final_bad_header_destiny = D_PASS;     # False-positive prone (for spam)

On bloque ainsi totalement les virus, mais on laisse passer le spam (qui sera tagué par la suite) pour éviter de supprimer du courrier légitime.

On continue :

nano /etc/amavis/conf.d/50-user

use strict;

#
# Place your configuration directives here.  They will override those in
# earlier files.
#
# See /usr/share/doc/amavisd-new/ for documentation and examples of
# the directives you can use in this file
#

$sa_spam_subject_tag = '***** SPAM ***** ';
$spam_quarantine_to  = undef;
$sa_tag_level_deflt  = undef;
$final_spam_destiny=D_PASS;

@lookup_sql_dsn = (
    ['DBI:mysql:database=MailServer;host=127.0.0.1;port=3306',
     'MailServer',
     'MotDePasse']);

$sql_select_policy = 'SELECT name FROM domains WHERE CONCAT("@",name) IN (%k)';

#------------ Do not modify anything below this line -------------
1;  # ensure a defined return

On peut maintenant démarrer les services :

/etc/init.d/amavis start
/etc/init.d/clamav-daemon start
/etc/init.d/clamav-freshclam start

Dovecot

/etc/init.d/dovecot stop
cd /etc/dovecot

Configurons tout d’abord la connexion au serveur MySQL :

mv dovecot-sql.conf dovecot-sql.conf-orig
nano dovecot-sql.conf

driver = mysql
connect = host=127.0.0.1 dbname=MailServer user=MailServer password=MotDePasse
default_pass_scheme = PLAIN-MD5
password_query = SELECT email AS user, password FROM users WHERE email='%u'

Comme d’habitude, pensez à changer le mot de passe, et mettez celui de l’utilisateur MySQL MailServer. Enregistrez puis fermez, avant de modifier la configuration principale :

mv dovecot.conf dovecot.conf-orig
nano dovecot.conf

base_dir = /var/run/dovecot
protocols = imaps managesieve

ssl = yes
ssl_cert_file = /scripts/certificate_authority/dovecot/mail.exemple.fr.crt
ssl_key_file = /scripts/certificate_authority/dovecot/mail.exemple.fr.key
ssl_key_password = MotDePasse

mail_location = maildir:/var/vmail/%d/%n/Maildir

mail_uid = vmail
mail_gid = vmail

mail_privileged_group = mail

protocol imap {
}

protocol managesieve {
    login_executable = /usr/lib/dovecot/managesieve-login
    mail_executable = /usr/lib/dovecot/managesieve
}

protocol lda {
    postmaster_address = postmaster@exemple.fr
    auth_socket_path = /var/run/dovecot/auth-master
    mail_plugins = sieve
}

auth_executable = /usr/lib/dovecot/dovecot-auth

auth default {
    mechanisms = plain login

    passdb sql {
        args = /etc/dovecot/dovecot-sql.conf
    }

    userdb static {
        args = uid=5000 vid=5000 home/var/vmail/%d/%n
    }

    user = root

    socket listen {
        master {
            path = /var/run/dovecot/auth-master
            mode = 0600

            user = vmail
            group = vmail
        }
        client {
            path = /var/spool/postfix/private/auth
            mode = 0660
            user = postfix
            group = postfix
        }
    }
}

plugin {
    sieve=/var/vmail/%d/%n/Maildir/sieve/.dovecot.sieve
    sieve_dir=/var/vmail/%d/%n/Maildir/sieve
    sieve_global_path = /etc/sieve/sieve.global
}

Lorsque nous allons générer le certificat et la clé à utiliser avec dovecot, vous aurez la possibilité de créer une clé sans mot de passe. Si vous choisissez de créer une clé sans mot de passe, commentez la ligne ssl_key_password = MotDePasse. Dans le cas contraire, indiquez le mot de passe utilisé lors de la génération du certificat.

Quelques répertoires vont devoir être créés :

mkdir /etc/sieve
mkdir /var/vmail

On génère les certificats :

/scripts/certificate_authority/make_request dovecot mail.exemple.fr
/scripts/certificate_authority/sign_request dovecot mail.exemple.fr

On créé ensuite l’utilisateur vmail :

addgroup vmail --gid 5000
adduser --system --disabled-password --no-create-home --disabled-login --uid 5000 --gid 5000 vmail
chown -R vmail:vmail /var/vmail

On peut désormais redémarrer dovecot :

/etc/init.d/dovecot restart

Nous avons configuré dovecot pour utiliser le plugin sieve/managesieve. Cela nous permettra plus tard de mettre en place des filtres pour la messagerie.

Créons tout de même le fichier de configuration de base pour sieve, dont le rôle va être simplement de déplacer le spam dans le bon répertoire :

nano /etc/sieve/sieve.global

require ["fileinto"];
# rule:[Spam]
if header :contains "Subject" "***** SPAM *****"
{
    fileinto "Spam";
}

Quelques tests

Installez le paquet telnet si vous ne l’avez pas déjà :

apt-get install telnet
telnet localhost 25
ehlo exemple.fr
quit

Vous devriez avoir une sortie console qui ressemble à ceci :

Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 minerva.localdomain ESMTP Postfix
ehlo exemple.fr
250-minerva.localdomain
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS
250-AUTH PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

Procédez de même avec le port 465, la sortie doit être la même.

Pour tester le serveur IMAP, nous devons créer un premier domaine, puis un premier utilisateur du domaine :

mysql -u root -pMotDePasse

USE MailServer;
INSERT INTO domains (name) VALUES ('exemple.fr');
INSERT INTO users (email, password) VALUES ('test@exemple.fr', MD5('MotDePasse'));
quit;

On peut ensuite tester le serveur IMAP :

openssl s_client -connect localhost:993

La dernière ligne affichée devrait ressembler à ceci :

* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE AUTH=PLAIN AUTH=LOGIN] Dovecot ready.

Suite à quoi, écrivez :

A LOGIN test@exemple.fr MotDePasse

La fin de la ligne suivante devrait afficher « Logged in ». Concluez la session avec :

a5 LOGOUT

Nous testerons plus tard les anti-virus et anti-spam. Pour l’heure, nous avons une dernière chose à régler.

Firewall

nano /scripts/firewall

Entre les lignes :

##### Configuration personnalisée #####

Et :

##### Fin : Configuration personnalisée #####

Rajoutez les lignes suivantes :

${IPT} -A SERVICES -p tcp --dport 25 -j ACCEPT
${IPT} -A SERVICES -p tcp --dport 465 -j ACCEPT

Ce sont les deux ports à ouvrir pour que votre serveur SMTP puisse communiquer avec l’extérieur (et vice-versa).

${IPT} -A SERVICES -p tcp --dport 993 -j ACCEPT

DNS

Dernière étape de l’installation de notre serveur mail, la modification de la configuration de notre serveur DNS pour sa prise en compte. On édite donc le fichier de définition de notre zone :

nano /etc/bind/db.exemple.fr

Et on rajoute à la fin (sans oublier de modifier l’identifiant de l’enregistrement !) :

		IN	MX	10	mail.exemple.fr.
mail		IN	A		1.1.1.1

Et on redémarre bind :

/etc/init.d/bind9 restart

C’est aussi simple que ça !

La prochaine étape consistera à installer un serveur web sécurisé, et quelques applications utiles, dont un client de messagerie pour jouer avec le serveur mail que l’on vient d’installer.

Lire la Suite »]]> J’avais initialement prévu d’aborder dans un troisième article la configuration d’un serveur mail, mais il fallait d’abord que j’explique comment mettre en place une autorité de certification, puisque nous allons nous en servir dans la configuration du serveur mail, mais aussi pour bien d’autres services que nous verrons ultérieurement.

À l’issue de cet article, vous aurez à disposition une série de scripts qui vous permettront de mettre rapidement et facilement en place des certificats pour tous types d’applications.

L’autorité de certification et les certificats vous permettront de chiffrer les données qui vont transiter sur votre cloud personnel. Ainsi, si une personne malintentionnée cherchait à espionner ce qui transite entre votre propre machine et votre serveur, elle ne pourrait pas exploiter les données qu’elle récolterait. C’est une solution fiable, même si tout chiffrement peut être « cassé ». Il faut simplement garder à l’esprit que vous n’êtes pas une banque, et que les données que vous allez stocker sur votre serveur n’ont de valeur que pour vous. Personne ne cherchera donc à passer des semaines ou des mois à casser le chiffrement de vos certificats…

Créons tout d’abord un répertoire dédié à nos scripts :

mkdir -p /scripts/certificate_authority

Vérifions ensuite que nous disposons bien du paquet nécessaire :

apt-get install openssl

Nous allons créer les premiers certificats, matérialisant l’autorité de certification. Les certificats spécifiques à certains services seront signés par cette autorité. Pour commencer, on va se créer un fichier de configuration personnalisé :

cp /etc/ssl/openssl.cnf /scripts/certificate_authority/

On édite ce fichier pour y modifier les variables suivantes :

• Dans la catégorie [ CA_default ], mettez les valeurs suivantes :

dir             = /scripts/certificate_authority
certs           = $dir/
crl_dir         = $dir/
database        = $dir/index.txt

new_certs_dir   = $dir/

certificate     = $dir/ca.crt
serial          = $dir/current_serial
crlnumber       = $dir/current_crl
crl             = $dir/crl.pem
private_key     = $dir/ca.key
RANDFILE        = $dir/.rand

• Dans la catégorie [ req_distinguished_name ], renseignez les valeurs suivantes :

• countryName_default
• stateOrProvinceName_default
• localityName_default
• 0.organizationName_default
• emailAddress_default

Enregistrez puis fermez ce fichier. On va ensuite créer le fichier create_ca, qui aura pour but de créer l’autorité de certification. L’autorité de certification n’est à créer qu’une seule fois, mais le fait de créer un script pour le faire permettra, en cas de besoin, de retrouver les commandes nécessaires. À noter que nous allons créer un certificat dont la validité est de 10 ans (3650 jours).

nano create_ca

#!/bin/bash

base=`dirname $0`

echo "Étape 1 : Création de la clé"
openssl genrsa -des3 -out "$base/ca.key" 1024

echo "Étape 2 : Génération de la demande de certificat"
openssl req -config "$base/openssl.cnf" -new -key "$base/ca.key" -out "$base/ca.csr"

echo "Étape 3 : Génération du certificat"
openssl x509 -days 3650 -signkey "$base/ca.key" -in "$base/ca.csr" -req -out "$base/ca.crt"

chmod 0400 ca.key

chmod 700 create_ca

Cette dernière commande nous assure que personne à part root ne peut exécuter ce fichier. Ce que nous allons faire immédiatement :

./create_ca

Après vous avoir demandé un mot de passe (qu’il est impératif de renseigner), quelques questions vont vous être posées. La plupart contient déjà les réponses pré-replies dans le fichier openssl.cnf que nous avons édité plus tôt. Seule la variable Organizational Unit Name est à spécifier (mettez ce que vous voulez, par exemple « Certificate Authority« ), et la variable Common Name, qui devrait contenir votre nom de domaine principal.

Une fois la commande exécutée et les variables spécifiées, trois nouveaux fichiers ont été créés dans le répertoire de travail (/scripts/certificate_authority) : ca.csr (la demande de certificat), ca.crt (le certificat principal) et ca.key (la clé privée). On peut désormais créer de nouveaux certificats, à l’aide d’un nouveau script :

nano make_request

#!/bin/bash

app=$1
domain=$2
base=`dirname $0`

if [ "$app" == "" ]
then
        echo "Vous devez spécifier un nom d'application ou de service"
        exit
fi

if [ "$domain" == "" ]
then
        echo "Vous devez spécifier un nom de domaine"
        exit
fi

if [ ! -d "$base/$app" ]
then
        mkdir "$base/$app"
fi

echo "Étape 1 : Création de la clé"
openssl genrsa -des3 -out "$base/$app/$domain.key" 1024

echo "Étape 2 : Création de la demande de certificat"
openssl req -config "$base/openssl.cnf" -new -key "$base/$app/$domain.key" -out "$base/$app/$domain.csr"

echo "Souhaitez-vous créer une clé sans mot de passe ? (o/n) [n]"

read answer

if [ $answer = o -o $answer = O ]
then
        cp "$base/$app/$domain.key" "$base/$app/$domain.key-withpass"
        openssl rsa -in "$base/$app/$domain.key-withpass" -out "$base/$app/$domain.key"
        chmod 0440 "$base/$app/$domain.key-withpass"
fi

chmod 0440 "$base/$app/$domain.key"

chmod +x ./make_request

L’objectif de ce script va être de générer une demande de certificat pour une application donnée et un domaine donné. Cela nous permettra de générer des certificats différents selon les applications et les domaines, mais il est tout à fait possible (bien que déconseillé) de générer un seul certificat et de s’en servir dans toutes nos applications. Ce script s’utilisera de la manière suivante :

./make_request <application> <domaine>

Ce script va également nous permettre de créer des clés sans mot de passe, ce qui sera utile avec apache.

Créons ensuite le script qui va nous permettre de demander la signature d’une demande précédente :

nano sign_request

#!/bin/bash

app=$1
domain=$2
base=`dirname $0`
serial=0

if [ "$app" == "" ]
then
        echo "Vous devez spécifier un nom d'application ou de service"
        exit
fi

if [ "$domain" == "" ]
then
        echo "Vous devez spécifier un nom de domaine"
        exit
fi

if [ ! -d "$base/$app" ]
then
        echo "Aucun certificat n'a été généré pour l'application spécifiée"
        exit
fi

if [ ! -f "$base/$app/$domain.csr" ]
then
        echo "Aucun certificat n'a été généré pour le domaine spécifié"
        exit
fi

if [ -f "$base/current_serial" ]
then
        serial=`cat "$base/current_serial"`
fi

serial=$(($serial+1))

openssl x509 -req -days 3650 -in "$base/$app/$domain.csr" -CA "$base/ca.crt" -CAkey "$base/ca.key" -set_serial $serial -out "$base/$app/$domain.crt"

echo "$serial" > "$base/current_serial"

echo "Souhaitez-vous supprimer la requête initiale ? ($domain.csr) (o/n) [o]"

read answer

if [ "$answer" != "n" -a "$ans" != "N" ]
then
        rm "$base/$app/$domain.csr"
fi

chmod 700 sign_request

La syntaxe est la même que précédemment :

./sign_request <application> <domaine>

La signature du certificat va générer un fichier portant l’extension .crt : c’est celui-ci qui sera notamment utilisé à travers les applications.

La procédure pour créer un certificat valide est donc la suivante. Nous admettrons pour l’exemple que nous travaillons avec apache.

./make_request apache exemple.fr
./sign_request apache exemple.fr

Cela aura pour conséquence de créer un répertoire apache dans le répertoire /scripts/certificate_authority, qui contiendra vos certificats, demandes, et clés spécifiques à apache.

Vous disposez désormais d’un ensemble complet d’outils pour générer facilement les certificats dont vous aurez besoin plus tard, et notamment lors de la mise en place du serveur mail, prochaine étape de la création de votre cloud personnel.

Lire la Suite »]]> Le deuxième article de cette nouvelle rubrique traite logiquement de la mise en place d’un serveur DNS. À moins que vous n’ayez recours à l’outil de gestion de vos DNS proposé par votre registrar et qu’il ne vous bride pas, vous devrez passer par l’étape du serveur DNS, d’autant qu’il nous permettra par la suite de faire bien d’autres choses que simplement faire pointer un domaine sur une IP…

Nous utiliserons le serveur bind. Nous allons tout d’abord l’installer sur le serveur principal en tant que maître. Si vous disposez d’un second serveur, vous pourrez le configurer en tant qu’esclave pour assurer la continuité du service.

Pare-feu

Tout d’abord, reprenons le script de pare-feu que nous avons configuré précédemment.

nano /scripts/firewall

Entre les lignes :

##### Configuration personnalisée #####

Et :

##### Fin : Configuration personnalisée #####

Rajoutez les lignes suivantes :

${IPT} -A SERVICES -p tcp --dport 53 -j ACCEPT
${IPT} -A SERVICES -p udp --dport 53 -j ACCEPT

Nous ouvrons donc le port 53 en TCP et en UDP. Normalement, seul le protocole UDP est utilisé pour les requêtes, mais le protocole TCP est utilisé également pour les transferts de zones dont nous aurons besoin plus tard. Il est donc important d’ouvrir les connexions aux deux types de protocoles, à moins que vous ne configuriez pas un serveur esclave. Nous pourrions également spécifier directement l’adresse du serveur esclave afin d’éviter toute demande de transfert directement depuis iptables :

${IPT} -A SERVICES -p tcp --dport 53 -s 2.2.2.2 -j ACCEPT
${IPT} -A SERVICES -p udp --dport 53 -j ACCEPT

Serveur maître

Pour installer bind, rien de plus simple :

apt-get install bind9 dnsutils

Le paquet dnsutils contient notamment les outils nslookup et dig, qui nous serviront par la suite à tester notre installation.

Rendez-vous dans le répertoire de configuration de bind :

cd /etc/bind
/etc/init.d/bind9 stop

On créé le fichier le définition de notre domaine :

nano db.exemple.fr

$TTL	86400
@	IN	SOA	ns.exemple.fr. postmaster.exemple.fr. (
		     2012020501
			     2D		; Refresh
			    15M		; Retry
			     3W		; Expire
			  86400 )	; Negative Cache TTL

			IN	NS		ns.exemple.fr.
			IN	NS		ns2.exemple.fr.

			IN	A		1.1.1.1

ns			IN	A		1.1.1.1
ns2			IN	A		2.2.2.2

Quelques explications s’imposent. Dans la ligne relative au SOA, on déclare le serveur DNS autoritaire pour la zone (ns.exemple.fr) et l’adresse email du responsable (postmaster.exemple.fr, le « @ » de l’adresse étant remplacé par un « . »). Ensuite, on attribue un numéro de série au fichier ; ce numéro ne s’invente pas : il s’agit de la date (au format YYYYMMDD) suivi d’un nombre compris entre 00 et 99. Pour plus de clarté, on va appeler ce nombre la « clé ». Si vous disposez de plusieurs domaines, vous pouvez utiliser le premier chiffre de la clé comme identifiant pour un domaine particulier (par exemple, « j’attribuerai toujours un 1 au domaine exemple.fr, et un 2 au domaine exemple2.fr« ), tandis que le second chiffre de la clé vous servira à indenter les modifications survenues dans ce fichier pour le jour donné.

Par exemple, vous faites 4 modifications sur le fichier db.exemple.fr, et 7 sur le fichier db.exemple2.fr, en date d’aujourd’hui. Vous pouvez attribuer les numéros de série suivants à vos fichiers : 2012020514 et 2012020527.

Les valeurs suivantes (refresh, retry, etc.) devraient convenir à la majorité des situations.

Nous définissons ensuite les deux serveurs DNS associés au nom de domaine : ns.exemple.fr. et ns2.exemple.fr.

Ensuite, nous indiquons que le serveur principal a pour adresse IP 1.1.1.1, puis nous associons les adresses 1.1.1.1 et 2.2.2.2 aux deux serveurs de noms. Une fois que vous avez adapté cet exemple à votre propre domaine, vous pouvez enregistrer et fermer.

Théoriquement, dans une installation de base de bind sur une debian stable, le fichier named.conf contient la ligne suivante :

include "/etc/bind/named.conf.local";

Si ce n’est pas le cas, rajoutez-là :

echo "include \"/etc/bind/named.conf.local\";" >> named.conf

Et modifiez le fichier named.conf.local :

nano named.conf.local

Ce fichier va contenir les directives de configuration pour un domaine particulier, en l’occurrence, exemple.fr (et/ou exemple2.fr). C’est une bonne pratique de configuration à laquelle passe la majorité des applications, cela permet de clarifier les choses, et de s’y retrouver facilement.

Mettez donc le contenu suivant dans ce fichier :

zone "exemple.fr" {
    type master;
    file "/etc/bind/db.exemple.fr";
};

On défini notre instance de bind comme étant maître pour ce domaine, et on lui indique le fichier de configuration correspondant. Enregistrez et fermez ce fichier une fois modifié.

Redémarrez ensuite bind, pour procéder à quelques tests :

/etc/init.d/bind9 restart
nslookup exemple.fr

Vous devriez obtenir la sortie suivante :

Server: 127.0.0.1
Address: 127.0.0.1#53
Name: exemple.fr
Address: 1.1.1.1

Vous noterez qu’à cause de la propagation des DNS, votre domaine n’est peut être pas encore disponible depuis l’extérieur. N’hésitez pas à tester (en utilisant la même commande) régulièrement depuis une machine qui n’héberge pas le serveur bind.

Si la commande précédente vous retourne une sortie similaire, c’est que votre domaine est correctement configuré (du point de vue de bind en tout cas). En l’état actuel des choses, bind devrait donc être en mesure de répondre à des requêtes portant sur votre domaine, bien qu’encore aucun domaine « utile » ne soit créé.

Serveur esclave

Pour faire fonctionner deux instances de bind sur le modèle de maître/esclave, on commence par compléter un peu la configuration du serveur maître. On reste donc sur la même machine, pour créer une clé de transfert :

dnssec-keygen -a HMAC-MD5 -b 512 -n HOST <localhost>.exemple.fr.

dnssec-keygen est un outil livré avec bind. Grâce à la commande suivante, on génère une clé en utilisant l’algorithme HMAC-MD5, d’une longueur de 512 bits, pour un hôte particulier (-n HOST), en l’occurrence, celui indiqué à la fin. Remplacez <localhost> par le nom d’hôte du serveur. Par exemple, j’ai appelé mon serveur « minerva », sur le domaine ingnu.fr. La commande qui s’applique à mon cas devient donc :

dnssec-keygen -a HMAC-MD5 -b 512 -n HOST minerva.ingnu.fr.

On génère une clé pour un hôte donné, mais dnssec-keygen permet bien d’autres choses que nous n’utiliserons pas ici. Notamment, vous pouvez choisir un algorithme différent, ou créer une clé pour toute une zone. Pour l’heure, nous souhaitons avoir la possibilité de transférer de manière sécurisée les données de zones (dans notre exemple, le fichier db.exemple.fr) de notre serveur maître vers le serveur esclave que nous configurerons plus tard. Cette commande est donc suffisante pour le moment.

A l’issue de l’exécution de cette commande (qui peut durer une vingtaine de secondes), deux nouveaux fichiers ont été créés. Ils commencent par la lettre K majuscule, et portent respectivement l’extension .key et .private. Le premier fichier contient une ligne qu’il est possible de rajouter dans un fichier de zone, tandis que le second contient quelques détails sur la création de la clé. Nous n’utiliserons dans notre cas précis aucun des deux dans son état actuel. Cependant, il peut être utile de les conserver pour un usage ultérieur.

La seule chose qui nous intéresse est la clé en elle-même qui figure dans les deux fichiers. Utilisez la commande cat sur le fichier .private, et copiez la clé qui apparaîtra. Créez ensuite le fichier transfer.conf :

nano transfer.conf

key "TRANSFER" {
    algorithm hmac-md5;
    secret "la clé que vous avez copié";
};

server 2.2.2.2 {
    keys {
        TRANSFER;
    };
};

Dans ce fichier, nous ajoutons une clé au « trousseau » de bind, qui ne sera destinée qu’au transfert des zones entre le maître et l’esclave. Si un cas se présente où nous devrons diffuser d’autres clés, nous en génèrerons de nouvelles, pour éviter toute interférence.

Ensuite, nous affectons cette clé au serveur esclave, 2.2.2.2.

Incluez ce fichier à votre configuration, puis modifiez le fichier named.conf.local :

echo "include \"/etc/bind/transfer.conf\" >> /etc/bind/named.conf
nano named.conf.local

zone "exemple.fr" {
    type master;
    file "/etc/bind/db.exemple.fr";
    allow-transfer { 2.2.2.2; };
};

Nous avons rajouté la ligne allow-transfer { 2.2.2.2; }; qui nous permet d’éviter que n’importe qui puisse transférer nos zones sur son serveur. Redémarrez bind :

/etc/init.d/bind9 restart

Désormais, lorsque le serveur maître redémarrera, il notifiera automatiquement le(s) serveur(s) esclave(s) de tout changement, et initiera le transfert des zones de manière sécurisée.

Passons maintenant à la configuration du serveur esclave à proprement parlé. Sur la machine qui hébergera ce serveur, installez bind :

apt-get install bind9 dnsutils

Nous avons créé le fichier transfer.conf sur le serveur maître. Le même fichier doit être créé sur la machine esclave, avec une petite nuance.

cd /etc/bind
/etc/init.d/bind9/stop
nano transfer.conf

key "TRANSFER" {
    algorithm hmac-md5;
    secret "la clé que vous avez copié";
};

server 1.1.1.1 {
    keys {
        TRANSFER;
    };
};

Vous noterez qu’il s’agit exactement du même fichier, y compris la même clé, mais que l’adresse IP de la clause server change. Dans la configuration du serveur esclave, c’est l’adresse IP du serveur maître qu’il faut indiquer. Ensuite, comme pour la configuration du serveur maître, on ajouter ce fichier à la configuration de bind :

echo "include \"/etc/bind/transfer.conf\" >> /etc/bind/named.conf

Modifions ensuite le fichier named.conf.local pour y ajouter la configuration de votre (vos) domaine(s) :

zone "exemple.fr" {
    type slave;
    file "/var/cache/bind/db.exemple.fr";
    masters { 1.1.1.1; };
    allow-notify { 1.1.1.1; };
};

Nous indiquons ici que le fichier de zone db.exemple.fr, une fois transféré, sera stocké dans le dossier /var/cache/bind, qui devrait déjà être créé. Si ce n’est pas le cas, il faut le créer, et donc tous les cas, lui attribuer les bons droits :

mkdir -p /var/cache/bind
chown -R bind:bind /var/cache/bind
chmod -r 644 /var/cache/bind

Il suffit maintenant de redémarrer bind pour que les modifications soient prises en compte.

/etc/init.d/bind9 restart

Consultez immédiatement les journaux utilisés par bind :

tail -100 /var/log/syslog

Il se peut que vous y trouviez une erreur à propos de l’heure qui n’est pas synchronisée. Installez sur les deux serveurs le paquet ntpdate, puis synchronisez les horloges avant de redémarrer bind :

apt-get install ntpdate
ntpdate 0.fr.pool.ntp.org
/etc/init.d/bind9 restart

Testez maintenant votre serveur :

nslookup
> server 127.0.0.1
Default server: 127.0.0.1
Address: 127.0.0.1#53
> exemple.fr
Server: 127.0.0.1
Address: 127.0.0.1#53
Name: exemple.fr
Address: 1.1.1.1

Vous disposez désormais de l’une des pièces maîtresses de votre propre serveur. La configuration de base que nous avons mis en place aujourd’hui va être complétée et sécurisée au fil des articles à venir, pour qu’au final, vous disposiez d’une solution complète vous permettant de vous affranchir des services offerts par Google, Twitter, facebook et bien d’autres. Le serveur que nous allons monter avec ces articles va vous permettre de reprendre le contrôle de vos données. Alors à bientôt pour le prochain article, qui traitera de la deuxième pierre angulaire de votre Cloud personnel et Libre : le serveur mail.

Lire la Suite »]]> Je parle beaucoup sur ingnu du fait que Google c’est le mal, qu’il faut utiliser des alternatives libres, et que le Cloud, c’est de la merde. Pour être tout à fait cohérent, il me fallait proposer des articles traitant concrètement de la mise en place de ces alternatives, et c’est pour cela que j’ai créé la rubrique « Créer son propre cloud« , dont cet article constitue le premier maillon pour vous aider à construire votre serveur grâce aux Logiciels Libres.

Il y a quatre prérogatives : n’utiliser que des Logiciels Libres, assurer la confidentialité de vos données, assurer la sécurité de votre serveur, s’affranchir de tout service géré par une entreprise.

Nous considérerons que vous disposez déjà d’un système GNU/Linux, de préférence fraîchement installé, brut de décoffrage. Je me baserai sur un système Debian GNU/Linux (que je maîtrise bien mieux que les autres), il faudra alors adapter certaines de mes notes à votre cas précis (notamment en ce qui concerne les commandes d’installation de paquets).

La toute première étape après l’installation du système d’exploitation est d’imposer une politique de sécurité stricte. Nous commençons donc par créer un script permettant la mise en place d’un pare-feu et qui s’exécutera à chaque démarrage de la machine.

mkdir /scripts
cd /scripts

Le répertoire /scripts que nous venons de créer contiendra un certains nombre de fichiers, que nous créerons au fil des articles. Dans un premier temps, nous ne créons que le script du firewall :

nano firewall

#!/bin/sh

IPT=/sbin/iptables
IF_EXT=eth0
IP_SSH=xxx.xxx.xxx.xxx

${IPT} -t mangle -F
${IPT} -t nat -F
${IPT} -F
${IPT} -t mangle -X
${IPT} -t nat -X
${IPT} -X
${IPT} -Z

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

${IPT} -P INPUT DROP
${IPT} -P OUTPUT ACCEPT
${IPT} -P FORWARD ACCEPT

${IPT} -A FORWARD -i lo -o lo -j ACCEPT
${IPT} -A INPUT -i lo -j ACCEPT
${IPT} -A OUTPUT -o lo -j ACCEPT

${IPT} -A INPUT -p tcp ! --syn -m state --state NEW,INVALID -j REJECT

${IPT} -N SPOOFED
${IPT} -N SERVICES

${IPT} -A SPOOFED -s 127.0.0.0/8 -j DROP
${IPT} -A SPOOFED -s 169.254.0.0/12 -j DROP
${IPT} -A SPOOFED -s 172.16.0.0/12 -j DROP
${IPT} -A SPOOFED -s 192.168.0.0/16 -j DROP
${IPT} -A SPOOFED -s 10.0.0.0/8 -j DROP

${IPT} -A INPUT -p icmp --icmp-type echo-request -j ACCEPT

${IPT} -A SERVICES -p tcp --dport 22 -s ${IP_SSH} -j ACCEPT

##### Configuration personnalisée #####

##### Fin : Configuration personnalisée #####

${IPT} -A OUTPUT -j ACCEPT
${IPT} -A INPUT -m state --state ESTABLISH,RELATED -j ACCEPT
${IPT} -A INPUT -j SPOOFED
${IPT} -A INPUT -i ${IF_EXT} -j SERVICES

#################################
# Anti spam                     #
#################################

FILE="/tmp/drop.lasso"
URL="http://www.spamhaus.org/drop/drop.lasso"

[ -f $FILE ] && /bin/rm -f $FILE || :
cd /tmp
wget $URL
blocks=$(cat $FILE  | egrep -v '^;' | awk '{ print $1}')
${IPT} -N droplist

for ipblock in $blocks
do
        ${IPT} -A droplist -s $ipblock -j LOG --log-prefix "DROP List Block"
        ${IPT} -A droplist -s $ipblock -j DROP
done

${IPT} -I INPUT -j droplist
${IPT} -I OUTPUT -j droplist
${IPT} -I FORWARD -j droplist

/bin/rm -f $FILE

Dans un premier temps, on défini quelques variables. La plus importante est IP_SSH, c’est votre adresse IP, l’adresse depuis laquelle vous allez vous connecter au serveur via ssh.

Ensuite, on purge les règles (pour pouvoir exécuter plusieurs fois le fichier sans que cela ne les alourdisse), on met en place une politique par défaut (rien ne doit pouvoir rentrer sans autorisation), on créé les chaînes SPOOFED et SERVICES qui vont nous permettre de séparer le trafic et de sécuriser les accès, on met en place des règles personnalisées (pour le moment, aucune), et on installe un blocage du SPAM en bonus.

Théoriquement, ce script est tout à fait utilisable tel quel. Au fil des articles, on ajoutera des directives spécifiques au niveau du commentaire « Configuration personnalisée ». On se servira de la chaîne SERVICES pour y affecter les services hébergés par notre machine.

Dans le cas extrême où vous vous retrouviez bloqué, incapable de vous connecter en ssh à votre serveur, essayez de voir si votre hébergeur vous offre la possibilité de passer par un KVM virtuel. Cela vous permettra de reprendre la main sur votre serveur le temps de configurer correctement le pare-feu. Et dans le cas où le KVM est indisponible, voyez si votre hébergeur vous propose de démarrer un système de secours. Pour information, les deux possibilités vous sont offertes chez online.

Il ne reste plus qu’à enregistrer, chmoder, exécuter, et patienter jusqu’au prochain article :

chmod +x firewall
./firewall

Lire la Suite »]]> Cela fait maintenant quelques temps que j’enquiquine mes followers sur social.ingnu.fr à propos de XMPP qui déconne sévèrement avec la release 1.0.1 de status.net : déconnections intempestives, mauvaise gestion de la file d’attente, etc.

La page de Jean-Baptiste Favre m’a permis de creuser un peu plus, bien que ne parlant pas de XMPP. Il aborde tout de même quelques directives de configuration à propos des files d’attente qui m’ont échappé, directives que j’ai adapté pour mieux coller (selon moi) à une debian et à placer dans le fichier config.php :

$config['daemon']['piddir'] = '/var/run/';
$config['daemon']['user'] = 'www-data';
$config['daemon']['group'] = 'www-data';

À cela, il faut rajouter les lignes relatives à XMPP :

addPlugin('xmpp', array(
    'user'=>'identifiant du robot',
    'server'=>'nom de domaine',
    'password'=>'mot de passe',
    'resource'=>'ce que vous voulez',
    'encryption'=>true,
));

Maintenant, l’étape la plus « difficile ». En l’état, vous pouvez être à peu près certain que ça ne marchera pas. Un contributeur au projet propose un patch, que vous pouvez télécharger ici. Enregistrez-le à la racine de votre instance de status.net et nommez-le par exemple statusnet.patch, puis saisissez les commandes suivantes :

sed -i "s#statusnet-1\.0\.1#\./#" statusnet.patch
patch -p1 < statusnet.patch

Normalement, tout devrait fonctionner à merveille désormais.

Lire la Suite »]]> Le Cloud, c’est de la merde, c’est une chose de laquelle je ne démordrai pas. Qu’il soit utilisé par des particuliers ou des entreprises, le Cloud est dangereux. Confier ses données à une entreprise  est suicidaire.

Par contre, créer son propre Cloud est une bonne chose. Mais il y a un problème de vocabulaire : rien ne distingue le Cloud de Google, d’Amazon ou de Microsoft, du Cloud auto-hébergé. Or cette distinction est capitale, parce que l’accessibilité des données hébergées est totalement différente.

Rappelons pour commencer que le Cloud est un terme utilisé pour désigner un ensemble d’applications et de services accessibles à travers Internet, avec une idée d’interopérabilité (généralement).

Ensuite se pose la question de la confidentialité de ces données : qui a le droit de les utiliser, qui y a accès. Officiellement bien sûr, les fournisseurs de Cloud disent ne pas y accéder, ni même pouvoir le faire. En réalité, impossible de savoir. L’auto-hébergement se montre alors comme une solution idéale, résolvant les problèmes de vie privée.

Cela consiste à installer et gérer soi-même son propre serveur. Par conséquent, cela demande de solides connaissances, pas tant pour installer les applications et les services que pour les sécuriser.

Première question : comment s’auto-héberger ?

Trois solutions se présentent : le serveur à la maison, le serveur mutualisé, le serveur dédié.

Le serveur à la maison présente l’intérêt majeur de ne pas vous coûter un rond, à l’exception bien sûr de l’achat initial du matériel, et de l’énergie consommée (qui est insignifiante, notamment quand on se paye une alimentation certifiée 80PLUS…). Vous choisissez sa puissance, vous installez exactement le matériel qu’il vous faut, et vous pouvez installer les applications dont vous avez besoin et seulement celles dont vous avez besoin. En contrepartie, vous êtes limités par votre bande passante.

Le serveur dédié vous coûte plus cher, mais le nombre d’offres présentes sur le marché est suffisant pour que vous trouviez une solution qui allie performances et faibles coûts. À titre informatif, j’héberge tous mes sites, un serveur mail complet avec MySQL, antivirus et anti-spam, une partie de mes fichiers personnels, un environnement de bureau LXDE, des dépôts git, etc. sur un Intel Core i3 540 et 2x1To en RAID1 sur une machine qui me coûte moins de 50€ par mois chez Online (filiale d’Illiad/FREE). Cerise sur le gâteaux : trafic illimité et bande passante de 1Gb/s. Par ailleurs, les systèmes d’installation (en tout cas chez Online) vous proposent un choix intéressant de systèmes d’exploitation : du Windows (pour les imberbes) à GNU/Linux (pour les barbus), en passant par des systèmes de virtualisation pré-configurés. En plus, en tant que serveurs dédiés, vous avez les pleins pouvoirs sur la machine. C’est comme si vous aviez votre propre serveur à la maison, sauf que vous payez tous les mois, pour disposer en plus de la possibilité de remplacer gratuitement du matériel défectueux, et un taux de disponibilité élevé de votre machine grâce aux systèmes de gestion d’alimentation mis en oeuvre. C’est, à mon sens, la solution idéale pour s’auto-héberger.

Enfin, le serveur mutualisé est entre les deux. La différence, c’est que vous n’êtes pas le maître absolu à bord, vous êtes dépendant des ressources qui vous sont octroyées, y compris au niveau de la bande passante.

Le nom de domaine 

Dans tous les cas de figure, pour un auto-hébergement décent, il vous faut un nom de domaine. Bien que je sois relativement ennuyé par la notion « d’achat » de nom de domaine (vous n’êtes que locataires du domaine), les moins de 10€ annuels que vous coûtera un domaine ne représente pas une dépense faramineuse. Il existe bien les solutions gratuites du type no-ip, mais vous êtes dépendants du bon fonctionnement du service, et – j’ignore si la situation a beaucoup changé – la configuration est quelque peu contraignante, pour peu que vous n’ayez pas un système de gestion intégré à votre routeur, et particulièrement quand vous avez une IP dynamique (ça existe encore ?)

Une fois le domaine acquis, théoriquement, vous en faites ce que vous voulez, à moins que l’offre que vous avez choisi ne vous limite d’une façon ou d’une autre : si vous installez et configurez votre propre serveur de noms de domaines (au hasard, bind), vous êtes libres de créer autant de sous-domaines que vous voulez. Faites attention cependant à certaines offres qui utilisent le service de validation de la configuration DNS de l’AFNIC : pour que vous puissiez gérer vous-même votre domaine, il vous faut deux serveurs DNS (un maître et un esclave). C’est notamment le cas chez Online, ce qui fait qu’outre la dédibox qui dessert – entre autres – ingnu.fr, j’ai aussi un serveur à la maison qui fait office d’esclave pour assurer la continuité du service.

Les applications

Pour s’auto-héberger, il faut savoir ce qu’on veut héberger : données personnelles ? musiques, films, ISOs de jeux ? Services ? Selon ce que vous voulez, l’auto-hébergement peut ne pas être la solution idéale. Il y a aussi probablement une question de philosophie derrière : m’auto-héberger me permet de m’affranchir de toute contrainte ou presque. J’ai installé un serveur de messagerie pour ne pas laisser un hotmail ou un gmail fouiller dans mes messages pour m’afficher de la pub, j’ai installé un dépôt git pour ne pas être limité en possibilités par un github, etc. Si je veux une machine 100% « rms approved« , je peux me la monter sans rendre de compte à personne. Si je veux chiffrer la totalité de mon disque, ou juste une partie, c’est selon mon bon vouloir. Si je veux passer mon RAID1 en RAID0 pour avoir 2To au lieu de 2x1To, pas de problème. Le choix des applications et services à auto-héberger est donc déterminant.

Au final

S’auto-héberger, bien que n’étant pas gratuit, permet tout à la fois de bénéficier de l’aspect pratique du Cloud, sans confier vos données à des organismes étrangers. Par ailleurs, vous regroupez vos données, applications et services au même endroit, ce qui, malgré la violation du principe geek de ne pas mettre tous ses oeufs dans le même panier (ce qui est excusable dans le cas où c’est vous-même qui construisez et utilisez le panier en question), simplifie grandement tout autant la sécurisation du système que sa sauvegarde.

Alors, qu’attendez-vous pour fermer vos comptes Google pour créer votre propre Cloud ?

Lire la Suite »]]>

• Les faux geeks qui se prétendent geeks parce qu’ils jouent 11 heures par jour
• Les faux geeks qui se prétendent geeks parce qu’ils utilisent des mots comme « cyber-marketing », « veille », « réseaux sociaux », et plus généralement, qui se disent geeks alors qu’ils voient Internet comme un marché financier
• Les gens qui traînent des pieds quand ils font leurs courses
• Les gens qui emmènent leurs gosses au supermarché (et les laissent crapahuter partout)
• Les gens qui ouvrent les boîtes de macaron au supermarché pour en grailler un et qui se font même pas chier à refermer la boîte comme si de rien n’était
• Les gens qui, toujours au supermarché, prennent un article dans un rayon, vont à la borne pour obtenir le prix juste à côté du rayon, et reposent l’article dans le panier sous la borne au lieu de le remettre en rayon
• Les gens qui crachent
• Les éditeurs de jeux vidéos commerciaux qui auraient les moyens de sortir de bons titres et qui sortent de la merde
• Même remarque pour la musique
• Même remarque pour les films
• Le gouvernement qui passe en douce des lois à la con
• Le cloud et le fait que tout le monde en parle en bien (à part les vrais geeks)
• Les conasses qui téléphonent au volant
• Les ouvriers qui roulent comme des cons
• Les serveurs de restaurant qui font la gueule
• Les clients de restaurant qui disent ni « merci », ni « s’il vous plait », ni « bonjour », ni « au revoir »
• Les jeunes cons qui se baladent par -5° avec une jambe de pantalon remontée jusqu’au genou
• Les gamins de moins de cinq ans qui me regardent comme si j’étais une tartine de Nutella géante
• Les magazines « Linux », qui usent et abusent du terme « Linux » pour désigner un système d’exploitation sans jamais parler de GNU (et qui, en plus, incendient la langue française, et ne traitent QUE d’applications graphiques sans pratiquement jamais mentionner les outils console)
• Même remarque pour Wikipédia
• Les « geeks » qui parlent d’Open Source au lieu de Free Software
• Plus généralement, les « geeks » qui ne savent absolument rien sur GNU ou Richard Stallman
• Les mecs qui nous considèrent comme des nerds juste parce qu’eux se considèrent faussement geeks
• La lingerie féminine léopard
• Les rayons de « lingerie » pour filles de moins de 12 ans (ok il en faut peut-être, mais pas au milieu d’un grand magasin, avec une grande pancarte, comme si tout le monde en avait besoin alors que c’est juste une question d’apparence, et surtout pas présentée comme de la lingerie, « sous-vêtements » suffit)
• L’État qui ne sait pas aligner trois phrases sans dire trois conneries*
• Les pilotes Libres de cartes réseaux dont le Makefile est truffé de bugs et qui, du coup, compilent pas (remarque, ça permet de chercher et comprendre pourquoi ça déconne)
• BLFS. Autant LFS est écrit au poil de cul, autant BLFS c’est le bordel
• Le chocolat chaud de Senseo qui requiert un support à dosettes spécial et qui est dégueulasse, alors que Milka sait faire un chocolat excellent sans support spécial
• Le mec de Scarlett Johansson et celui de Kaley Cuoco
• Les briquets neufs qui tombent en rade au bout d’une semaine
• Claude Guéant, Nicolas Sarkozy, et tous les politiciens qui vont se vanter de relancer l’économie avant les élections, pour mieux la détruire une fois élus
• Les jeunes « geeks » (moins de 30 ans) qui trouvent le moyen d’être sur le devant de la scène (oui je suis jaloux et je vous emmerde)
• La tendance naturelle de l’Homme à fermer la gueule de celui qui ne pense pas comme lui
• Les « geeks » qui utilisent Google et des iMerdes

Bref, je fais la gueule. Le premier qui me dit « Pète un coup ça ira mieux » je le flagelle en place publique avant de le cramer.

* Il faut que je développe un peu. Une pancarte, accrochée à la caisse du supermarché. Trois phrases pour dicter des recommandations anti-alcool, trois conneries, trois insultes à la langue française.

1. Il est interdit de vendre de l’alcool à des mineurs de moins de 18 ans : Il existe des mineurs de plus de 18 ans ? Il existe des gens de moins de 18 ans qui ne sont pas mineurs ? Ce n’est pas un peu redondant comme phrase ?
2. Il est interdit de vendre à crédit des boissons alcooliques : Depuis quand les boissons sont alcooliques ? Alcoolisées je veux bien, mais alcooliques…
3. Il est interdit de se trouver en état d’ivresse manifeste sur la voie publique : Oui, faut se retenir d’être bourré mais seulement dans la rue quand on est bien élevé. Par contre, comment on fait si on simule l’ivresse juste pour le fun ? On se fait mettre en garde à vue pendant 72 heures ? Pour être certain ? Pour faire semblant de décuver ?

Lire la Suite »]]> Je m’insurge depuis que ingnu a rouvert sur les lois liberticides qui affectent notamment Internet. Cependant, tant que ces lois ne concernent qu’Internet, à part les geeks, peu s’en émeuvent. L’inertie dont fait preuve le « commun des mortels » est à imputer probablement à trois causes : le manque d’intérêt, le manque de motivation pour délaisser des plateformes « qui marchent » pour des plateformes Libres qu’ils ne connaissent pas, et parce que ça n’affecte pas – encore – leur vie de tous les jours.

Cependant, plusieurs organisations (entreprises et État) conspirent pour tuer une liberté qui affecte tout le monde : la liberté d’acheter (et vendre) de l’occasion. En effet, qui n’a jamais acheté d’occasion ? Moi-même qui suis généralement – et ça me coûte de le dire – un early-adopter, il m’est déjà arrivé d’acheter des jeux, des livres ou des films d’occasion.

Tout cela a – probablement – commencé avec l’avènement du Cloud.

Considéré à ses débuts comme un moyen pratique de se mettre à sa disposition ses données depuis n’importe où dans le monde, les entreprises ont commencé à y voir un moyen de contrôler ce que les gens font des données qui y sont stockées, et ce que les gens consomment comme services.

À travers le Cloud, et plus précisément les Software As Service (SaS), les entreprises ont habilement amené leurs clients à se passer de logiciel à installer sur leur propre machine (logiciel qui pouvait alors être piraté) pour opter pour une solution plus restrictive : leur proposer de payer pour utiliser un logiciel que cette entreprise elle-même héberge, sur un serveur chargé du traitement des données, tâche anciennement affectée à la machine sur laquelle ce logiciel était installé chez le client.

Exactement le même procédé que la VoD (Video on Demand) : on n’achète plus la vidéo, on paye pour la regarder pendant 24h. Si on veut la revoir, il faut repayer.

Exactement le même procédé que la première génération de consoles de jeux connectées, où il faut mettre la main au portefeuille pour acheter des correctifs, des extensions, bien que le support CD (ou équivalent) était toujours disponible.

Exactement le même procédé, porté à un niveau jamais atteint, par Sony avec sa PSP Go. Plus de média physique, et par conséquent, plus moyen de le revendre.

Malheureusement, d’autres entreprises suivent. Et l’exemple le plus récent est la volonté de l’État de tuer le marché du film d’occasion. Et rien n’empêcherait les éditeurs de faire pression pour étendre leur emprise sur le marché du livre d’occasion.

L’occasion est un marché parallèle, libre ou presque. Les majors et éditeurs ne peuvent pas ponctionner les clients une deuxième fois lorsqu’un produit est revendu. La fin de l’occasion signifierait que les éditeurs pourraient vendre leurs produits plus chers – les gens seraient obligés d’acheter au prix fort – sans pour autant augmenter la valeur de ces produits, tout en tuant tout un pan de l’économie : les boutiques d’occasion payent des impôts comme toute entreprise.

Aujourd’hui, quand vous payer plus de cent euros pour un coffret Blu-ray avec des figurines, des livres collectors, des CD avec la bande originale, etc., vous en avez pour votre argent. La fin de l’occasion signifie forcément la distribution dématérialisée, et donc, la fin des coffrets collectors, ou même, la fin pure et simple du matériel.

Les implications sont abyssales : d’un côté, la dématérialisation du contenu signifie le traitement centralisé des données, donc les ordinateurs personnels n’auront plus d’intérêt à être puissants. Les passionnés n’auront donc plus accès à des processeurs ultra-performants, des cartes graphiques surpuissantes. Les PC ne deviendront plus que de simples terminaux voués à l’affichage, un peu comme un téléviseur. Tuer l’occasion, c’est tuer l’informatique.

C’est aussi tuer la valeur ajoutée, celle pour laquelle on décide de dépenser des sommes plus importantes que pour un objet classique, rare, ancien, disponible uniquement sur le marché de l’occasion parce que plus vendu, et donc, impossible à obtenir par d’autres moyens.

C’est tuer la créativité, car c’est réserver à une élite ayant les moyens d’acquérir de puissants serveurs et une bande passante coûteuse la possibilité de produire et diffuser de la culture.

De manière plus pragmatique, empêcher les gens d’acheter d’occasion, c’est réduire de manière significative leur pouvoir d’achat.

Je vais extrapoler et même un peu dévier du sujet, mais concrètement, d’une manière ou d’une autre, l’argent appartient à l’État. Quand vous êtes employés, l’argent que votre entreprise vous donne ne vient de nulle part ailleurs que de l’État. Les aides dont bénéficient certaines entreprises et certaines familles pauvres proviennent de l’État. En achetant, vous n’enrichissez pas un vendeur, vous ne faites que rendre cet argent à l’État, parce que ce vendeur paye des impôts, des taxes, et des fournisseurs, qui eux-mêmes payent des impôts et des taxes. L’argent passe ainsi de main en main jusqu’à retourner aux sources : dans les caisses de l’État. Autrement dit, d’une l’argent ne vous appartient pas, même si vous pleurez que vous l’avez gagné à la sueur de votre front, et de deux, l’argent n’a aucune valeur, ce n’est qu’un outil d’échange. Bref.

Avec les lois liberticides, la suppression des plateformes de téléchargement « illégales » et la promotion de plateformes légales, la suppression du marché de l’occasion, l’État ne cherche qu’une seule chose : supprimer un maximum d’intermédiaires possible. Moins il y a d’intermédiaires, plus d’argent sera récupéré. Et comme les plus riches sont ceux qui consomment le plus, ce sont eux aussi qui ramènent le plus d’argent à l’État. C’est la logique des « flux » financiers.

Mais qu’on soit geek, ouvrier, passionné de musique, fan de films, féru de lecture, tout ce que le gouvernement met en place nous concerne tous. C’est la suppression de notre patrimoine. En dématérialisant, on supprime notre patrimoine. On n’achète plus un coffret ou un livre, on achète des données numériques. Or, l’information, sous sa forme informatisée, ne peut s’acheter parce qu’elle se duplique aisément. L’information numérique doit rester libre, parce qu’elle ne peut pas être soumise à restrictions de part sa nature même. Mais personne (à part les chinois peut-être…) ne peut copier un coffret avec une figurine en résine numérotée, ou un album collector avec des photos inédites. C’est du matériel, c’est donc du patrimoine.

Alors, il faut lutter pour la conservation de notre patrimoine, il faut s’élever contre ces lois qui nous dépouillent tous !