🗓️ Note : Cet article est une archive importée de mon ancien blog. Certaines informations peuvent ne plus être à jour.

Ou comment installer et configurer Transmission sur notre Helios 64

Cet article fait suite à cet article ci , et cet article là.

Disclaimer

Bon, je vous refais pas le topo complet mais pour faire vite et bien :
Je suis ni développeur, ni programmeur, ni informaticien, juste un ours un peu geek qui tente des trucs ; et des fois : ça marche ! Ce qui suit est le résultat de mes nombreux échecs et de ma compréhension globale du biniou. Il doit y avoir d’autres manières de faire, et peut être des trucs « mieux » ou « plus simple ». Je considère désormais que je peux me permettre de vulgariser un peu moins (je ne préciserai pas qu’il faut se connecter via SSH ou se genre de chose…) Enfin, il y a certainement des coquilles, n’hésitez pas à me faire remonter l’info.

 

Torrent

 

C’est quoi ?

Sur mon Helios64; je vais installer un serveur Torrent. Si vous ne savez pas ce que c’est, j’en ai rapidement déjà parlé ici !

 

Choix du logiciel

Il en existe une ribambelle , en voici quelques un : Deluge, qBittorent, Transmission …

Personnellement je vais choisir Transmission, parceque j’ai l’habitude de faire avec lui (c’était ça aussi sur Yunohost (cf cet article) )

 

BONUS : Ajout d’espace de stockage (facultatif)

Je ne sais pas si vous vous souvenez mais mon Helios64 contient un disque dur de 1To. J’aimerai en profiter car l’eMMC ne fait que quelques giga… L’idée c’est donc d’utiliser toute cette mémoire de stockage plutôt que de se limiter à la mémoire eMMC. Ca sera super utile pour stocker les fichiers qui seront échangé via bittorrent. Ce qui suit est fortement inspiré de ceci.

 

1 – Identifier le disque dur

On tape la commande lsblk qui doit donner quelquechose comme ça : NAME         MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda            8:0    0 931.5G  0 disk 
└─sda1         8:1    0 931.5G  0 part 
mmcblk1      179:0    0  14.6G  0 disk 
└─mmcblk1p1  179:1    0  14.4G  0 part /
mmcblk1boot0 179:32   0     4M  1 disk 
mmcblk1boot1 179:64   0     4M  1 disk 
zram0        251:0    0   1.9G  0 disk [SWAP]
zram1        251:1    0    50M  0 disk /var/log

Avec la colonne SIZE j’arrive à déterminer que mon disque dur de 1To semble être sda1. Si vous vous demandez pourquoi le 1To donne 931.5G et pas 1000 G c’est ici que ça se passe.
Si j’avais plusieurs disques, je verrai sda, sdb, sdc, etc…

 

2 – Créer la partition

Mon disque dur étant neuf, il n’a pas de partition dessus. Il faut donc la créer. On peut le faire en ligne de commande. Dans mon cas je vais taper :

fidsk /dev/sda
/!\ remplacer sda par la configuration que vous avez vous localement /!\

Puis, il faut :

• taper n pour nouvelle partition, puis entrée
• taper p pour indiquer une partition primaire, puis entrée
• taper 1 pour indiquer que c’est la première partition, puis entrée
• appuyez sur entrée à nouveau pour valider la configuration par défaut
• appuyez une nouvelle fois sur entrée pour valider la configuration par défaut (ici, on va utiliser tout l’espace disponible)
• enfin taper w pour valider l’écriture de cette nouvelle partition et appuyez sur entrée. Patientez jusqu’à ce que vous ayez à nouveau la main.

Pour plus d’informations à propos de fdisk, c’est par ici que ça se passe.

 

3 – Formater la partition

Si nécessaire, vous pouvez formater la partition :

mkfs.ext4 /dev/sda1

• ext4 correspond au format de fichier
• /!\ attention, ici je précise sda1  : sda pour le disque « sda » et « 1 » pour la premiere partition. A adapter selon votre configuration !

Plus d’information concernant mkfs c’est ici !

 

4 – Monter le disque dur

On vas d’abord créer un répertoire qui sera notre point de montage du disque dur. Pour ma part j’ai choisis /hdd mais ca peut etre /media ou meme /toto/bidule/truc/muche !

mkdir /hdd
(à adapter selon votre configuration)

Puis, on va monter le disque dur sur ce répertoire.

mount /dev/sda1 /hdd
(encore une fois : à adapter selon votre configuration ! Chez moi c’estsda1 et /hdd chez vous, ca sera peut être sdc1 et /media/documents par exemple !)

 

5 – Monter le disque automatiquement au démarrage

En cas de redémarrage, il faudra remonter le disque à la main (cf mount /dev/sda1 /hdd ) ce qui n’est pas pratique. Heureusement, on peut demander à notre machine de faire ça automatiquement pour nous à chaque démarrage.

blkid | grep "/dev/sda1:
(à adapter selon votre configuration ! C’est peut être pas sda1 chez vous…)

Cette commande devrait vous retourner quelquechose comme :

/dev/sda1:UUID="cea0b7ae-2fbc-4f01-8884-3cb5884c8bb7" TYPE="ext4" PARTUUID="34e4b02c-02"

L’UUID pour Universsaly Unique Identifier est (comme son nom l’indique) un identifiant unique pour repérer votre disque dur avec un petit nom rien qu’à lui. Et c’est avec ce nom qu’on va désigner le disque dur à la machine.

Pour ça, il faut éditer un fichier de configuration :

nano /etc/fstab
(j’utilise nano mais évidemment vous pouvez utiliser ce que vous voulez comme éditeur… Cliquez ici si vous souhaitez des informations sur nano)

Normalement, il doit y avoir déja une (ou plusieurs) lignes dans ce fichier. Il ne faut pas s’en préocupper mais simplement rajouter la ligne suivante :

UUID="cea0b7ae-2fbc-4f01-8884-3cb5884c8bb7" /hdd ext4 defaults,nofail 0 0
/!\ A adapter selon votre configuration. Il faut prendre l’UUID que vous avez généré juste avant, et remplacer /hdd par le point de montage que l’on a créé tout à l’heure.

On peut redemarrer notre machine pour vérifier que sa fonctionne. Ainsi, si vous tapez lsblk vous pourrez vérifier. Dans mon cas :

└─sda1 8:1 0 931.5G 0 part /hdd
(Dans mon cas c’est la ligne relative à sda1 qui m’intéresse. Je vois que c’est monté automatiquement sur /hdd , c’est parfait !)

6 – Créer les repertoires

Nous allons créer deux répertoires pour y déposer les téléchargements complet, et les téléchargements incomplets.

mkdir -p /hdd/downloads /hdd/downloads-incomplete


Evidemment, vous pouvez choisir les chemins que vous souhaitez. C’est à adapter selon votre configuration.

 

Installation de Transmission

Bien, maintenant, on peut rentrer dans le vif du sujet. Après une recherche sur les internets : on apprend à installer transmission avec les commandes suivantes :

sudo apt update
sudo apt-get install transmission-cli transmission-common transmission-daemon

Normalement, après l’installation, transmission se met automatiquement en marche. Sinon :

sudo systemctl start transmission-daemon

Connexion en local

Dans votre navigateur internet, vous pouvez taper votre adresse IP (prenez la votre) local suivi du port 9091 (le port utilisé par bittorrent) :

192.168.x.y:9091

Vu que l’on a rien paramétrer on doit avoir cette erreur :

Unauthorized IP Address.

Either disable the IP address whitelist or add your address to it.

If you’re editing settings.json, see the ‘rpc-whitelist’ and ‘rpc-whitelist-enabled’ entries.

If you’re still using ACLs, use a whitelist instead. See the transmission-daemon for details.

Bien, on va maintenant aller configurer le fichier « settings.json » comme on nous le demande si gentiment… Mais avant, il faut couper Transmission !

sudo systemctl stop transmission-daemon

Paramétrage

Le fichier settings.json se situe par défaut à cet emplacement :

/etc/transmission-daemon/settings.json

Si il n’y est pas, une petite recherche avec :

sudo find / -name "settings.json"

Une fois localisé on va d’abord faire une copie de sauvegarde (on sait jamais, si on fait une erreur on pourra rétablir par défaut) . Pour se rendre dans le bon répertoire :

cd /etc/transmission-daemon

Pour faire la copie de sauvegarde (le nom settings.backup est arbitraire)

cp settings.json settings.backup

Puis, on va éditer le fichier .json :

nano settings.json

 

Vous allez voir un long fichier de configuration. Attardons nous sur quelques lignes, et remplaçons les valeurs par défaut par ça : (à adapter selon votre configuration)

• Spécifions le répertoire des téléchargements :
  • « download-dir » : « /hdd/downloads »,
• Celui des téléchargements « en cours » :
  • « incomplete-dir »: « /hdd/downloads-incomplete »,
• Activons le répertoire des téléchargements « en cours » (si cette option est activé, les téléchargements se feront dans le répertoire spécifiés, et ils seront déplacés dans le répertoire des téléchargements une fois complété)
  • « incomplete-dir-enabled » : true,
• Spécifions la white list, si vous êtes dessus : vous avez le droit d’y entrer (un peu comme en boite) :
  • « rpc-whitelist »: 192.168.x.y,

On peut enregistrer et redemarrer transmission :

sudo systemctl start transmission-daemon

Et si on teste 192.168.x.y:9091 dans une barre d’adresse :

Youpi !

(Si on vous demande un login / mot de passe c’est « transmission » et « transmission » 🙂

 

Rendre Transmission acessible

Bien : là, on peut accéder à notre client depuis le réseau local. Moi, j’aimerai bien y accéder depuis n’importe où. Du coup, si vous avez suivi les épisodes précédents vous vous dites :

Ha ba facile ! Il suffit d’aller d’ouvrir les ports et de faire de la redirection comme on l’a fait avec Caddy !

…

Non !

Explications

Internet est une zone dangereuse. Le fait d’ouvrir un port, ouvre une porte vers ce monde pernicieux. Votre modem/routeur est là pour s’assurer qu’aucunes connexions de l’extérieur ne puissent facilement se frayer un chemin jusqu’à vos appareils installés sur votre réseau local. Il faut donc limiter au maximum les ports ouverts vers le monde extérieur. En aucun un port doit rediriger directement vers une application (pour des raisons de sécurité).

L’idée, c’est de tout faire transiter via le port HTTP (et tant qu’a faire HTTPS) , et de rediriger ensuite vers le port local. Ca tombe bien, Caddy sait faire ça !

Si vous souhaitez plus d’informations (en anglais) à ce sujet, je vous recommande ce post.

 

Création d’un sous domaine

Pour que ce soit bien rangé chez moi, j’ai choisis d’utiliser des sous domaines; j’aurai le site principal : « https://monsupersite.truc » et pour chaque service, un sous domaine.

• blog.monsupersite.truc
• torrent.monsupersite.truc
• rss.monsupersite.truc
• trucmuche.monsu… bref vous avez compris

Pour faire ça, ça se passe encore au niveau de votre registrar au niveau des enregistrements DNS. Il suffit de rajouter simplement autant de ligne que nécessaire selon le modéle suivant :

nom-du-sous-domaine

CNAME

10800

nomdudomaine.truc.

J’attire votre attention qu’il y a un point après « truc » !

Si on reprend notre exemple ci dessus ça donnerait :

• blog CNAME 10800 monsupersite.truc.
• torrent CNAME 10800 monsupersite.truc.
• rss CNAME 10800 monsupersite.truc.
• trucmuche CNAME 10800 monsupersite.truc.
• etc … etc…

 

Configuration de Caddyfile

On retourne configurer Caddyfile (cf la partie 2 si vous n’avez pas tout suivi…)

nano /etc/caddy/Caddyfile

On l’avait laissé dans cet état là :

[...]
monsupersite.truc

# Set this path to your site's directory.
root * /var/www/html

# Enable the static file server.
file_server
[...]

Déja, on va rendre ça un peu plus présentable. On peut utiliser des { et des } (mais c’est pas obligatoire) et retirer les # :

[...]
monsupersite.truc {
 root * /var/www/html
 file_server
}
[...]

Maintenant, on va rajouter notre nouveau sous domaine :

[...]
monsupersite.truc {
root * /var/www/html
file_server
{
torrent.monsupersite.truc{
reverse_proxy 192.168.x.y:9091
}
[...]

Bon, je le dit une derniere fois : à adapter selon votre configuration !

On enregistre, et on recharge caddy avec ces nouveaux paramétres !

cd /etc/caddy
caddy reload

Voilà, et là normalement https://torrent.monsupersite.truc est accessible et vous renvoie sur Transmission !

 

Sécuriser un peu tout ça…

Actuellement, bien qu’on soit en HTTPS avec un reverse proxy via Caddy (ce qui fait qu’on expose pas directement les ports de Transmission) , c’est quand meme pas folichon en terme de sécurité.

En effet, n’importe qui peut accéder à votre client torrent et faire ce qu’il veut avec. Et ça, on veut pas !

Bien sur, vous allez me dire que c’est sécuriser par un login et un mot de passe. Qu’il suffit de modifier ceux par défaut (pour rappel transmission et transmission) . On peut le faire via le fichier settings.json c’est vrai.

Néanmoins, si quelqu’un de mal attentionné est déterminé, il peut « forcer » le passage en essayant toutes les combinaisons possibles. C’est relativement simple à faire, avec un petit programme qui va tenter toutes les combinaisons possibles. Ca peut être assez long (si vous avez un mot de passe robuste, j’en parlais ici.) mais quand meme, au bout d’un moment ca peut casser. Et puis, ca va aussi saturer et créer un joli bouchon devant chez vous.

… avec Fail2ban !

L’idée, c’est de rajouter une couche de sécurité avec Fail2ban. C’est un petit programme qui va scruter les logs de connexion, et qui va bannir quiconque ayant une activité suspecte. Par exemple, si il voit une connection qui essaye de se connecter 5 fois d’affilés en se trompant de mot de passe.

Il faut savoir que j’ai pas mal galéré à mettre ça en place. Je vous épargne mes périgrinations mais sachez que Transmission génére des fichiers de log, mais pas par rapport aux connexions au client. (ou alors : j’ai pas trouvé !). Pour contourner le probléme, on peut faire en sorte que l’authentification se fasse par Caddy plutot que directement dans Transmission. Caddy lui, en tant que serveur web, peut générer des logs de connection , et ce sont ces derniers qui seront analysé par fail2ban pour mettre les méchants à la porte. Vous êtes pret ? C’est parti !

Disclaimer

Je ne suis pas un expert en sécurité informatique. Ce qui suit n’est que le résultat de mes bidouilles personnelles. Il y a (peut etre) des failles et ca ne garantit en rien une quelconque inviolabilité de votre systeme. Vous utiliserez donc cet article en votre âme et conscience sans garanti de résultat ! Et moi, je ne pourrai pas être tenu responsable ! Vous voilà averti 🙂

1 – Autoriser toutes les connexions dans Transmission

Pour ça, on retourne couper le service pour éditer le fichier settings.json :

sudo systemctl stop transmission-daemon
nano /etc/transmission-daemon/settings.json

On s’intéresse à trois lignes en particulier :

1. "rpc-authentication-required": false,
2. "rpc-whitelist-enabled": false,
3. "rpc-host-name":"torrent.monsupersite.truc"

La ligne 1 et 2 permettent de désactiver l’authentification et de permettre à quiconque d’atteindre le service.

Si on ne précise pas la ligne 3, vous aurez une erreur de ce type à la prochaine connection sur votre client : (je sais, j’ai tenté 😀 )

421: Misdirected RequestTransmission received your request, but the hostname was unrecognized.To fix this, choose one of the following options:Enable password authentication, then any hostname is allowed.Add the hostname you want to use to the whitelist in settings.If you’re editing settings.json, see the ‘rpc-host-whitelist’ and ‘rpc-host-whitelist-enabled’ entries.This requirement has been added to help prevent DNS Rebinding attacks.

On peut relancer le service, faire un test, mais recouper le tout de suite aprés parceque c’est pas sécuriser donc on va pas laisser la porte ouverte !

 

2 – Demander à Caddy de s’occuper de l’authentification

Attention d’aprés la documentation officielle de Caddy :

Notez que l’authentification de base n’est pas sécurisée sur un HTTP ordinaire. Faites preuve de discernement lorsque vous décidez ce que vous voulez protéger avec l’authentification de base HTTP.

2.1 Générer le hash du mot de passe

Pour des raisons de sécurité évidente, le mot de passe que l’on va utiliser pour protéger transmission ne sera pas écrit « en clair » dans Caddyfille mais uniquement son hash.
Pour générer un hash il suffit de taper :

caddy hash-password

Puis de suivre les instructions à l’écran (caddy vous demandera de taper votre mot de passe deux fois) ; à la suite de quoi vous obtiendrez le hash de votre mot de passe. Ca ressemble à un truc comme ça :

JDJhJDE0JC5idEs0WFp5c0JodWxRQnRxZUpNWC41TndIZHhHdGs4LmRXb0dNc2lmM2pDMHpnUWxMZU5P

Je vais encore insister sur ce point : utilisez un mot de passe robuste.

2.2 Editer Caddyfile pour ajouter basicauth

nano /etc/caddy/Caddyfile

On va modifier la partie qui concerne transmission :

torrent.monsupersite.truc {
basicauth /* {
toto hash-du-mot-de-passe
}
reverse_proxy 192.168.x.y:9091
}

Vous remplacer « toto » par le login que vous souhaitez, et le « hash-du-mot-de-passe » par ce qu’on a obtenu précédemment.

Lien vers la doc officielle à propos de basicauth.

2.3 Editer Caddyfile pour générer des logs

Maintenant, on va pouvoir rajouter la partie qui va générer les logs. (Lien vers la documentation officielle concernant log) . Voici ce qu’on rajoute (en gras) :

torrent.monsupersite.truc {
basicauth /* {
toto hash-du-mot-de-passe
}
log {
 format single_field common_log
 output file /var/log/caddy-torrent.log {
  roll_size 20MiB
  roll_keep 3
  roll_keep for 48h
}
}
reverse_proxy 192.168.x.y:9091
}

• log permet de signifier qu’on souhaite des logs
• format single_field permet de signifier qu’on souhaite que chaque log tienne sur une seule ligne
• common_log permet de signifier une certaine syntaxe du log. Ca sera trés utile par la suite.
• output file /var/log/caddy-torrent.log permet de signifier qu’on veut sauvegarder ses logs dans un fichier . Le chemin et le nom du fichier est à votre discrétion
• roll_size 20MiB signifie que le fichier log n’excédera pas 20 méga.
• roll_keep 3 signifie qu’on gardera 3 fichiers log. (Dés que ca dépasse 20 méga on en crée un nouveau, et on garde 3 en faisant un roulement).
• roll_keep for 48h signifie qu’on garde ses fichiers au maximum 48h.

Ce sont des réglages « au pif » qui me paraisse bien vu que Fail2ban va regarder ce qui se passe dans les logs presque en temps réel.

2.4 Relancer Caddyfile pour appliquer ses mises à jour

cd /etc/caddy/Caddyfile
caddy reload

2.5 Relancer Transmission (vu que maintenant il est « protégé »)

sudo systemctl stop transmission-daemon

2.6 Etudier le fichier de log

Essayons de nous connecter à notre client, en utilisant des mauvais mot de passe puis en utilisant le bon mot de passe. Ca va permettre de générer quelques logs. Puis, allons étudier ces derniers : (on a définit le chemin précdemment dans le Caddyfile)

nano /var/log/caddy-torrent.log

Voilà le genre de chose que vous devriez obtenir :

On remarque quoi ? Que les premiers essais sont tous des échecs (j’ai volontairement mis le mauvais mot de passe). En revanche, on voit sur la derniere ligne que l’utilisateur « bob » a réussi à se connecter (là, j’avais mis les bons identifiants).
On constat que sur les échecs, on obtient à chaque fois l’erreur 401. C’est ça qu’on va traquer avec Fail2ban.

 

3 – Fail2ban

3.1 Installer Fail2ban

sudo apt-get update && sudo apt-get install fail2ban

3.2 Premier lancement de Fail2Ban

Lancer le service fail2ban :

systemctl start fail2ban

Faire en sorte qu’il démarre automatiquement :

systemctl enable fail2ban

Et enfin on peut vérifier son statut (c’est à dire qu’il est lancé)

fail2ban-client status

Normalement, vous aurez comme retour quelque chose comme ça (de mémoire, je crois que fail2ban se lance par défaut avec la jail sshd active) :

Status
|- Number of jail:	1
`- Jail list:	sshd

 

3.3 Créer notre propre règle

Si vous souhaitez creuser le sujet en profondeur  c’est ici que ça se passe.

Le principe de fail2ban est simple mais j’ai été dérouté au début. Les fichiers de configurations sont normalement situés dans /etc/fail2ban/

Le fichier jail.conf contient toutes les règles de bannissements par défaut. Il est fortement conseiller de ne pas y toucher. Les règles dans ce fichier sont toutes désactivées. (Vous pouvez quand meme le consulter à des fins d’informations / d’apprentissage)

On peut alors soit créer notre propre fichier jail.local dans lequel on viendra activer ou non les règles par défaut (voire même créer nos propres régles) ou créer un fichier dans le répertoire jail.d ; c’est cette option que je vais choisir.

Allons dans le dossier jail.d et voyons voir ce qu’il contient

cd /etc/fail2ba/jail.d && ls

Il y a (chez moi en tout cas) déja un fichier : defaults-debian.conf . Editons le.

nano defaults-debian.conf


Par défaut, il contient une seule régle :

[sshd]
enabled = true

Fail2ban va considérer le enabled = true puis considérer tout ce que contient le fichier contenant les régles : jail.conf

On reparlera de ssh plus tard, en attendant, nous allons paramétrer un peu en ajoutant les régles de banissements un peu plus poussives que celle par défaut :

[DEFAULT]
# les ip suivant seront ignorés (la plage d'ip locaux de 192.168.1.1 à 192.168.1.10, ainsi que mon IPv4 et IPv6 pour éviter de m'auto-ban)
ignoreip = 192.168.1.1/10 11.22.333.444 2000:111:222:333:444:5555:666

# Regle de banissement : Si 3 essais raté 
max retry = 3 
# sur 10 minutes (600 secondes) 
findtime = 600 
# alors ban 24 heures (86400 secondes)
bantime = 86400

Puis, on va créer une règle pour transmission, car elle n’existe pas dans les configurations par défaut.

[transmission]
enabled = true
filter = transmission
logpath = /var/log/caddy-torrent.log
port = 80,443

• enabled = true pour signifier qu’on active la règle
• filter = transmission le nom du filtre (on va le créer après)
• logpath = /var/log/caddy-torrent.log le chemin vers le log généré par caddy
• port = 80,443 les ports à écouter (ici HTTP et HTTPS les seuls ouverts vers l’extérieur)

 

3.4 Créer notre propre filtre

Les filtres sont situés dans le dossier filter.d ; on va y créer un fichier que l’on appellera « transmission » conformément a ce qu’on a spécifier précédemment.

nano /etc/fail2ban/filter.d/transmission.conf

Les filtres, sont en fait des … des… regex.

Si vous ne savez pas ce que c’est , je vous renvoie à cet article qui est plutôt bien fait (et ca m’évitera de m’éterniser sur ce sujet). Mais pour aller vite, ca permet de trouver rapidement des chaines de caractéres dans un texte. Nous, dans nos logs, on veut trouver une chaine de caractére qui finit par « 401 » ; puis de déterminer dans cette ligne de caractére l’adresse IP.

Pour m’aider dans la rédaction du regex qui-va-bien, je me suis aidé de https://regexr.com/ qui permet de tester des regex sur un texte. J’ai donc coller là dedans mon extrait de log, et commencé à faire des tests.

Voilà, sur ce petit essai, en tripatouillant quelques dizaines de minutes, on arrive a trouver le bon regex (à savoir : – – \[.*\] « .* » 401 . ) Avec ça, on arrive à filtrer les lignes où la connection échoue.

Du coup, on peut retourner dans notre fichier conf’ :

nano /etc/fail2ban/filter.d/transmission.conf

[Definition]
failregex= <HOST> - - \[.*\] ".*" 401 .

On rajoute <HOST> pour spécifier à fail2ban que le morceau qui reste (si vous reprenez le screenshot au dessus, vous remarquez bien que l’IP n’est pas en surbrillance)  est l’IP à bannir.

Il n’y a plus qu’a enregistrer tout ça.

3.5 Tester le filtre

Fail2ban posséde un outil pour tester notre filtre avant de le lancer « officiellement » dans la nature. C’est l’outil fail2ban-regex  . Voilà la syntaxe :

fail2ban-regex [OPTIONS] <LOG> <REGEX> [IGNOREREGEX]

Je vous laisse regarder dans l’aide de fail2ban pour savoir quelles options on peut spécifier. Nous, on a simplement spécifier le chemin du log, et le chemin de notre filtre (regex)

fail2ban-regex /var/log/caddy-torrent.log /etc/fail2ban/filter.d/transmission.conf

 

3.6 Relancer Fail2ban

sudo fail2ban-client reload

 

3.7 Verifier l’état

sudo fail2ban-client status
devrait vous retourner :

Status
|- Number of jail: 2
Jail list: sshd, transmission

On peut également vérifier l’état d’une jail en particulier :

sudo fail2ban-client status transmission
Ce qui devrait nous retourner :

Status for the jail: transmission
|- Filter
|  |- Currently failed:	1
|  |- Total failed:	1
|  `- File list:	/var/log/caddy-torrent.log
`- Actions
   |- Currently banned:	1
   |- Total banned:	1
   `- Banned IP list: xx.xxx.xxx.xxx	
`- Jail list:	sshd

Sur ce extrait, on voit qu’une IP (caviardée) a été banni . C’est simple, j’ai fait un test avec un autre ordinateur (qui n’est pas sur mon réseau local car rappelez vous on a mis des régles pour ignorer que l’on s’auto-ban) et au bout de 5 échec consécutif : poof ! On est banni pour 24 heures.

Ca fonctionne !

4 – Continuer de garder un oeil

Comme j’a l’ai déja dit : je ne suis pas expert sur le sujet. Et se baser sur 6 lignes de log pour certifier une regex, c’est pas la joie. Dans les prochains jours / semaines, je vous recommanderai d’etre trés attentif à votre fichier de log pour voir si des petits malins ne passeraient pas à travers les mailles du filet.

Conclusion

Ca marche, on est content, on va pouvoir partage des fichiers via ce fabuleux protocole bittorrent ! Pourquoi pas des distributions linux ?
Pour aller plus loin, on peut rajouter un lien dans notre code HTML !

nano /var/www/html/index.html

Et on bricole quelquechose comme ça :

<!doctype html>
<html lang="fr">

    <head>
        <meta charset="utf-8">
        <title>Mon super site</title>
        <meta name="description" content="The HTML5 Herald">
        <meta name="author" content="SitePoint">
    </head>

    <body>
        <h1> youpikay ! </h1>
        <p>
            <a href="https://torrent.monsupersite.truc"> Transmission c'est par ici ! </a>
        </p>
    </body>
</html>

 

Et voilà le travail 🙂

 

Et aprés ?

Bon il manque encore pas mal de choses… :

1. S’arranger pour que caddy démarre tout seul (actuellement, c’est pas le cas)
2. Améliorer la sécurité du serveur
3. Permettre un accés SSH depuis l’extérieur
4. Continuer de rendre le serveur carrément trop cool

Merci d’avoir lu cet article, j’espére qu’il vous a plu et que vous avez appris des choses. N’hésitez pas si vous avez des remarques à faire , ou si j’ai laissez un cadenas sur une porte ouverte avec la fenêtre cassé à coté.