Raspberry pi : ze topic !

:hello: Bienvenue sur ce topic dédié au Raspberry Pi ! :hello:

Attention, ce topic est en construction.

Sachez également que je n’ai pas la prétention d’avoir des connaissances illimitées en ce qui concerne Linux, si vous remarquez des choses qui vous paraissent incohérentes n’hésitez pas à m’en faire la remarque pour que je puisse corriger.

Note aux débutants : si tenter l’aventure Raspberry / Linux vous tente, pour par exemple monter vous aussi un serveur (ou en faire tout autre chose :wink: ), je vous recommande fortement ce cours, notamment à partir de la partie 2 pour la console (que je vais utiliser tout au long de ce topic).

Notez également, que dans la mesure du possible (je vais essayer de ne pas trop alourdir les choses non plus, je risque déjà de faire un maxi pavé :ane: ) j’expliquerai le plus possible les commandes que j’utiliserai.
Si quelque chose ne parait pas clair, n’hésitez pas à me le signaler pour que j’améliore les choses, ce topic étant avant tout votre topic. :slight_smile:

[b]Sommaire

  1. Présentation de la bête (le matos).

  2. Que peut-on en faire ?

  3. La distribution Raspbian (Debian)

3 A) Installation et configuration d’un serveur Lighttpd.

3 B) Installation et configuration d’un VPN. (à venir)

  1. La sécurité.

  2. Le monitoring et autres services. (en cours de construction)

  3. L’overclocking. (à venir)[/b]
    Edité le 05/06/2013 à 11:57

1) Présentation de la bête (le matos).

Le Raspberry pi est un mini ordinateur tout ce qu’il y a de fonctionnel destiné aux bricoleurs et curieux ou aux développeurs, il est équipé d’un processeur ARM et de 512 MO de RAM dans sa dernière version.

http://chezjuju.123.fr/vrac/raspi.jpg

Vous pouvez vous rendre compte de sa (petite) taille sur cette photo, sachez que la règle est gradué en cm. :smiley:

Voyons ses caractéristiques de manière détaillée (version 512MO):

Système

SoC (System on a Chip : Broadcom BCM2835.
CPU ARM1176JZF-S core ARM11 @ 700MHz (overclockable).
GPU : Broadcomm VideoCore IV, prise en charge OpenGL ES 2.0, support de la HD 1080p.
RAM : 512 MO SDRAM, partagée avec le GPU (possibilité de modifié la quantité allouée au GPU).
RTC : Le Raspberry Pi ne comporte pas d’horloge RTC, ce qui implique une connection à un serveur NNTP ou l’utilisation d’une horloge externe pour qu’il dispose de l’heure).

Entrées / sorties

USB : 2 ports USB 2.0
Sorties Video et audio : Composite, HDMI et jack 3.5 mm (stéréo)
Port GPIO (interface programmable que l’on peut utiliser pour commander toute sorte de périphériques)
Port Ethernet 10/100 Mbps
Alimentation via un port Micro USB (700mA, sous 5volts, soit 3.5 Watts).
Lecteur de cartes SD (support de la norme SDHC).

2) Que peut-on en faire ?

Eh bien, la réponse va être très simple : A peu près tout !

Les utilisations possibles du Raspberry Pi ne manque pas, rien n’empêche de l’utiliser comme un serveur Web, d’en faire un VPN, un serveur Mail, FTP, une petite machine multimédia pour lire du contenu sur sa TV depuis le réseau, une machine permettant l’émulation d’anciens jeux, etc …

Notez toutefois une limitation dûe à son architecture ARM : Il sera impossible de le faire fonctionner sous Windows.
Ceci étant, cette limitation n’a rien de dramatique, il est effectivement possible de faire énormément de chose avec les OS le supportant, dont GNU / Linux (qui sera abordé dans ce sujet).

Pour ma part, dans le cadre de ce sujet, j’ai choisi de l’utiliser en tant que serveur web (avec Apache) pour tester les modifications de mon site perso (c’est mieux de tester avant de les mettre en prod :ane: ), dans le futur j’installerai probablement d’autres fonctionnalités (la mise en place d’un serveur VPN est prévue).

3) La distribution Raspbian (Debian)

La distribution Raspbian est un portage de la distribution Debian sur le Raspberry.
Il existe une image prête à l’emploi qu’il suffit de télécharger et d’installer (attention, il ne s’agit pas d’une simple copie de fichiers) sur une carte SD, pour récupérer cette image ça se passe par ici.
Lisez bien les instructions (simples) pour installer tout ça.

Lors du premier démarrage un assistant est lancé pour vous aider dans la configuration de base du Rapsberry Pi. :slight_smile:

Si jamais vous souhaitez le relancer pour modifier quelque chose, ou avoir accès aux paramètres d’overclocking (nous verrons cela en détails un peu plus loin), il suffit de taper la commande suivante dans la console Linux (j’utiliserai les termes GNU / Linux, Linux et Debian au long de ce topic pour désigner la distribution Debian adapté au Raspberry) :

sudo raspi-config

Notez que l’utilisateur par défaut créé pour cette distribution est : pi
Avec pour mot de passe raspberry
Notez bien que si vous souhaitez rendre accessible à distance il est impératif de modifier au moins le mot de passe.

Notez également que par défaut le compte root est désactivé, si vous souhaitez toutefois l’activez vous pouvez à l’aide de la commande :

sudo passwd

Un mot de passe pour le compte root vous sera alors demandé.
Sachez aussi qu’il est tout à fait possible de fonctionner sans compte root, la commande sudo permettant de lancer une commande avec les privilèges super utilisateurs.

Je rappelle d’ailleurs qu’il est toujours déconseillé de se loguer avec le compte root, une mauvaise manipulation pouvant potentiellement endommager le système.

Pour terminer le rapide coup d’oeil sur le système fourni par défaut, sachez que le serveur SSH est installé par défaut, permettant donc de se connecter au Raspberry Pi depuis le réseau, une interface graphique est également fournie, mais je ne l’aborderai pas ici.

3 A) Installation et configuration d’un serveur Lighttpd.

[b]Avertissement: Ce qui est indiqué dans ce topic, concernant la mise en place d’un serveur Lighttpd n’est pas forcément recommandé en production, je rappelle qu’il s’agit pour moi de mettre en place un serveur de test, mais en aucun je n’ai la prétention de présenter une mise en place pour répondre à des besoins professionnels.

Si toutefois vous remarquez des incohérences ou des choses qui vous semblent fauusses, merci de me l’indiquer pour que je puisse corriger[/b]. :slight_smile:

Il est préférable d’utiliser Lighttpd sur un Raspberry Pi plutôt qu’Apache, car ce dernier est plus gourmand en ressources matérielles.

Tout d’abord, une petite présentation : Lighttpd, qu’est-ce que c’est?

Tout comme Apache, il s’agit d’un serveur Web HTTP et HTPPS (SSL), il est certes moins utilisé qu’Apache, mais tout de même très répandu.

Installation de Lighttpd et de MySQL.

Note : Sous Debian, j’ai l’habitude d’utiliser aptitude comme gestionnaire de paquets, si vous préferez utiliser apt-get, je conseille de continuer à l’utiliser.
Il est en effet conseillé de ne pas utiliser les deux conjointement, leur méthode de gestion des dépendances étant différentes, celà pour éventuellement générer ldes problèmes.

sudo aptitude install lighttpd lighttpd-doc mysql-server-5.5 php5-cgi php5-gd php5-mysql

L’installation ne comporte aucune difficulté particulière, mysql vous demandera juste le mot de passe root MySQL.

L’installation terminée, il reste a activer le module fastcgi de lighttpd pour permettre entre autres l’utilisation de PHP :

sudo lighty-enable-mod fastcgi

Notez également qu’il faut parfois ajouter ce qui suit au fichier de config de lightpd ( /etc/lighttpd/lighttpd.conf ) pour éviter d’avoir une erreur 403 lorsque l’on tente d’accéder à une page php:


fastcgi.server = ( ".php" => ((
"bin-path" => "/usr/bin/php5-cgi",
"socket" => "/tmp/php.socket"
)))

Au niveau configuration minimale, il me faut aussi vous signaler que je modifie systématiquement l’emplacement du dossiers des sites hébergés par lighttpd.

Ils sont situés par défaut à l’emplacement suivant :

/var/www

Perso, je préfère les déplacer dans le dossier :

/srv/www/

Il faut donc modifier cette ligne dans le fichier de config de lighttpd :

server.document-root		= "/var/www"

Notez qu’il vous faudra créer le dossier www, ce qui se fait avec la commande suivante :

sudo mkdir /srv/www

Je reviendrai plus en détails sur la configuration de lighttp plus tard, n’oubliez pas qu’il s’agit uniquement ici d’une configuration minimale.

Notez deux choses :

Il est possible de vérifier si la syntaxe du fichier de config de lighttpd est bonne, ça évite toujours un message d’erreur au démarrage du service, avec la commande :

lighttpd -t -f lighttpd.conf

Pour rédémarrer lighttpd (indispensable pour qu’il prenne vos modifs en compte), il faut utiliser la commande suivante :

sudo service lighttpd restart

Retrouver l’installation et la configuration d’Apache

A propos de sécurité, il est important de configurer un minimum MySQL pour éviter de laisser des failles de sécurité aussi importantes qu’il y a de trous dans un morceau de gruyère. :ane:

La première chose à faire à ce propos est de lancer la commande :

mysql_secure_installation

Le mot de passe root mySQL que vous avez défini sera demandé, ensuite répondez y à toutes les questions posées, sauf peut être la première si vous souhaitez ne pas changer le mot de passe root MySQL.

Voici quelles actions seront effectuées :

changer le mot de passe root
supprimer le compte anonymous
désactiver la connexion à distance du compte root mysql
supprimer la base de test
recharger les privilèges

Notez, que si vous utilisez SSH pour vous connecter à votre Raspberry, le fait que la connexion à distance du compte root MySQL soit désactivée ne posera aucun problème spécifique.

Il nous reste toutefois a installer un site web sur notre serveur tout neuf. ^^)

Perso, ce sera un blog de type wordpress.

Avant de faire l’install proprement dite (ce n’est pas très compliqué, vous verrez), on va déjà créer un dossier pour stocker ledit contenu. :slight_smile:

Avec la commande suivante :

sudo mkdir /srv/www/blog

Ensuite passons à wordpress.

Perso j’ai choisi d’aller le récupérer avec links2, un navigateur internet en mode console (oui, donc en mode texte :ane: ).

L’adresse de la page des téléchargements est fr.wordpress.org…

Ensuite, une fois l’archive récupérée (préferez le .tar.gz, on est sous Linux mille millions ! :stuck_out_tongue:

On la décompresse et la dézarchive (oui, je ne sais pas si ce terme existe dans le dictionnaire :paf: ) les fichiers.

sudo tar -xvzf wordpress-3.5.1-fr_FR.tar

On déplace le dossier du blog dans son emplacement définitif

sudo mv wordpress /srv/www/blog/

Ensuite on règle les droits d’accès au dossier.
c’est important, parce que sinon on sera bloqué pour installer wordpress.

Il faut tout d’abord passer le compte utilisateur d’Apache comme propriétaire des fichiers, ce qui se fait via la commande :

sudo chown -R www-data /srv/www/blog

Notez que pour ce point, je ne suis pas très sûr de la procédure à suivre, je vais essayer de me renseigner sur ce point et si vous avez une piste, n’hésitez pas à m’en faire part.

[b] En revanche attention, il ne faut jamais attribuer des droits 777 (droits d’accès complets y compris en écriture pour TOUT LE MONDE), car c’est une grosse faille potentielle).

Donc, droit 755 (modification accordée au propriétaire des fichiers et lecture / execution pour les autres) de rigueur :[/b]

sudo chmod -R 755 /srv/www/blog

Ensuite on créé la base de données MySQL :

mysql -u root -p

On se retrouve alors sur l’invite de commande de Mysql et on saisit (n’oubliez pas le point virgule à la fin de la ligne) :

CREATE DATABASE blog_db;

Mysql doit affcher un message comme quoi l’opération s’est bien passée.

Cette fois on va créer un utilisateur dédié à notre blog et lui affecter les droit uniquement sur la base de donnée concernée.

Il est en effet HORS DE QUESTION d’accéder à un serveur MySQL depuis une web application avec le compte root MySQL, car en cas de faille dans la webapp, le risque que la totalité des bases MySQL soit exposée est bien réel.

Pour ce faire, on va utiliser la commande :

GRANT ALL PRIVILEGES ON blog_db.* TO 'Utilisateur'@'localhost' IDENTIFIED BY 'mot de passe' WITH GRANT OPTION;

Gardez bien en tête (ou notez les) le nom d’utilisateur et le mot de passe ainsi créés, vous en aurez besoin lors de l’installation de la webapp.

On peut alors quitter mysql avec la commande :

exit

On se retrouve alors sur la ligne decommande Linux.

Je me suis rendu compte d’un point très important concernant Wordpress : L’adresse de son installation est une adresse absolue dans la base de données MySQL, ce qui fait que ça possera des problèmes de chargements incomplets s’il a été installé à partir d’une IP locale et que vous y accédez depuis une ip public.
Pour vous éviter bon nombre de soucis, je vous recommande de recourir à un service de type no-ip.com qui permet même avec une ip public flottante d’avoir une adresse fixe
.

Maintenant il ne reste plus qu’a lancer l’installation de worpress, ce qui se fait depuis un navigateur web avec l’adresse:

http://nom de domaine/blog/

Le reste arrivera plus tard.
Edité le 25/11/2014 à 22:05

4 ) La sécurité (en cours de construction)

En matière de serveur, s’il est un point qui est essentiel, il s’agit bien de la sécurité.

Configurer IPTables

Pour commencer nous allons voir comment régler le pare-feu integré à Linux, Iptables.
Notez que ce que je vais indiquer n’est jamais qu’un exemple basé sur le fait que mon serveur sert de serveur http et ftp ou https pour le moment.
Je peux être amené a faire évoluer cette section par la suite.

Je ne vais pas non plus présenter tout ce qui est possible de faire avec iptables, sachez que c’est un pare-feu très puissant, dont le paramétrage peut se révéler complexe.

Normalement aucune règle ne doit être définie pour iptables -L (rien n’est configurer par défaut)

On va donc créer un script Bash dans lequel on va définir les règles.
Attention si vous êtes connecté via SSH à votre Pi, n’exécuter surtout pas le script avant d’avoir ajouter la règle permettant de laisser le port SSH ouvert, sinon, il va vous falloir brancher votre clavier et votre écran pour récupérer la situation.

Pour créer / éditer le script :

sudo nano /etc/init.d/firewall

Ensuite nano se lance, voici ce qu’il faut y spécifier :


#!/bin/sh

#Suppression des règles précédentes
iptables -t filter -F
iptables -t filter -X

# Définition des blocages pour les entrées et le suivi et autorisation des sorties
iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT ACCEPT

# Conservations des connexions déjà établies
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

# Autorisation du loopback
iptables -t filter -A INPUT -i lo -j ACCEPT
iptables -t filter -A OUTPUT -o lo -j ACCEPT

# Autorisation du port HTTP (80)
iptables -t filter -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 80 -j ACCEPT

# Autorisation du port SSH (22)
iptables -t filter -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 22 -j ACCEPT

# Autorisation du Ping et du Pong ^^
iptables -t filter -A INPUT -p icmp -j ACCEPT
iptables -t filter -A OUTPUT -p icmp -j ACCEPT

# Regles pour éviter (en partie) les attaques de type Déni de Service
iptables -A FORWARD -p tcp --syn -m limit --limit 1/second -j ACCEPT
iptables -A FORWARD -p udp -m limit --limit 1/second -j ACCEPT
iptables -A FORWARD -p icmp --icmp-type echo-request -m limit --limit 1/second -j ACCEPT

# Limitation (loin d'être totale) du scan de ports
iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j ACCEPT

Ensuite il faut lancer le script (je rappelle qu’il s’agit d’un script minimal a compléter selon vos propres usages, notez que j’ai ajouté la règle pour autoriser SSH quelque soit l’adresse d’où on se connecte).

sudo chmod +x /etc/init.d/firewall
sudo /etc/init.d/firewall

Attention, si vous obtenez un message d’erreur, il est causé par une erreur de syntaxe (même un espace mal placé suffit) dans votre fichier de config d’Iptables (celui que je vous ai indiqué ne pose normalement pas de soucis).

sudo update-rc.d firewall defaults

Vous obtiendrez un warning, provoqué par le fait que je n’ai pas ajouté tout ce qui est habituellement indiqué dans un script qui se lance au démarrage, sachez que celà ne provoque aucun problème de fonctionnement.

Le pare-feu ainsi configuré limite sérieusement les risques d’intrusions et de scan des ports sur les ports fermés.

En revanche, dans le cas de notre serveur, le port 80 (hhtp) et ssh (22 pour l’instant) se retrouvent exposés a d’éventuelles tentatives d’intrusions.

Nous allons voir quels moyens s’offrent à nous pour renforcer la sécurité.

Bloquer les tentatives de scans de port avec Portsentry

Portsentry est un programme qui fonctionne en tant que service (donc qui fonctionne en permanence) dans le but de bloquer les tentatives de scans de ports (les scans de ports permettent de détecter d’éventuelles faiblesses au niveaude la configuration d’une machine).

Son installation est extremement simple :

sudo aptitude install portsentry

Portsentry nous averti lors de son installation qu’il ne bloque rien par défaut.

Il nous est indiqué qu’il existe deux manuels que l’on peut consulter avec les commandes suivantes :

man portsentry
man portsentry.conf

Passons ensuite à la pahse de configuration.

On va utiliser Portsentry en mode automatique, c’est à dire qu’il va se charger lui même de vérifier ce qui arrive sur les ports réseau, on peut également spécifier soi-même quels ports surveiller, mais je n’aboderai pas ce point, du moins pour le moment.

Pour configurer Portsentry pour le mode automatique c’est simple, on accède d’abord au fichier de config :

sudo nano /etc/default/portsentry

On remplace ensuite :


TCP_MODE="tcp"
UDP_MODE="udp"

par :


TCP_MODE="atcp"
UDP_MODE="audp"

On redémarre ensuite le service de Portsentry (j’imagine que vous devez vous douter de la commande à force :stuck_out_tongue: )

sudo service portsentry restart

Ensuite, on peut tester que Portsentry remonte bien les tentative de scan de port avec la commande nmap.

Dans le cas où elle n’est pas installée, utilisez aptitude ou apt-get pour le faire, je pense que vous devez savoir faire, à force :ane: ), mais je suis bon prince, je vous note quand même la commande. :slight_smile:

sudo aptitude install nmap

Ensuite on lance un test avec la commande :

nmap -v -PN -p 0-2000,60000 x.x.x.x

Ou x.x.x.x représente l’adresse IP de votre Pi, sachez qu’il est d’ailleurs possible de lancer la commande depuis le Pi lui-même (c’est d’ailleurs ce que j’ai fait).

nmap nous informe de quels ports sont ouverts, mais ce n’est pas tellement ça qui nous intéresse en fait, on aimerait surtout vérifier que portsentry récupère bien les scans de ports.

Pour ce faire, il faut ouvrir le fichier log /var/log/syslog

Pour se faire :

sudo tail /var/log/syslog

(J’utilise tail et non cat, car dans ce cas précis seule la fin du fichier m’intéresse.


May 13 15:50:54 Pi portsentry[5647]: adminalert: Going into listen mode on UDP port: 32770
May 13 15:50:54 Pi portsentry[5647]: adminalert: Going into listen mode on UDP port: 32771
May 13 15:50:54 Pi portsentry[5647]: adminalert: Going into listen mode on UDP port: 32772
May 13 15:50:54 Pi portsentry[5647]: adminalert: Going into listen mode on UDP port: 32773
May 13 15:50:54 Pi portsentry[5647]: adminalert: Going into listen mode on UDP port: 32774
May 13 15:50:54 Pi portsentry[5647]: adminalert: Going into listen mode on UDP port: 31337
May 13 15:50:54 Pi portsentry[5647]: adminalert: Going into listen mode on UDP port: 54321
May 13 15:50:54 Pi portsentry[5647]: adminalert: PortSentry is now active and listening.

On se rend compte que portsentry récupère bien les tentatives de scans.

Bon, ok, mais vous allez me dire qu’on est bien avancé, parce que le but c’est plutôt qu’il les bloque, non ?

Eh oui, en effet, mais pas de panique c’est prévu. :smiley:

Pour demander le rejet (blocage si vous préferez) des scans de ports il faut modifier le principal fichier de config de portsentry, soit :

sudo nano /etc/portsentry/portsentry.conf

Ensuite avant la section “Dropping Routes”, vous trouverez les deux lignes qui nous intéressent, soit :


BLOCK_UDP="0"
BLOCK_TCP="0"

Je pense que vous aurez facilement deviné ce qu’il faut faire, il s’agit tout simplement de mettre “1” à la place de “0”, facile, hein ? :ane:

Ce qui donne donc :


BLOCK_UDP="1"
BLOCK_TCP="1"

Maintenant il suffit de relancer Portsentry pour que les modifs entrent en vigueur, une fois encore on utilise la commande :


sudo service portsentry restart

Je m’arrête là pour le moment sur la config de Portsentry, n’hésitez pas à consulter la doc si vous souhaitez en savoir plus sur les options disponibles :slight_smile: .

Notez que Portsentry utilise au moins en partie IpTables et qu’il est à même de modifier le fichier de config de ce dernier (celui que l’on a configuré plus haut), voilà pourquoi je vous recommande fortement de commenter ce que vous saisissez vous même dans le fichier d’IPTables. :wink:

Sachez également que si vous relancez un scan de port avec nmap depuis le Pi lui-même, seuls devraient cette fois apparaitre ceux que l’on a explicitement ouvert dans le fichier de config d’IpTables, soit les ports 80 & 22 dans mon exemple.

Derniers points : Vous pouvez autorisez des machines a faire des scans de ports (ça peut être utile) en déclarant les machines autorisées dans le fichier : /etc/portsentry/portsentry.ignore.static.

Vous pouvez consulter la liste des machines bloquées dans le fichier : /etc/hosts.deny

Bannir l’ip à l’origine d’une attaque avec Fail2ban

On a vu dans le point précédent comment bloquer les scans de ports, mais il faut savoir que ce n’est pas la seule attaque, loin de là qui est possible.
Il y en a une autre, qui peut se réveler bien plus problématique : les tentatives de connexion par dictionnaire ou par force brute.

De quoi s’agit-il? De tentatives répetées de connexions (par exemple au service SSH) dans le but de casser votre mot de passe (brrr …), d’où déjà la necessitée absolue de ne pas utiliser un mot de passe trop facile a casser ou un mot pouvant exister dans un dictionnaire, mais une suite de caractères aléatoire pour garantir la sécurité de l’accès.

Oui, d’accord, mais même avec un mot de passe ultra complexe, si le pirate fait 540 mille miyons de miyards (le mec est un acharné :ane: ) de tentatives, il va bien arriver a casser le mot de passe ? :confused:

Pas si vous utiliser un mot de passe ultra complexe de 295 000 000 de caractères. [:mpay]

Comment ça, ça fait beaucoup ? :paf:

Bref, trève de plaisanteries, c’est là que rentre en jeu fail2ban.

Ce programmes détecte les tentatives frauduleuses d’accès à la machine, notamment celles consistant à tester un grand nombre de mots de passe.

Comme d’hab, pour l’installation on passe par notre gestionnaire de paquets préferés (vous avez du vous rendre compte que le mien est aptitude [:yeoh]) :

sudo aptitude install fail2ban

Ensuite, comme d’hab, seconde étape, la configuration, qui se passe dans le fichier /etc/fail2ban/jail.conf

On l’ouvre avec nano. :sleep: Euh, pardon, je m’assoupis. :ane:

sudo nano /etc/fail2ban/jail.conf

Ensuite c’est relativement simple, il est possible d’indiquer une adresse mail pour être prévenu des tentaives d’intrusion. (par défaut les éventuels rapports arriveront sur la boite mail Unix du compte root)

Ensuite dans la section JAILS, vous pouvez définir les types de connexions a surveiller.
Notez bien que celles en “disabled” ne sont pas surveillées.

Si vous modifiez le port par défaut de l’une d’elle il faut également l’indiquer en utilisant port = xx (xx représente le port en question).

Les autres options utiles concernent le temps de banissement d’une ip (bantime définit par défaut pour toutes les conexions) en secondes et maxretry qui concerne le nombre de tentatives maximum de connexion avant le ban d’une ip.
On peut également définir les adresses Ip exclues du filtrage.

Comme d’hab, quand on a terminé la configuration, il faut relancer le service :

sudo service fail2ban restart

Un point intéressant peut être de consulter le fichier log de fail2ban, pour savoir ce qui s’est passé pendant qu’on était absent par exemple.

Noter que j’utilise la commande tail -f et non cat pour afficher les dernières lignes du fichier et bénéficier en plus d’une mise à jour régulière (par défaut toutes les secondes, ce qui est pratique car si une tentative de connexion est bannie par fail2ban, vous le voyez immédiatement).

Là, je me doute, vous vous dite sque ça n’arrive pas tous les jours ce genre de tentatives d’intrusion …

(la commande qui va bien pour demander un affichage du fichier log de fail2ban :slight_smile:

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

Eh, bien, justement, le même jour, en à peine plus de 2 heures d’intervales, mon fichier contenait ceci :


2013-05-14 12:58:40,660 fail2ban.actions: WARNING [ssh] Ban 61.xx.xx.xx
2013-05-14 15:10:35,036 fail2ban.actions: WARNING [ssh] Ban 210.xx.xx.xx

Quand même. :riva:

Sachez que ce ne sont pas forcément des tentatives d’intrusions non plus, il peut s’agir de scans de ports un peu “poussés”, mais toujours est-il que c’est le genre de chose qui ne me plait pas vraiment).

Notez que j’ai modifié les apramètres de ban pour les tentatives de connexions sur SSH, ban de 24 heures au bout de 4 tentatives échouées (oui, par contre, il faut éviter de se lourder de mot de passe :ane: ), soit pour la section concerné de mon fichier de config fail2ban :


[ssh]

enabled  = true
port     = ssh
filter   = sshd
logpath  = /var/log/auth.log
maxretry = 4
bantime = 86400

Je rappelle que la période de ban est en secondes.

Pour le blocage d’une IP, fail2ban se repose sur IpTables.

On peut voir la liste des règles appliquées par Iptables avec la commande :

sudo iptables -L

Ce qui nous intéresse particulièrement c’est ceci :


Chain fail2ban-ssh (1 references)
target     prot opt source               destination
DROP       all  --  21xxxxxxx.xxxxxx.xxx  anywhere
DROP       all  --  61.xx.xx.xx        anywhere
RETURN     all  --  anywhere             anywhere

On voit clairement les deux règles crées par fail2ban pour rejeter les paquets provenants des adresses IP bannies.

Les adresses ip apparaissent en clair et lorsqu’un nom de domaine est lié il apparait en clair. :jap:

Toujours au sujet de fail2ban, notez qu’il est possible dans le fichier de config de spécifier des adresses à ne pas bannir (ça peut être pratique pour des postes en réseau local, si vous adoptez une politique de ban très agressive).
Veillez a laisser l’adresse indiquée par défaut 127.0.0.1/8, il s’agit du serveur lui même.
Notez aussi que le masque de sous réseau se note en décimal ("/8").

Ca se passe dans la section [DEFAULT] du fichier.
On a d’ailleurs également la possibilité de spécifier la durée du ban par défaut et le nombre de tentatives (utiles pour les connexions non listées ensuite).

A la recherche de la porte perdue : Rkhunter

Dans le cas ù votre machine aurait subi une intrusion, il est très probable que l’attaquant ait laissé une backdoor.

Rkhunter est précisément un utilitaire permettant de détecter ce genre de choses, notez que par défaut il se lance une fois par jour pour effectuer cette recherche et consomme peu de ressources, on ne va donc pas s’en priver.

Pour l’install, ça se passe avec la commande suivante :

sudo aptitude install rkhunter

Ensuite, la traditionnelle confing :

sudo nano /etc/default/rkhunter

Pour que rkhunter s’execute une fois par jour il faut modifier la ligne CRON_DAILY_RUN par :

CRON_DAILY_RUN="YES"

Là encore, vous pouvez spécifier une adresse mail pour recevoir le rapport et là encore, par défaut il atterit dans la boite mail unix du compte root.

Configurer SSH

On l’a vu avec l’étude de fail2ban, le port SSH (par défaut 22) est une cible toute particulière d’attaques en tout genre.
Eh oui, pensez donc, si quelqu’un arrive a se logguer avec SSH il est dans la place !

Certes les mécanismes de droit et de comptes utilisateurs de Linux permet de réduire les risques en cas d’intrusion.
De plus, il faut encore connaitre le nom du compte sur lequel se logguer et le mot de passe …

Oui, sauf qu’un nom de compte est commun à TOUS les systèmes basés sur Linux (sauf s’il est désactivé évidemment).

Il s’agit de root …

Le compte root, kézako ?
Vous le savez sans doute, le compte root c’est le compte super utilisateur, le compte “DIEU” qui possède TOUS les droits sur la machine, imaginez donc les conséquences possibles en cas d’intrusion sur ce compte …

BRRR … :peur:

Cependant ne paniquez pas il existe une solution des plus efficaces : Désactiver le compte root pour les connexions SSH.

[color=red]Notez bien que c’est une précaution que je vous recommande TRES FORTEMENT de prendre.
Certes, on a mis en place des messures de sécurités permettant de réduire les risques d’intrusions, mais il vaut mieux prendre TOUTES les précautions possibles.[/color]

Bonne nouvelle, mettre en place cette limitation est simple. :slight_smile:

Notez qu’il reste possible une fois loguué avec votre compte utilisateur de passe root si besoin.

Comme d’habitude, on va bricoler le fichier de config, de SSH cette fois, pour se faire on lance la commande :

sudo nano /etc/ssh/sshd_config

Ca se passe à la section #Authentification.

Il faut modifier la ligne “PermitRootLogin” pour :

PermitRootLogin no

Notez qu’il est également très conseillé de changer le port d’écoute de SSH (22 par défaut je le rappelle).

Ce paramètre se situe en début de fichier :

Port 22

Attention à bien choisir un port qui n’est pas utilisé par un autre service.

Vous trouverez sur le net des listes d’utilisations des ports réseaux.
Bien entendu vous devrez aussi le changer sur le logiciel que vous tuilisez pour accéder à votre PI via SSH.

IMPORTANT : Soyez TRES vigilants lorsque vous changez le port SSH, en effet n’oubliez pas qu’il faut aussi le changer dans les régles d’IpTables.
Je vous recommande d’ailleurs fortement d’autoriser les deux ports en entrées / sorties dans IpTables (et de bien lancer le script) AVANT d’effectuer les modifs dans les paramètres dans SSH.

Si vous oubliez cette procédure, vous serez quitte pour brancher un clavier et un écran sur votre PI.
Une fois que vous avez fait la modif dans SSH (et relancé le service, nous allons voir ça de suite), vous pourrez bien sûr ne mettre qu’un port pour SSH dans les règles d’IpTables … Le bon port. :ane:
N’oubliez pas non plus de relancer :

sudo update-rc.d firewall defaults

Pour être bien sûr que les paramètres soient bien pris en compte au démarrage.

Relancer le service SSH pour que les modifications soient appliquées, ben comme d’hab :

sudo service ssh restart

Pour augmenter encore la sécurité du serveur on peut autoriser seulement certains utilisateurs à se connecter via SSH.

Pour ce faire, il faut encore et toujours se rendre dans le fichier de configuration de SSH (le même précédemment, je vous fais grâce de la commande cette fois).

La manip est toute simple, une fois que l’on a ouvert le fichier de config, il suffit d’ajouter AllowUsers, suivi des utilisateurs a ajouter, séparés par un espace.

Ce qui donne par exemple :

AllowUsers Titi Grosminet Bipbip Coyotte

Je vous conseille d’insérer la ligne dans la section #Authentification où l’on a précisé que l’on ne voulait pas pouvoir se logguer avec le compte root.

Attention a bien saisir votre compte utilisateur (attention aux majuscules / minuscules), là encore en cas d’erreur c’est un coup a devoir rebrancher votre clavier).

On va profiter du fait que l’on est dans le fichier de config pour fiare une petite vérification : Normalement SSH est configuré par défaut pour interdire de se logguer avec des mots de passe vide (sans mot de passe en fait), recherchez dans le fichier de config la ligne :

PermitEmptyPasswords 

Elle doit se terminer par la mention no, si ce n’est pas le cas, modifiez la valeur pour mettre no.

Un fois la modification faite on redémarre SSH, avec la commande que vous connaissez :

sudo service ssh restart

Comme promis depuis quelques temps, nous allons cette fois aborder la possibilité de se loguer avec une clé d’authentification plutôt que par mot de passe, nous verrons également comment configurer SSH pour qu’il n’accepte que cette méthode et plus de mot de passe, ce qui permettra de réduire encore le risque d’intrusions non autorisées. :slight_smile:

La première étape consiste a générer les clés nécessaires à l’utilisation de l’authentification par clés.

Sachez que cette étape (ainsi que celle de la copie de la clé publique sur le serveur dépendra de la méthode que vous utilisez pour vous connecter via SSH à votre Pi).

Notez également que je pars du principe que SSH est configuré de façon adéquate pour utiliser l’authentification par clés.

Il faut pour se faire que le fichier /etc/ssh/sshd_config contienne les 3 lignes suivantes :


RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile      %h/.ssh/authorized_keys

Si vous avez besoin de modifier la configuration, je vous rappelle qu’il faut relancer SSH pour qu’elles soient prises en compte, avec la commande :

sudo service ssh restart

Pour une machine sous Linux il faut procéder de la façon suivante :

On créé donc d’abord les clés :

ssh-keygen -t rsa

Sachez que vous pouvez utiliser le type de clés DSA, mais je ne détaillerai pas les différences ici, en remplaçant rsa par dsa.

Une fois les clés générées une passphrase (l’équivalent d’un mot de passe) vous sera demandés, sachez qu’elle n’est pas obligatoire, mais je vous conseille d’en saisir une, histoire de maximiser la sécurité.

Ensuite il faut copier la clé publique générée sur le serveur, ce qui se fait avec la commande :

ssh-copy-id -i id_rsa.pub -p xx votrelogin@ipserveur

xx représente le port SSH.

Ensuite, vous pourrez vous connecter à votre serveur en utilisant la commande habituelle pour lancer SSH :

ssh -p xx votrelogin@ipserveur

Pour une machine sous Windows, en utilisant Putty, c’est un poil plus complexe:

Note que pour Putty, je considère qu’il est configuré en encodage UTF8, cela peut avoir une conséquence sur l’affichage des caractères si ce n’est pas le cas, je vous conseille fortement de le configurer pour qu’il utilise un encodage UTF8 (Onglet /windows/translation).

Il faut utiliser l’utilitaire puttygen.exe qui se télécharge à la même adresse que Putty.

On le lance, il faut ensuite séléctionner le type de clé SHA-2 RSA, on peut définir la longueur de la clé, perso, je met 2048 bits, ensuite on clique sur Generate.

Notez que pour créer la clé il vous faudra bouger la souris dans la fenêtre de puttygen (qui utilise les mouvements de la souris pour créer la clé).

Enregistrez ensuite les clés publiques et privées sur votre machine locale (celle sous Windows donc).

Là encore, je vous conseille d’utiliser une passphrase.

Ensuite, c’est là où la procédure diffère et devient moins pratique, mais ça reste assez simple à mettre en oeuvre. :wink:

Ah, Windows qui n’intègre pas de client SSH nativement, quel bonheur … :ane:
Si j’avais le temps, je trollerais d’ailleurs …

Euh, oui, bon, passons. :ane:

Redevenons sérieux, dans Puttygen, vous remarquez que votre clé publique est affichée et vu qu’elle sert juste à décrypter, vous pouvez à la limite l’afficher sur votre façade d’immeuble à la vue de tous, sans problème. :stuck_out_tongue:
Par contre la clé privée, elle il faut la garder précisuement. :wink:
Donc, on va copier la clé publique dans le presse papier (sélectionner la totalité de la clé clic droit copier, mais j’imagine que vous n’avez pas attendu que je l’écrive pour le faire [:yeoh]).

Ensuite, il faut la copier sur le serveur (via Putty et une session SSH ouverte).

Rendez vous dans votre dossier home (sous Debian, sur le Pi via SSH) avec la commande :

cd ~

Puis vérifier qu’il existe un dossier .ssh, avec la commande :

ls -a .ssh

Si la console vous retourne un message vous indiquant qu’aucun dossier ou fichier se nommant de cette façon, il faut donc le créer avec la commande suivante :

mkdir .ssh

La commande est simple, mais je détaille quand même une chose : le . précédant le nom du dossier indique qu’il s’agit d’un dossier caché (qui n’est pas affiché lorsque l’on tape ls, mais qui l’est avec un ls -a ).

Ensuite, il faut lancer la commande suivante pour ajouter votre clé RSA publique au fichier de clés autorisées (il sera créé s’il n’existe pas), avec la commande :

echo "votre clé RSA" >> .ssh/authorized_keys

Evidemment il faut remplacer votre clé RSA (notez qu’il faut saisir les guillemets) par la clé que nous avons copiée dans le presse papier, pour ce faire effectuer simplement un clic droit dans la fenêtre (n’importe où) de Putty.

Faites bien attention à une chose : Il faut bien saisir les deux chevrons (>>), en effet, si vous n’en saisissez qu’un au lieu d’ajouter la clé au fichier, le système remplacera le contenu du fichier par la seule clé que nous venons d’indiquer.
Alors évidemment, si le fichier n’existait pas, cela n’aura aucune conséquence, en revanche, si le fichier contenait d’autres clés, cela pourrait avoir de fâcheuses conséquences, attention donc !

Ensuite, vous pouvez vous déconnecter de votre session avec Putty (avec la commande exit ou la combinaison de touches CTRL + D).

Dans Putty dans les options de votre connexion , dans SSH / Auth (onglet de gauche) indiquez le fichier de votre clé privée sous “Private key file for authentification”.

Enregistrez ensuite vos réglages, vous pourrez alos vous connectez à votre Pi via SSH en utilisant votre clé toute neuve ! ^^)

Configurer SSH pour qu’il n’accepte que la connexion par clé :

Maintenant l’étape suivante consiste a configurer SSH pour qu’il refuse la connexion par mot de passe au profit de celle par clé uniquement.

Pour cela, il faut (encore et toujourd) modifier le fichier /etc/ssh/sshd_config et modifier la ligne :

PasswordAuthentication yes

Il faut bien entendu suprimer yes et mettre no, je pense que vous l’aures aisément deviné, n’oubliez pas de retirer le # en début de ligne s’il y en a un (je rappelle que le # permet de mettre une ligne en commentaire et donc de faire en sorte que la ligne soit ignorée).
Attention à n’effectuer cette modification qu’après vous êtes assuré que l’authentification par clé fonctionne bien.

Ensuite, bien entendu on redémarre SSH pour valider les modifs :

sudo service ssh restart

Voilà pour la configuration de SSH, nous avons maintenant quelque chose de suffisanment robuste au niveau des tentatives d’intrusions. :jap:

Divers

Bien entendu, il reste après quelques conseils de bon sens, comme surveiller régulièrement les fichiers logs du serveur.

Je reviendrai là dessus dans quelques temps.

Sachez aussi que pour tester la sécurité de votre machine, notamment tout ce qui est failles connues, vous pouvez utilisez l’utilitaire Nessus ou son pendant libre Open VAS, mais l’utilisation de ces logiciels dépassent largement le cadre de ce topic, je n’en parlerai donc pas ici (du moins pas pour le moment).

Il existe également un logiciel Linux permettant de faire de la détection d’intrusion, de manière encore plus précise que les outils assez simples que je décris ici.

Cet outil s’appelle Snort et est très puissant et complexe à mettre en oeuvre, de plus c’est outil qui tourne en permanence et analyse les flus en temps réel il consomme donc de la ressource, là non plus je n’aborderai pas son utilisation.
Edité le 05/12/2013 à 19:25

5) Le Monitoring et autres services

5.1) Le Monitoring

On a donc un serveur, qui a défaut d’être parfait est au moins opérationnel pour ce qu’on lui demande, cependant il serait quand même pratique de pouvoir le surveiller un peu.

Sur un Raspberry Pi, Raspcontrol est préférable à Munin, dont vous pouvez retrouvez l’installation et la configuration.

Raspcontrol est en effet plus léger et spécifique au Pi, en revanche il ne monitore pas les mêmes points et il est beaucoup moins détaillé, mais devrait être suffisant dans la majorité des cas.

Raspcontrol n’est pas disponible dans les dépôts raspbian, il faut donc l’installer manuellement, mais ce n’est pas très compliqué.

On saisit la commande suivante pour récupérer le paquet :

wget https://github.com/Bioshox/Raspcontrol/zipball/master

On décompresse ensuite le fichier (attention c’est un zip on n’utilisera donc pas la commande tar )

unzip master

Perso, je trouve que le nom de dossier “Raspcontrol-master” est long, pour pas grand chose, je le renomme donc en raspcontrol.

Ensuite, il faut déplacer le dossier en question dans le répertoire /srv/www

Soit :

sudo mv raspcontrol /srv/www

Ensuite, si vous souhaitez protéger l’accès à raspcontrol par mot de passe il faut d’abord créer le dossier qui contiendra le fichier d’utilisateurs / mots de passe :

sudo mkdir /etc/raspcontrol

Ensuite, on lance nano pour créer / éditer le fichier d’utilisateurs / mots de passe :

sudo nano /etc/raspcontrol/database.aptmnt

Le fichier devant contenir ceci :


{
"user":"admin",
"password":"admin"
}

Bien entendu n’hésitez pas a changer le nom d’utilisateur et le mot de passe. :wink:

D’ailleurs, le mot de passe apparait en clair, je vais me renseigner pour voir si on peut changer ça. :jap:

Rasponctrol est fonctionnel, il suffit de lancer votre navigateur et de taper l’adresse de votre serveur, suivie de /raspcontrol pour y avoir accès. :slight_smile:

5.2) Torrentflux

Avant de commencer ce point proprement dit, un avertissement sur l’utilisation des logiciels peer to peer et notamment des torrents :

Je rapalle que ces protocoles et logiciels sont tout à fait légaux, seule l’utilisation qui peut en être fait peut être illégale.
Je vous rappelle également que SEULE VOTRE RESPONSABILITE est engagée, pas celle de Clubic, ni la mienne si vous décidez d’enfreindre la loi.
L’utilisation de ces logiciels et protocoles n’a donc rien d’illégale tant que les fichiers que vous téléchargez / partagez sont libres de droits.

Avant d’installer Torrentflux proprement dit, il vous faudra d’abord installer un client bittorrent supporté par torrentflux sur votre Pi, personnellement, j’utilise bittornado.

Pour l’installer, on passe par notre gestionnaire de paquets préfèré, ce qui donne par exemple :

sudo aptitude install bittornado

Ensuite il faut récupérer l’archive de torrentflux, sur sourceforge.net (perso, j’utilise links2 pour le faire, certes c’est un navigateur en mode texte, mais il suffit pour ce genre de choses :slight_smile: )

Ensuite, il faut décompresser l’archive :

tar -xvzf torrentflux_2.4.tar.gz

Ensuite, on procède comme pour l’installation de Wordpress, on déplace donc le dossier contenant les fichiers php sur à l’emplacement où l’on stocke les sites hébergé sur le PI (je rappelle que sur ma conig, je stocke ça sur /srv/www ), soit :

sudo mv ~/torrentflux_2.4/html /srv/www/torrentflux/

On n’oublie pas l’attribution des droits à l’utilisateur sous lequel se lance lighttpd :

sudo chown -R www-data /srv/www/torrentflux

Et :

sudo chmod -R 755 /srv/www/torrentflux

Notez qu’il est signalé dans la doc d’install de torrentflux qu’il faut que le dossier de téléchargement aie les droit 777, soit :

sudo chmod -R 777 /srv/www/torrentflux/downloads/

Ensuite, il faut créer à l’aide de MySQL un utilisateur et une base de données pour torrentflux, pour ça, je vous renvoie à la section 3 où je traite de Wordpress.

Dernières étapes, il faut créer les tables MySQL pour torrentflux, pour ce faire il faut utiliser la commande suivante :

mysql -u utilisateurtorrentflux -p lenomdelabasetorrentflux < ~/torrentflux_2.4/sql/mysql_torrentflux.sql

Ensuite et pour terminer il faut modifier le nom d’utilisateur, de la base de données et le mot de passe utilisé par torrentflux pour se connecter à mysql, avec la commande :

sudo nano /srv/www/torrentflux/config.php

Rechercher ensuite root (Ctrl +W pour lancer une recherche dans Nano), puis modifiez en conséquence.

Tout dernier point, on se connecte à notre page torrent flux via un navigateur sur une machine distante (réseau, ou via internet) :

nom_d’hote…

Un nom d’utilisateur et un mot de passe sera demandé, sachez que ce login et ce mot de passe serviront à la création du compte administrateur de torrentflux, vous pourrez ensuite créer des utilisateurs simples qui ne peuvent pas modifier la configuration.
Edité le 05/06/2013 à 11:56

Edité le 13/05/2013 à 14:39

Drapal :smiley:

Edité le 13/05/2013 à 19:17

Hop
Je vais suivre du coin de l’oeil ce topic, même si pour moi le Raspberry Pi sert uniquement à faire tourner XBMC (avec RaspBMC) donc c’est pas trop le sujet du topic j’ai l’impression (plus orienté serveur, etc)

Justement, le but du topic c’est de le tester sur plusieurs fonctions :smiley:

Je ferai aussi un petit topo sur l’utilisation de la distrib openelec (qui contient XBMC), mais pour le moment j’ai donné la priorité à mes besoins propres, c’est à dire un serveur de tests basés sur Debian. :wink:

drap

Suite à un conseil de Lithium, je vais probablement enlever Apache qui se révèle lourd sur une telle machine pour utiliser un serveur http moins lourd.

WIP http://kay-smiley.info/images/321.gif
Edité le 14/05/2013 à 22:12

te laisse pas influencer comme ca :na:

manque juste des ports SATA pour en faire un petit NAS :miam:

Pour info, j’ai finalement installé lighttpd en lieu et place d’Apache, je ferai un petit topo là dessus quand j’aurai vu un peu en détail la config du machin. :stuck_out_tongue:

question dans quoi tu installes le Raspberry pi?

Quand je l’ai commandé, j’ai pris aussi une boite en plastique dédié au Pi, sachant que je le mets dans un renfoncement de mon meuble info, je préfère au moins si quelque chose tombe dessus il ne risque rien. :slight_smile:

Perso j’ai mis le mien la dedans: http://www.materiel.net/barebone-mini-pc-avec-carte-mere-et-alimentation-/raspberry-pi-boitier-raspberry-pi-type-b-noir-87821.html

Idem, sauf que j’ai pris la version transparente. :paf:

topodoco => Tu fais quel usage de ton Pi ?