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 
)
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. 
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. 
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 .
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. 
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 ? 
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
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.
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.
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.
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.
Par contre la clé privée, elle il faut la garder précisuement.
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
