Je vous ai parlé il y a quelques temps de la configuration d’un client Deluge permettant de se monter une petite seedbox. Aujourd’hui je vous propose un nouveau tuto traitant cette fois ci d’une toute autre solution : rTorrent interfacé avec Flood !

1. Objectifs

L’objectif de ce tutoriel est de vous montrer la marche à suivre pour installer votre propre seedbox sur un système d’exploitation Linux Debian ou Ubuntu (adaptez les commandes à votre distribution !) avec le logiciel rTorrent sur lequel nous allons ajouter une interface en Node.js un peu sympa : Flood.

Je pars du principe que vous avez déjà un serveur opérationnel, avec ou sans interface graphique c’est comme vous le sentez, perso j’en ai pas donc tout sera fait en interface de commande. Si vous n’avez pas de serveur à disposition, vous pouvez aller jeter un oeil chez Online.net qui vous louera un petit (ou un gros) serveur à prix raisonnable.

Si vous avez un nom de domaine c’est encore mieux car toute la fin du tutoriel traite de la mise en place d’un reverse proxy pour accéder à l’interface via une url propre et non pas via l’ip + le port.

Pour info, dans les commandes et fichiers de configuration dont je vous parle en dessous, tout ce qui est en gras est à adapter à votre configuration !!!

 

2. Installation et configuration des pré-requis : screen, curl, git et apache

Pour installer rTorrent et Flood, un certain nombre de pré-requis sont nécessaires et c’est par cela que nous allons commencer.

On commence par installer screen, curl et git qui sont nécessaires au bon fonctionnement de la seedbox :

sudo apt install screen curl git

Ensuite, on ajoute un utilisateur qui permettra de lancer rTorrent sans utiliser le compte administrateur, la meilleure option en terme de sécurité : 

sudo adduser --disabled-password rtorrent

Et voilà pour les pré-requis, si vous envisagez de mettre en place le reverse proxy pour avoir une URL propre, vous devrez installer Apache2 en plus du reste :

sudo apt install apache2

 

3. Installation et configuration de rTorrent

Une fois que vous avez installé l’ensemble des pré-requis, vous pouvez passer à l’installation du logiciel rTorrent :

sudo apt install rtorrent

Ensuite, on s’occupe du fichier de configuration :

sudo vi /home/rtorrent/.rtorrent.rc

Adaptez les valeurs suivantes à votre installation :

# Emplacement des fichiers téléchargés
directory = /répertoire/rtorrent/downloads

# Emplacement des sessions de téléchargement
session = /répertoire/rtorrent/.session

# Ports à ouvrir (2 ports identiques = 1 seul et même port, 2 ports différents = plage de ports !)
port_range = 40000-40000
port_random = no

# Vérifier le hash de controle à la fin du téléchargement
check_hash = yes

# Activation du DHT (pour les trackers publics)
dht = auto
dht_port = 6881
peer_exchange = yes

# Authoriser les trackers UDP
use_udp_trackers = yes

# Activer le chiffrement si possible
encryption = allow_incoming,try_outgoing,enable_retry

# Port de communication avec Flood
scgi_port = 127.0.0.1:5000

Ensuite, on créé et on donne les bonnes permissions aux différents répertoires :

sudo mkdir /répertoire/rtorrent/downloads
sudo mkdir /répertoire/rtorrent/.session
sudo chmod 775 -R /répertoire/rtorrent
sudo chown rtorrent:rtorrent -R /répertoire/rtorrent
sudo chown rtorrent:rtorrent /home/rtorrent/.rtorrent.rc

On créé un service rTorrent qui permettra de démarrer simplement le logiciel :

sudo vi /etc/systemd/system/rtorrent.service

Et on y insère le code suivant :

#!/bin/sh

[Unit]
Description=rTorrent
After=network.target

[Service]
User=rtorrent
Type=forking
KillMode=none
ExecStart=/usr/bin/screen -d -m -fa -S rtorrent /usr/bin/rtorrent
ExecStop=/usr/bin/killall -w -s 2 /usr/bin/rtorrent
WorkingDirectory=%h

[Install]
WantedBy=default.target

On active le service rTorrent et on démarre le logiciel :

sudo systemctl enable rtorrent.service
sudo systemctl start rtorrent

Voilà, vous avez maintenant un rTorrent fonctionnel et prêt à faire feu. Rendons le un peu plus sexy…

 

4. Installation et configuration de Flood

Flood c’est super sexy donc on va pas se priver et l’installer pour remplacer l’interface habituelle de rTorrent. Croyez moi, y’a pas photo c’est carrément mieux !

On commence par installer Node.js, un framework basé sur Javascript et avec lequel est développé Flood :

curl -sL https://deb.nodesource.com/setup_6.x | sudo -E bash -
sudo apt install -y nodejs

On récupère ensuite Flood sur git et on le place dans le bon répertoire :

cd /répertoire/rtorrent
sudo git clone https://github.com/jfurrow/flood.git

Puis on prépare le fichier template :

cd flood
sudo cp config.template.js config.js

On l’édite :

sudo vi config.js

On modifie cette valeur :

floodServerHost: '0.0.0.0'

Et on active Flood :

sudo npm install --production

Même principe que pour rTorrent, on évite de lancer Flood avec un compte administrateur donc on créer un utilisateur dédié :

sudo adduser --disabled-password flood

Et on lui donne les droits sur le répertoire où est installé Flood :

sudo chown -R flood:flood /répertoire/rtorrent/flood/

On fait également en sorte que Flood soit un service afin de faciliter sa maintenance (Marche / Arrêt) :

sudo vi /etc/systemd/system/flood.service

On insère le code suivant :

#!/bin/sh

[Service]
WorkingDirectory=/répertoire/rtorrent/flood
ExecStart=/usr/bin/npm start
Restart=always
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=notell
User=flood
Group=flood
Environment=NODE_ENV=production

[Install]
WantedBy=multi-user.target

Et on active enfin le service :

sudo systemctl enable flood
sudo systemctl start flood

Voilà, votre seedbox est prête à faire feu et est joignable à l’adresse suivante : http://IP-DE-VOTRE-SERVEUR:5000

 

5. Configuration du reverse proxy avec Apache

Si vous possédez un nom de domaine et que vous préférez avoir http://VOTRE-DOMAINE.EXT au lieu de http://IP-DE-VOTRE-SERVEUR:5000 parce que ça fait plus propre mais également pour des raisons évidentes de sécurité, il faut maintenant configurer le reverse proxy.

Commençons par activer le module proxy_http pour apache :

sudo a2enmod proxy_http

Puis créons un fichier host pour définir les paramètres de notre interface :

sudo vi /etc/apache2/sites-available/mon-nom-de-domaine.conf

Y insérer :

<VirtualHost *:80>
ServerAdmin VOTRE_ADRESSE_EMAIL
ServerName VOTRE_NOM_DE_DOMAINE
ServerAlias VOTRE_NOM_DE_DOMAINE

ProxyRequests Off
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
ProxyPass / http://localhost:9092/
ProxyPassReverse / http://localhost:9092/
</VirtualHost>

Activez le fichier host et redémarrez Apache :

sudo a2ensite mon-nom-de-domaine.conf
sudo service apache2 reload

Voilà, votre seedbox est désormais accessible via l’adresse http://VOTRE_NOM_DE_DOMAINE

Si vous voulez passer le http en https, je vous invite à jeter un coup d’oeil à mon tutoriel sur Let’s Encrypt

Read More

Le HTTPS se démocratise peu à peu et, pour plusieurs raisons, j’ai décidé de migrer l’intégralité de mes sites. Je vais vous expliquer aujourd’hui comment effectuer une transition simple de HTTP vers HTTPS en utilisant le service Let’s Encrypt.

Si tu en as rien à secouer des raisons qui m’ont poussé à migrer vers HTTPS, je t’invite à passer directement à la « Présentation de Let’s Encrypt » ou carrément au tutoriel si t’es complètement YOLO.

1. Pourquoi passer à HTTPS

a. Un meilleur référencement

Cela fait un moment que Google crie haut et fort qu’il favorise dans son classement les sites qui utilisent HTTPS au lieu de HTTP. Pour ma part, j’ai envie d’avoir un meilleur référencement car cela me permettra probablement de toucher plus de visiteurs et d’attirer l’attention sur le blog (et éventuellement mes autres sites / blogs).

De plus, début septembre, le géant de Mountain View franchissait un nouveau cap en annonçant qu’à partir de Janvier 2017, l’affichage de l’URL des sites en HTTP allait être modifié au sein de son navigateur Chrome.

Google indiquera bientôt qu'un site n'est pas sécurisé

Bon OK, cela ne concerne pas toutes les pages mais seulement celles qui comportent une saisie de mot de passe ou d’informations bancaires (dans un premier temps). Quoi qu’il en soit, sur une page en HTTP, l’URL sera précédée de « Non sécurisé », une indication très explicite pour l’internaute… Je me dis que cette indication lancée aux utilisateurs sera peut être étendue à TOUTES les pages HTTP le jour où Google-le-tout-puissant l’aura décidé et je préfère anticiper ça que de me retrouver à devoir faire une migration « en urgence ».

 

b. Des informations sécurisées

C’est la deuxième raison et qui est surement plus importante que celle énoncée juste avant : je veux que les informations que j’envoie et que je reçois du serveur soient chiffrées. Cela diminue le risque d’interception des informations qui transitent (mots de passes entre autres) par quelqu’un de mal intentionné.

Vous me direz « oui mais c’est toujours possible… ». Certes, mais au moins ce sera déjà un peu plus compliqué de récupérer une information exploitable tout de suite comme ça l’était jusqu’à présent. De plus, HTTPS permet de garantir au client (toi, mon petit visiteur inconnu) que les informations qui transitent entre le serveur et ton PC n’ont pas été altérées ! Je le fais donc pour moi, mais aussi un peu pour mes visiteurs.

Passons maintenant dans le vif du sujet.

 

2. Let’s Encrypt : qu’est ce que c’est ?

Let’s Encrypt est une autorité de certification (CA), libre, automatisée et gérée pour le bénéfice du public. C’est un service fourni par le Internet Security Group (ISRG).

Let’s Encrypt délivre aux utilisateurs les certificats numériques dont ils ont besoin afin de leur permettre d’implémenter HTTPS (SSL / TLS) pour leurs sites web, gratuitement, de la manière la plus simple possible, pour créer un Web plus sécurisé avec un haut degré de confientialité.

Les principes clés derrière Let’s Encrypt sont:

    Gratuit : Let’s Encrypt est entièrement gratuit ! (mais vous pouvez leur faire un don pour soutenir l’initiative)
    Automatique : Vous pouvez obtenir et renouveler vos certificats automatiquement.
    Sécurisé : Let’s Encrypt se base sur TLS 1.2 avec chiffrement en 2048 bits.
    Transparent : Tous les certificats délivrés ou révoqués seront enregistrées publiquement et disponibles pour quiconque souhaite les inspecter.
    Ouvert : Le protocole de délivrance et de renouvellement automatique sera publié en tant que norme ouverte que les autres pourront adopter.
    Indépendant : Tout comme les protocoles Internet sous-jacents, Let’s Encrypt est un effort conjoint au profit de la communauté, au-delà du contrôle de toute une organisation.

Et pour terminer, Let’s Encrypt est soutenu par quelques grands noms du monde informatique :

Let's Encrypt : de nombreux soutiens

Mais tout n’est pas rose puisque vos certificats générés depuis Let’s Encrypt ont une durée de vie « courte » : 90 jours. Le gros avantage, c’est que vous pouvez automatiser leur renouvellement sans problème… Suivez le guide !

 

3. Migrer ses sites web de HTTP vers HTTPS avec Let’s Encrypt

Le tutoriel suivant va vous expliquer comment mettre en place un certificat SSL Let’s Encrypt sur un de vos sites internet pour le passer en HTTPS. Les pré-requis sont les suivants :

– Système d’exploitation Ubuntu 16.04 configuré et opérationnel (vous pouvez également adapter le tutoriel à votre distribution)

– Serveur web Apache configuré avec un virtualhost

La première étape est d’installer le client qui permet de récupérer le certificat depuis l’autorité de certification et par la suite de renouveler vos certificats. Il en existe plusieurs mais Let’s Encrypt recommande l’utilisation de Certbot : https://certbot.eff.org/

On commence donc par installer le package :

sudo apt-get install python-letsencrypt-apache 

Ensuite, une fois que le package est installé vous pouvez créer votre premier certificat. A savoir que vous pouvez créer un certificat pour un seul domaine à la fois et ça se passe avec cette commande :

sudo letsencrypt --apache -d nom_de_domaine.com

Si vous avez des sous-domaines à passer en HTTPS également, vous pouvez taper cette commande à la place :

sudo letsencrypt --apache -d nom_de_domaine.com -d www.nom_de_domaine.com -d sd2.nom_de_domaine.com

Il est recommandé de mettre d’abord le domaine principal suivi par autant de sous-domaines que vous en avez. Certbot va vous demander une adresse e-mail puis si vous voulez que l’accès HTTPS soit obligatoire (Secure) ou optionnel (Easy) :

Let's Encrypt : HTTPS ou HTTP+HTTPS

Pour ma part, j’ai choisi « Secure » pour tous mes sites et c’est passé nickel ! Dès que vous voulez accéder à votre site en HTTP, vous êtes automatiquement redirigé vers le HTTPS et pourquoi laisser un accès HTTP quand on peut faire du full HTTPS ? Cette redirection est mise en place par Certbot directement dans le fichier vhost de votre domaine qui contient désormais ces lignes en plus :

RewriteEngine on
RewriteCond %{SERVER_NAME} =nom_de_domaine.com [OR]
RewriteCond %{SERVER_NAME} =www.nom_de_domaine.com
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,QSA,R=permanent]

Si tout fonctionne et que vous souhaitez tester votre nouveau domaine en HTTPS, vous pouvez le faire à l’adresse suivante : https://www.ssllabs.com/ssltest/analyze.html?d=nom_de_domaine.com (remplacer nom_de_domaine.com par votre nom de domaine personnel bien entendu…) 

Let's Encrypt : Test du site en HTTPS

 

Si par hasard la commande lestencrypt pour générer le certificat ne fonctionne pas, jetez un coup d’oeil du coté de votre pare-feu, les ports sont peut être fermés.

 

4. Automatisation du renouvellement des certificats

Pour renouveler les certificats que vous avez généré, il faut taper la commande suivante :

sudo letsencrypt renew

Vous devriez voir apparaitre la liste des certificats que vous avez déjà généré avec un message indiquant qu’un renouvellement est inutile.

Comme c’est une opération à répéter régulièrement et que l’on risque d’oublier de le faire 9 fois sur 10, nous allons mettre en place un cron :

sudo crontab -e

Et y ajouter la ligne suivante :

0 2 5 * * /usr/bin/letsencrypt renew >> /var/log/le-renew.log

Ainsi, le 5 de chaque mois à 2h00 du matin votre serveur vérifiera tout seul comme un grand si vos certificats doivent être renouvelés et s’en chargera lui même !

Passer vos sites en HTTPS devrait donc être maintenant un jeu d’enfant !

Sponsornot : Zéro collaboration

Read More

Avec l’avènement du jeu en ligne, la communication vocale est devenue un élément incontournable pour les teams, les guildes ou les escouades. Pour répondre à ce besoin, plusieurs solutions existent et nous nous intéresserons dans ce tutoriel à l’une des plus répandues : Teamspeak 3.

Vous pouvez installer un serveur de plusieurs façons. Si vous avez une grosse connexion internet (ADSL pour quelques utilisateurs, Fibre pour les grosses Team / Guildes), vous pouvez par exemple l’héberger directement sur votre machine. L’inconvénient est que votre PC doit être allumé en permanence et ce n’est pas toujours possible !

La solution que je vous propose est réalisable dans le cas où vous disposez d’un serveur dédié ou d’un VPS (Virtual Private Server), chez Ikoula par exemple où a été réalisé le test d’installation sur VPS, qui lui dispose d’une grosse bande passante et sera allumé 24/24 avec une disponibilité de 99,9% dans un datacenter. Vous pouvez également utiliser un PC chez vous qui serait dédié à cet usage, c’est à vous de voir.

 

1. PRE-REQUIS :

Avant de démarrer, vous avez besoin de :

Un serveur installé sous Linux (32 ou 64 bits) avec MySQL ou MariaDB installé et un compte SQL « teamspeak » disposant de tous les droits sur une base de données (nommée au hasard « teamspeak » pour plus de clarté). Ce tutoriel est basé sur une distribution Linux Ubuntu 64bits avec MariaDB.

 

2. CREATION DE L’UTILISATEUR DEDIE AU DAEMON :

sudo adduser --system --home /home/teamspeak --gecos "Exe TS3 Server" --group teamspeak
sudo passwd teamspeak

Et lui attribuer un mot de passe de votre choix

 

3. PREPARATION DES FICHIERS DU SERVEUR :

Téléchargement de l’archive de la dernière version de serveur disponible (adapter à votre architecture) :

cd /home/teamspeak
sudo wget http://ftp.4players.de/pub/hosted/ts3/releases/3.0.11/teamspeak3-server_linux-amd64-3.0.11.tar.gz

Ici, vous devez adapter la version de serveur à votre architecture ET à votre installation. Prendre la version 3.0.10 si vous avez MySQL et 3.0.11 si vous avez MariaDB.

Décompression de l’archive :

sudo tar -zxf teamspeak3-server_linux-amd64-3.0.11.tar.gz
sudo mv teamspeak3-server_linux-amd64 teamspeak3
sudo chown -R teamspeak:teamspeak teamspeak3

Création du fichier de configuration du serveur :

sudo vi /home/teamspeak/teamspeak3/ts3server.ini

Et y insérer pour MariaDB :

machine_id=
default_voice_port=9987
voice_ip=0.0.0.0
licensepath=
filetransfert_port=30033
filetransfer_ip=0.0.0.0
query_port=10011
query_ip=0.0.0.0
dbplugin=ts3db_mariadb
dbpluginparameter=ts3db_mariadb.ini
dbsqlpath=sql/
dbsqlcreatepath=create_mariadb/
logpath=logs
logquerycommands=0

pour MySQL :

machine_id=
default_voice_port=9987
voice_ip=0.0.0.0
licensepath=
filetransfert_port=30033
filetransfer_ip=0.0.0.0
query_port=10011
query_ip=0.0.0.0
dbplugin=ts3db_mysql
dbpluginparameter=ts3db_mysql.ini
dbsqlpath=sql/
dbsqlcreatepath=create_mysql/
logpath=logs
logquerycommands=0

Création du fichier de connexion du serveur à la base de données :

sudo vi /home/teamspeak/teamspeak3/ts3db_mariadb.ini

ou

sudo vi /home/teamspeak/teamspeak3/ts3db_mysql.ini

Et y insérer :

[config]
host=127.0.0.1
port=3306
username=teamspeak
password=VOTRE_MOT_DE_PASSE
database=teamspeak
socket=

Pour MariaDB :

Vérifiez si libmariadb.so est bien présent :

cd /home/teamspeak/teamspeak3
ldd libts3db_mariadb.so
linux-vdso.so.1 (0x00007fff43fff000)
libmariadb.so.2 => not found
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f211d5dd000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f211d234000)
/lib64/ld-linux-x86-64.so.2 (0x00007f211dbe0000)

Si il vous indique également “not found” :

sudo wget http://ftp.de.debian.org/debian/pool/main/m/mariadb-client-lgpl/libmariadb2_2.0.0-1_amd64.deb
sudo dpkg -i libmariadb2_2.0.0-1_amd64.deb

Pour MySQL :

Vérifiez si libmysql.so est bien présent :

cd /home/teamspeak/teamspeak3
ldd libts3db_mysql.so
linux-vdso.so.1 (0x00007fff43fff000)
libmysqlclient.so.15 => not found
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f211d5dd000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f211d234000)
/lib64/ld-linux-x86-64.so.2 (0x00007f211dbe0000)

Si il vous indique également “not found”, sachez qu’il est difficile de trouver le fichier en question. Il est disponible sur mon serveur :

sudo wget http://www.geek-chronicles.com/ressources/libmysqlclient15off_5.0.96-0ubuntu3_amd64.deb
sudo dpkg -i libmysqlclient15off_5.0.96-0ubuntu3_amd64.deb 

 

4. SCRIPT DE DEMARRAGE AUTOMATIQUE DU SERVEUR :

Création du fichier de configuration :

sudo vi /etc/init.d/teamspeak

Et y insérer :

#! /bin/sh
### BEGIN INIT INFO
# Provides: teamspeak
# Required-Start: networking
# Required-Stop:
# Default-Start: 2 3 4 5
# Default-Stop: S 0 1 6
# Short-Description: TeamSpeak Server Daemon
# Description: Starts/Stops/Restarts the TeamSpeak Server Daemon
### END INIT INFO
set -e
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
DESC="TeamSpeak 3 Server"
NAME=teamspeak
USER=teamspeak
DIR=/home/teamspeak/teamspeak3
DAEMON=$DIR/ts3server_startscript.sh
#PIDFILE=/var/run/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME
# Gracefully exit if the package has been removed.
test -x $DAEMON || exit 0
cd $DIR
sudo -u teamspeak ./ts3server_startscript.sh $1 inifile=ts3server.ini


Attribution des droits corrects d’exécution :

sudo chown teamspeak:teamspeak /etc/init.d/teamspeak
sudo chmod 755 /etc/init.d/teamspeak
sudo update-rc.d teamspeak defaults

 

5. DEMARRAGE DU SERVEUR :

Le serveur est prêt à démarrer :

Service teamspeak start

Pensez à noter les identifiants du compte d’administration du serveur et le token qui vous sera nécessaire pour obtenir les privileges administrateur :

Teamspeak 3 : ServerAdmin Privilege Key et Server Query Admin Account

Il ne vous reste plus qu’à vous connecter au serveur Teamspeak en entrant l’IP de votre serveur et le port que vous avez configuré (par défaut 9987) : ip.de.votre.serveur:port

Ensuite, dans Permissions > Use Privilege Key, il vous suffit d’entrer la clé « ServerAdmin » fournie par le serveur lors de son premier démarrage.

Le « Server Query Admin Account » vous sera utile pour administrer votre serveur Teamspeak 3 en ligne de commande ou via un utilitaire dédié tel que Yatqa (http://addons.teamspeak.com/directory/addon/administration/YaTQA-Query-Admin-Tool-(German).html).

Sponsornot : Gratuit

Read More

Vous avez surement déjà entendu parler des seedbox, un serveur dédié au téléchargement de fichiers torrent (ISO Linux par exemple) disposant d’une connexion internet bien plus performante que celle de votre domicile. Si vous possédez un serveur dédié, sachez qu’il est possible d’en configurer une très simplement afin de s’affranchir de ce service payant fourni par un prestataire bien souvent inconnu !

Warning Ce tutoriel ne vous indiquera pas comment télécharger des fichiers légaux ou illégaux mais uniquement comment mettre le serveur Deluge en place. Vous êtes responsable de ce que vous téléchargerez avec !

 

Tout d’abord, il faut créer un utilisateur dédié au daemon :

sudo adduser --disabled-password --system --home /var/lib/deluge --group deluge

Ensuite, il faut installer le daemon et son interface web :

sudo apt-get install deluged deluge-web

Puis les configurer :

Création du fichier de configuration du daemon :

vi /etc/init/deluge.conf

Et y insérer :

start on (filesystem and networking) or runlevel [2345] stop on runlevel [016] env uid=deluge env gid=deluge env umask=007exec start-stop-daemon -S -c $uid:$gid -k $umask -x /usr/bin/deluged -- -d

 

Création du fichier de configuration de l’interface web :

vi /etc/init/deluge-web.conf

Et y insérer :

start on started deluge stop on stopping deluge env uid=deluge env gid=debian-deluged env umask=027exec start-stop-daemon -S -c $uid:$gid -k $umask -x /usr/bin/deluge-web

 

Enfin, vous pouvez démarrer deluge :

sudo start deluge

 

Si vous voulez faire quelque chose de propre et séparer l’utilisateur qui éxécute le daemon et celui qui pourra se connecter en FTP pour récupérer les fichiers téléchargés, il vous faut créer un utilisateur spécifique :

sudo useradd -d /var/lib/deluge -g deluge seedbox
sudo passwd seedbox

Attribuez lui un mot de passe solide.

 

Pour accéder à l’interface web (le mot de passe par défaut est deluge), entrez l’URL suivante dans votre navigateur :

http://ip-du-serveur:8112

Interface Web de Deluge

Vous pouvez maintenant procéder à la configuration du serveur Deluge via l’interface web qui s’affiche. Je vous invite par exemple à changer le port de l’interface, changer le mot de passe par défaut, etc…

Sponsornot : Zéro collaboration

Read More

Comme je vous en ai parlé dans un précédent article, mon serveur a été victime d’une tentative d’exploit d’une faille WordPress.

Pour m’en prémunir, j’ai créé une nouvelle règle dans Fail2Ban qui va analyser les logs et repérer l’action suspecte à bloquer.

Si vous n’avez pas encore installé Fail2Ban :

sudo apt-get install fail2ban

Ensuite, il faut commencer par créer un filtre pour parser les logs à la recherche des nombreuses tentatives d’accès :

cd /etc/fail2ban/filter.d
sudo vi apache-xmlrpc.conf

Et y ajouter le code suivant :

[Definition]
failregex = ^<HOST> .*POST .*xmlrpc\.php.* ignoreregex =

Quittez et enregistrez le fichier. A ce stade, vous venez de créer le filtre qui va chercher l’adresse IP correspondant à la machine qui tente de lancer l’exploit sur votre fichier xmlrpc.php situé à la racine de votre installation WordPress. Passons maintenant à sa mise en place dans la configuration de Fail2Ban :

cd /etc/fail2ban/
sudo vi jail.conf

Ajoutez à la liste des filtres déjà présents celui que vous venez de créer :

[apache-xmlrpc] enabled = true
port = http,https
filter = apache-xmlrpc
logpath = /CHEMIN-VERS-VOS-FICHIERS-DE-LOG/access.log
maxretry = 6

Quittez et enregistrez le fichier. Il ne reste plus qu’à redémarrer le service Fail2Ban :

sudo service fail2ban restart

Et le tour est joué ! Vous n’avez plus qu’à surveiller les logs de Fail2Ban pour détecter les IPs qui tentent d’accéder à votre site et qui sont bloquées par le logiciel pour ensuite faire un whois suivi d’un déclenchement d’abuse.

Attention toutefois, cette astuce n’est efficace que sur de modestes sites. Si vous héberger un gros site avec un fort traffic, le parcours des logs Apache par Fail2Ban risque probablement d’impacter les performances de votre serveur en mobilisant une charge importante du CPU !

Sponsornot : Zéro collaboration

Comme vous le savez surement, j’héberge moi même mes sites internet sur un serveur dédié loué chez Online.net. En début de semaine, j’ai constaté des ralentissements importants sur l’ensemble de mes sites, ainsi que des problèmes de synchronisation MySQL entre les dis sites et leurs bases de données respectives. Je me connecte donc en SSH sur mon dédié et balance donc une petite commande « top » pour afficher les processus qui tournent.

A ma grande surprise, la liste n’est composée que d’une succession de services Apache2 qui vont et viennent et surchargent ainsi la totalité ou presque des ressources de mon serveur. La charge processeur culmine autour de 99% d’utilisation en constant, alors que d’ordinaire je suis plutôt entre 5 et 10%…

Mon premier réflexe : redémarrer le service Apache2 :

sudo service apache2 restart

Je patiente quelques secondes le temps que le service remonte et refait un « top ». Même constat, mon serveur est toujours à fond… Du coup, je file jeter un petit coup d’oeil aux logs et là, surprise :

mon-user@mon-serveur:~$ cd /var/log/apache2/
mon-user@mon-serveur:/var/log/apache2$ ll
total 786200
drwxr-x--- 2 root adm 4096 sept. 21 06:25 ./
drwxr-xr-x 14 root root 4096 sept. 24 06:25 ../

-rw-r----- 1 root adm 163781250 sept. 24 20:00 access.log
-rw-r----- 1 root adm 245624497 sept. 21 06:25 access.log.1
-rw-r----- 1 root adm 6488434 juil. 20 06:24 access.log.10.gz
-rw-r----- 1 root adm 6781312 juil. 13 06:25 access.log.11.gz
-rw-r----- 1 root adm 5014221 juil. 6 06:25 access.log.12.gz
-rw-r----- 1 root adm 6811034 juin 29 06:25 access.log.13.gz
-rw-r----- 1 root adm 6491920 juin 22 06:25 access.log.14.gz
-rw-r----- 1 root adm 8740091 juin 15 06:25 access.log.15.gz
-rw-r----- 1 root adm 13286015 juin 8 06:25 access.log.16.gz

-rw-r----- 1 root adm 7343230 sept. 24 20:00 error.log
-rw-r----- 1 root adm 13729544 sept. 21 06:25 error.log.1
-rw-r----- 1 root adm 602268 juil. 20 06:25 error.log.10.gz
-rw-r----- 1 root adm 569964 juil. 13 06:25 error.log.11.gz
-rw-r----- 1 root adm 483897 juil. 6 06:25 error.log.12.gz
-rw-r----- 1 root adm 334804 juin 29 06:25 error.log.13.gz
-rw-r----- 1 root adm 457884 juin 22 06:25 error.log.14.gz
-rw-r----- 1 root adm 853488 juin 15 06:25 error.log.15.gz
-rw-r----- 1 root adm 780921 juin 8 06:25 error.log.16.gz

-rw-r----- 1 root adm 4917534 sept. 24 20:00 other_vhosts_access.log
-rw-r----- 1 root adm 9301167 sept. 21 06:25 other_vhosts_access.log.1
-rw-r----- 1 root adm 66098 juil. 20 06:25 other_vhosts_access.log.10.gz
-rw-r----- 1 root adm 89567 juil. 13 06:25 other_vhosts_access.log.11.gz
-rw-r----- 1 root adm 52761 juil. 6 06:25 other_vhosts_access.log.12.gz
-rw-r----- 1 root adm 63852 juin 29 06:25 other_vhosts_access.log.13.gz
-rw-r----- 1 root adm 60675 juin 22 06:25 other_vhosts_access.log.14.gz
-rw-r----- 1 root adm 87682 juin 15 06:25 other_vhosts_access.log.15.gz
-rw-r----- 1 root adm 204479 juin 8 06:25 other_vhosts_access.log.16.gz

Je vous laisse comparer la taille des archives de log de septembre, avec celle des autres mois que j’ai volontairement laissé. Vous pouvez constater que pour septembre la quantité de logs s’est envolée et cela m’a mis la puce à l’oreille.

J’affiche le contenu du fichier access.log afin de voir qu’est ce qui accède à mon serveur, et parmi les quelques requêtes légitimes (je ne peux malheureusement pas me vanter de comptabiliser des millions de visites / mois ;)) je détecte 4 IPs qui ne requêtent pas de façon « normale » :

mon-user@monserveur:/var/log/apache2$ cat access.log | grep ip-suspecte
ip-suspecte - - [22/Sep/2014:19:39:21 +0200] "POST /xmlrpc.php HTTP/1.0" 200 544 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
ip-suspecte - - [22/Sep/2014:19:39:21 +0200] "POST /xmlrpc.php HTTP/1.0" 200 544 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
ip-suspecte - - [22/Sep/2014:19:39:22 +0200] "POST /xmlrpc.php HTTP/1.0" 200 544 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
ip-suspecte - - [22/Sep/2014:19:39:22 +0200] "POST /xmlrpc.php HTTP/1.0" 200 544 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
ip-suspecte - - [22/Sep/2014:19:39:22 +0200] "POST /xmlrpc.php HTTP/1.0" 200 544 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
ip-suspecte - - [22/Sep/2014:19:39:22 +0200] "POST /xmlrpc.php HTTP/1.0" 200 544 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
ip-suspecte - - [22/Sep/2014:19:39:22 +0200] "POST /xmlrpc.php HTTP/1.0" 200 544 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
ip-suspecte - - [22/Sep/2014:19:39:22 +0200] "POST /xmlrpc.php HTTP/1.0" 200 544 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
ip-suspecte - - [22/Sep/2014:19:39:22 +0200] "POST /xmlrpc.php HTTP/1.0" 200 544 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
ip-suspecte - - [22/Sep/2014:19:39:22 +0200] "POST /xmlrpc.php HTTP/1.0" 200 544 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
ip-suspecte - - [22/Sep/2014:19:39:23 +0200] "POST /xmlrpc.php HTTP/1.0" 200 544 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
ip-suspecte - - [22/Sep/2014:19:39:23 +0200] "POST /xmlrpc.php HTTP/1.0" 200 544 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
ip-suspecte - - [22/Sep/2014:19:39:23 +0200] "POST /xmlrpc.php HTTP/1.0" 200 544 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"

Au total : 200000 requêtes en 24h de cette simple IP, et il y en avait 3 autres, certes beaucoup moins virulentes mais pour le serveur s’en était trop.

On m’a demandé pourquoi je n’avais pas installé Fail2Ban. Et bien si, Fail2Ban était pourtant bel est bien installé ! Le problème, c’est que lorsqu’on épluche les logs on voit que l’attaquant fait un POST sur un fichier bien précis d’une installation WordPress : xmlrpc.php. La réponse du serveur à cette requête est 200 « Requête traitée avec succès », il n’y a donc aucune erreur de renvoyer… L’attaque passe ainsi entre les mailles de Fail2Ban dans sa configuration de base…

Une recherche sur Internet m’a permis d’identifier cette attaque comme étant une tentative d’exploit d’une vulnérabilité connue de WordPress. Comme il s’agit aussi d’une tentative d’injection SQL, j’ai jeté un oeil aux logs concernés :  

mon-user@mon-serveur:/var/log/mysql$ ll
total 36
drwxr-s--- 2 mysql adm 4096 sept. 25 06:25 ./
drwxr-xr-x 14 root root 4096 sept. 25 06:25 ../
-rw-r----- 1 mysql adm 0 sept. 25 06:25 error.log
-rw-r----- 1 mysql adm 20 sept. 24 06:25 error.log.1.gz
-rw-r----- 1 mysql adm 20 sept. 23 06:26 error.log.2.gz
-rw-r----- 1 mysql adm 1059 sept. 22 14:15 error.log.3.gz
-rw-r----- 1 mysql adm 20 sept. 21 06:25 error.log.4.gz
-rw-r----- 1 mysql adm 20 sept. 20 06:25 error.log.5.gz
-rw-r----- 1 mysql adm 20 sept. 19 06:25 error.log.6.gz
-rw-r----- 1 mysql adm 20 sept. 18 06:25 error.log.7.gz

Pour la journée du 22 septembre, la taille des logs a été multipliée par 50 environ, preuve qu’il s’agit bien d’une tentative d’exploit de la faille sur la fonctionnalité Pingback de WordPress. Je vous indiquerai dans un prochain tutoriel comment configurer Fail2Ban pour qu’il prenne en compte cette attaque sur vos installations WordPress.

Après un WhoIs sur les différentes IPs, 2 provenaient de serveurs hébergés chez Online et 2 de chez Elcatel. Ayant toujours été très bien renseigné par l’assistance du premier, je les ai contacté pour leur faire part du problème et ils m’ont guidé pour déclencher un abuse. La hotline Online ? Toujours au top (je vous invite à lire mon article sur mon expérience avec eux) !

Dans la foulée, pour stopper cette surcharge assez handicapante avant le traitement du signalement, j’ai créé 4 règles dans le firewall du serveur :

mon-user@mon-serveur:/~$ sudo ufw deny from ip-suspecte-1
mon-user@mon-serveur:/~$ sudo ufw deny from ip-suspecte-2
mon-user@mon-serveur:/~$ sudo ufw deny from ip-suspecte-3
mon-user@mon-serveur:/~$ sudo ufw deny from ip-suspecte-4
mon-user@mon-serveur:/~$ sudo ufw disable
mon-user@mon-serveur:/~$ sudo ufw enable

La charge serveur est instantanément retombée à son niveau d’origine et les sites internet et autres services hébergés sont redevenus fluides.

Moralité : superviser son serveur est indispensable pour traiter au plus vite ce genre d’attaque…

Sponsornot : Zéro collaboration

Read More

Un article un peu spécial, qui n’a pas vraiment de lien avec ma série de tutoriels sur comment monter un serveur dédié mais qui est plutôt destiné à vous faire partager mon expérience chez Online.net et je sais que beaucoup ne seront pas de mon avis.

Voilà maintenant 3 ans que je suis client chez eux. Tout a commencé le 6 janvier 2011 avec une Dedibox SC à 14.99€ HT/mois, mon tout premier serveur dédié. Dessus, j’ai appris à installer, configurer un OS Linux Server sans interface graphique, alors que je n’y connaissais rien. J’ai petit à petit délaissé mes différents hébergements mutualisés pour centraliser tous mes sites internet sur le même serveur, MON serveur.

Pendant 2 ans, il a été vaillant, répondant à mes attentes, mais j’en voulais plus. Alors en décembre 2012, je me suis lancé et j’ai pris une Dedibox Classic+. J’ai migré une première fois l’intégralité de mon installation, me perfectionnant sur quelques points au passage et découvrant de nouvelles techniques mais également de nouveaux problèmes. J’ai résilié la Dedibox SC, non sans un petit pincement au coeur.

Pendant un an environ, sur ma nouvelle Dedibox Classic+, j’ai testé de nouvelles choses, essayé de mettre en place un serveur Minecraft, un Teamspeak, testant de nouveaux scripts PhP, etc… Jusqu’au jour fatidique où, un peu fatigué à une heure avancée de la nuit, j’ai commis l’irréparable : apt-get dist-upgrade. Oui. Je l’ai fais. Sur une LTS. Certains me diront : « Pas de problème, au pire tout se passe bien et tu as upgradé ton OS ». Sauf que tout ne s’est pas bien passé. Plus de mise à jour possible, des réactions parfois bizarres, des tentatives de réparation avec divers tutoriels trouvés au fin fond de l’Internet, rien n’y fera je ne récupérerais jamais mon erreur. J’ai donc une fois de plus commandé un serveur dédié et me suis lancé dans une nouvelle migration vers une Dedibox Classic+ Gen 2. Nous sommes fin décembre 2013.

Aujourd’hui, à 7h45, la migration est achevée, mes sites et services à nouveau en ligne et il est temps pour moi de résilier la Dedibox Classic+. Je rempli donc tranquillement le formulaire de résiliation en indiquant comme raison :

Résumé : « Plus d’utilité »

Commentaire : « Migration vers le nouveau serveur terminé, je n’ai plus l’utilité de ce serveur ».

13h30, coup de téléphone : S. de Online.net qui m’appelle pour me demander si la migration s’est bien passée. On discute pendant 2 min le temps pour moi de lui dire que j’apprécie l’attention (en fait je suis sur le cul et j’ai du mal à aligner 2 phrases) et que ce genre de chose est assez exceptionnel. Bouquet final : il me laisse son numéro direct « en cas de question ou de problème ».

Stickers Online.net Dedibox

Si vous vous demandiez pourquoi aujourd’hui je ne jure que par Online.net, alors ne cherchez plus, je viens de vous l’expliquer. Certains concurrents devraient prendre exemple, cela m’aurait évité d’attendre 4 jours pour avoir une réponse à un ticket d’incident…

Sponsornot : Zéro collaboration

Read More

Avant même de songer au type de distribution Linux et d’ensemble logiciel pour lesquels vous aller opter, il faut d’abord définir quels sont vos besoins en terme de puissance, d’espace de stockage et de fonctionnalités afin de choisir un serveur dédié qui soit adapté à l’utilisation que vous allez en faire et à votre projet…

Tout d’abord, il faut commencer par réfléchir à la question suivante : « quel usage vais je faire de mon serveur ? ». Je précise que l’objectif final de cette grande série d’articles est de monter un serveur Linux fournissant divers services. Plusieurs possibilités s’offrent à vous :

– Hébergement de site web (Apache / MySQL)

– Serveur FTP

– Serveur Teamspeak3 / Mumble

– Serveur de jeu (Minecraft / CSS / etc…)

– Cloud

– Tout ça à la fois

Une fois que vous avez ciblé l’usage, il suffit d’y adapter la dimension de votre serveur et par conséquent son coût mensuel. Voici quelques indications de tarifs en fonction de la configuration choisie, issues du site Online.net  :

Dedibox SC Gen2 Dedibox SC L Dedibox Classic+ Gen2 Dedibox LT Dedibox MD
Nano U2250 Nano U2250 Intel Xeon E3 1220 v2 Intel Xeon E3 1220 Intel Xeon E3 1240
1 Core @ 1.6 GHz 1 Core @ 1.6 GHz 4 Core @ 3.5 GHz 4 Core @ 3.1 GHz 4 Core @ 3.7 GHz
2 Go 2 Go 8 Go DDR 16 Go DDR 24 Go DDR
500 Go Hybrid + SSD 1 To Hybrid + SSD 2 x 1 To 2 x 2 To 2 x 2 To
Pas de RAID Pas de RAID RAID 0/1 Hard RAID 0/1 Hard RAID 0/1 Hard
200 Mbit/s 200 Mbit/s 300 Mbit/s 300 Mbit/s 300 Mbit/s
9.99 € HT/mois 14.99 € HT/mois  29.99 € HT/mois 49.99 € HT/mois 64.99 € HT/mois


ATTENTION : CETTE GRILLE DE CONFIGURATIONS ET DE TARIFS EST FOURNIE A TITRE INDICATIF, SEUL LE SITE ONLINE.FR FAIT FOI.

 Online.net Hebergement Serveurs Domaines

Vous souhaitez héberger quelques sites (entre 5 et 10) de taille modeste, un ftp et éventuellement un Teamspeak ou un Mumble avec un Cloud, un serveur de type Dedibox SC Gen2 devrait vous suffire. En revanche, si vous souhaitez héberger un serveur de jeu, vous devrez obligatoirement vous orienter vers un serveur de type Dedibox Classic+ Gen2 minimum si vous ne voulez pas souffrir de perturbations en cours de jeu tels que des lags ou des plantages du serveur. Ensuite, en ce qui concernent les gammes supérieures de serveur, c’est en fonction de votre budget. Plus vous pourrez débourser d’argent tous les mois, plus vous pouvez vous prendre un serveur onéreux et donc puissant ! Quoi qu’il en soit, plus le logiciel qui fera tourner votre serveur sera puissant et possédera de slots, plus vous devrez avoir une configuration puissante pour le faire tourner.

Bien évidemment, il existe des serveurs beaucoup plus onéreux que je n’ai pas jugé utile d’inclure dans ce type de dédié car de mon point de vue ils ne sont pas destiné à une usage personnel, à moins que vous n’ayez une grosse fortune, un mécène ou que la publicité vous rapporte suffisamment pour couvrir les frais !

Cas particulier : le serveur Minecraft. En effet, Minecraft avec quelques mods et une grande est relativement gourmand au niveau des ressources en particulier la mémoire vive. Par conséquent, il sera probablement plus rentable de vous orienter vers un serveur fourni par un provider tel que NitroServ, SmallMine, OMGServ ou encore VeryGames qui seront bien plus attractifs au niveau tarif qu’un serveur dédié « maison » à niveau de prestations égales (live map, joueurs illimités, taille de map illimité…).

Pour terminer, il est important de regarder la tolérance de panne. En effet, le serveur de type 1 ne possédera pas de disque dur en RAID ce qui engendrera une perte des données en cas de crash de l’un des deux disques. D’autre part, il est également primordial de penser à la sauvegarde. Ce n’est pas parce que vous louez un serveur, que les données qui y sont hébergées sont à l’abri. En cas de piratage, de mauvaise manipulation, de panne matériel ou de plantage du système d’exploitation, il est indispensable d’avoir une sauvegarde des données importantes quelque part. Sachez par exemple qu’Online mets à disposition gratuitement un espace de sauvegarde de 10Go (extensible à 200Go moyennant finances) pour toute souscription à un serveur dédié ce qui peut être un point déterminant dans le choix de votre dédié. Si l’hébergeur que vous avez choisi ne propose pas ce service gratuitement, il est probable qu’il le propose de façon payante, si ce n’est pas non plus le cas, il faudra envisager une solution de sauvegarde alternative (2ème serveur dédié à la sauvegarde du premier, téléchargement quotidien de vos sauvegardes…).

Voilà, on a fait le tour des différents points à considérer. Pour ma part, à l’heure où j’écris ces lignes, mes noms de domaines sont pour le moment enregistrés chez OVH et mon serveur dédié vous l’aurez compris est hébergé par Online. Pourquoi une séparation du fournisseur de service ? Tout simplement parce que j’ai commencé avec des hébergements mutualisés chez OVH jusqu’à ce que je me rende compte qu’un dédié me couterait moins cher que l’ensemble de mes mutualisés. A partir de ce jour là, j’ai décidé de passer sur un dédié et je suis depuis janvier 2011 un client satisfait d’Online. Je publierais d’ailleurs probablement un feedback de 3 années passées chez eux dans les semaines qui viennent.

En espérant que cet article pourra vous orienter dans le choix de votre futur serveur dédié, à bientôt pour la suite !

Sponsornot : Zéro collaboration

Read More

Bonjour à tous ! 

Premier article d’une série d’articles d’articles traitant des serveurs dédiés que l’on peut louer auprès de sociétés telles que OVH, Ikoula, Online ou encore 1and1 (mais il en existe plein d’autres).

Plus un pense bête pour me permettre de refaire rapidement ces manipulations qu’une véritable documentation, vous trouverez au fil des articles des infos, des conseils, des tutoriels surtout, pour bien démarrer avec votre serveur dédié. A l’issue de la série d’articles, vous devriez pouvoir avoir un serveur dédié installé, configuré et hébergeant Apache, MySQL, Php, FTP, Teamspeak3, Minecraft, etc… En plus de l’installation basique, les articles auront pour but de sensibiliser à la sécurité du serveur et d’aborder les différents points à prendre en compte pour limiter les risques de compromissions ou pertes de données et services. L’ensemble des tutoriels est destiné à être réalisé sous un distribution Linux Debian ou Ubuntu, mais le principe reste le même pour n’importe quelle distribution Linux. Je n’expliquerais pas tous dans les moindre détails, l’intérêt est aussi que chacun cherche un peu de lui même comment il pourrait améliorer ou adapter un point à ses besoins ou son projet.

Je mettrais à jour cet article avec les liens des différents tutoriels que j’ajouterai au fil des semaines car non, tout ne viendra pas d’un coup, ce sera une sorte de fil rouge ! Bien que c’est avec Online que je ferais l’intégralité de mes tutoriels, vous pouvez reporter l’intégralité de ces tutoriels chez Ikoula, OVH ou 1and1 !

PS : je ne me prétends pas expert loin de là, donc si vous voyez une connerie passer, hésitez pas à commenter !

 

Sommaire :

1 – Choix du serveur

Sponsornot : Sponsorisé

Read More