Avec le grand nombre de Raspberry Pis à l'état sauvage et le fait que de grands groupes d'entre eux sont configurés de manière identique (lorsqu'une carte SD nouvellement flashée est installée avec l'une des rares images disponibles), il est probable qu'ils seront une cible tentante pour logiciels malveillants, y compris les réseaux de zombies.

Que peut-on faire pour atténuer cela?

Il est raisonnablement bien connu que l’on devrait changer le mot de passe de l’utilisateur "pi" (Debian) et "root" (Arch.). Mais qu’en est-il des autres comptes système (par exemple, "tli", "pnd"?) des mots de passe universels qui sont vraisemblablement les mêmes pour toutes les unités?

Et existe-t-il des vulnérabilités connues dans d'autres packages installés dans les images SD disponibles pour le Pi (par exemple, en raison de limitations matérielles ou de versions réduites de ces packages?)

En particulier ssh, mysql et tous les autres services pouvant s'exécuter sur une image nouvellement installée m'inquiètent.

Ce que j'ai remarqué jusqu'à présent sur l'image stock de Debian Squeeze:

• / etc / shadow contient une série de hachages de mots de passe pour les comptes qui ne sont pas le compte pi (buildbot, etc.). Modifiez le mot de passe sur le compte pi, bien sûr, si vous ne l'avez pas encore fait (ou créez un nouveau compte utilisateur et supprimez le compte pi), mais modifiez également les autres entrées et remplacez le hachage par * s. Remarque / etc / passwd contient des entrées en double pour le compte pi, ce qui déroute complètement adduser / deluser, supprimez-en une.

• la configuration par défaut du démon ssh autorise la connexion root à distance. Cela devrait être désactivé.

• Cela vaut la peine d’utiliser Netstat pour vérifier l’ensemble des éléments à l’écoute des connexions; une quantité surprenante de choses est en cours d’exécution comparée à un netinst minimal typique. Il est généralement une bonne idée de réduire l' exposition à seulement les choses que vous avez besoin , donc d' abord désactiver ou pare - feu hors tout , puis exposer seulement les services que vous souhaitez délibérément visibles sur l'Internet public (généralement juste ssh ou ssh + http).

• vous voudrez changer les clés de l'hôte ssh plutôt que d'utiliser celles de l'image (AIUI la dernière image les régénère au premier démarrage)

Il existe de nombreuses façons de remédier aux vulnérabilités, mais la première chose à savoir est que Linux n’est pas aussi vulnérable aux intrusions que les autres systèmes d’exploitation. Ceci est principalement dû au manque de malware qui cible * NIX. Néanmoins, vous voulez savoir comment accéder à votre système.

Mots de passe

Tout d'abord, vous devez modifier les mots de passe par défaut pour tous les utilisateurs pouvant se connecter. Pour Debian, ce n'est que l'utilisateur par défaut, Pi . Pour Arch Linux, il s'agit de la racine du super utilisateur . Les mots de passe sont modifiés lors de la connexion en tant qu'utilisateur en tapant passwdsur la ligne de commande.

Une stratégie de mot de passe sécurisé est recommandée, car il serait assez simple de lancer des attaques par dictionnaire avec force brutale sur votre utilisateur par défaut. Choisissez un mot de passe décent, de longueur moyenne.

Obscurité

L'accès à distance est probablement le trou de sécurité le plus important. Ce que nous pouvons utiliser ici s'appelle sécurité par obscurité . Une méthode d'attaque courante consiste à analyser une plage d'adresses IP à la recherche de ports ouverts. L’une des contre-mesures les plus simples que nous puissions prendre est donc d’être un utilisateur qui n’utilise pas les ports par défaut .

Ici, il suffit de changer les ports par défaut pour les protocoles couramment utilisés. Par exemple, le port SSH par défaut est 22 et FTP en 21. Sur mon système, SSH utilise 222 et FTP 221, ce qui devrait masquer ces protocoles contre toute attaque automatisée.

Sécurité de la connexion

Premièrement, le problème de sécurité le plus important est que le compte root ne puisse pas se connecter via SSH. Vous pouvez désactiver la connexion root dans le /etc/ssh/sshd_configfichier en commentant ou en supprimant cette ligne:

PermitRootLogin yes

Il devrait être réglé sur no par défaut, mais il vaut mieux vous en assurer.

Si vous utilisez beaucoup SSH et que vous vous inquiétez des attaques de type homme de la moyenne, attaques du dictionnaire contre votre mot de passe, vous pouvez utiliser SSH Keys.

L'authentification par clé présente plusieurs avantages par rapport à l'authentification par mot de passe. Par exemple, les valeurs de clé sont beaucoup plus difficiles à forcer que les mots de passe simples.

Pour configurer l'authentification par clé SSH, vous devez d'abord créer la paire de clés. Ceci s’effectue le plus facilement sur votre ordinateur client (l’ordinateur avec lequel vous voulez accéder au Pi).

# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/pi/.ssh/id_rsa):

Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/pi/.ssh/id_rsa.
Your public key has been saved in /home/pi/.ssh/id_rsa.pub.

Comme vous pouvez le constater, cela a créé deux fichiers, la clé privée id_rsaet la clé publique id_rsa.pub.

La clé privée n'est connue que de vous et doit être gardée en sécurité . En revanche, la clé publique peut être partagée librement avec tout serveur SSH auquel vous souhaitez vous connecter.

Nous aimerions donc copier la clé publique sur le Raspberry Pi. Nous pouvons le faire très facilement:

ssh-copy-id pi@address

Où se pitrouve le nom d'utilisateur Raspberry Pi et addressl'adresse IP du Pi.

Je répète, nous distribuons la clé publique . La clé privée est à vous. Tenez-le bien, relâcher cette clé casse la sécurité du système.

Le wiki Arch a une excellente description de la façon dont cela fonctionne:

Lorsqu'un serveur SSH a votre clé publique dans le fichier et vous voit demander une connexion, il utilise votre clé publique pour construire et vous envoyer un défi. Ce défi ressemble à un message codé et doit recevoir la réponse appropriée avant que le serveur ne vous accorde l’accès. Ce message codé est particulièrement sécurisé, c'est qu'il ne peut être compris que par une personne possédant la clé privée. Bien que la clé publique puisse être utilisée pour chiffrer le message, elle ne peut pas être utilisée pour déchiffrer le même message. Seul vous, détenteur de la clé privée, serez en mesure de comprendre correctement le défi et de produire la réponse correcte.

Pour plus d'informations sur la sécurité de l'authentification par clé publique, Wikipedia dispose d'une explication détaillée .

Avec la sécurité SSH en place, vous pouvez effectuer une quantité énorme de transferts de données cryptés et sécurisés. Pratiquement toutes les autres connexions de port peuvent être routées via SSH si nécessaire. Vous pouvez même transférer la session X via SSH afin qu’elle apparaisse sur un autre ordinateur.

Comme exemple intéressant, hier, j'utilisais Eclipse sur mon bureau, je le visualisais sur mon Raspberry Pi et contrôlais la souris et le clavier à partir de mon Netbook. Tel est le pouvoir de SSH.

Les permissions

Les autorisations de fichiers sont le noeud du système de sécurité Linux. Ils affectent qui peut voir vos fichiers et vos dossiers et peuvent être très importants pour la protection de vos données. Par exemple, connectez-vous à Raspberry Pi en tant qu'utilisateur normal et exécutez:

cat /etc/shadow

Le shadowfichier contient des mots de passe cryptés pour les utilisateurs du système, nous ne voudrions donc pas que quiconque le regarde! Donc, vous devriez voir cette réponse:

cat: /etc/shadow: Permission denied

Nous pouvons voir pourquoi c'est en jetant un coup d'œil sur les permissions du fichier:

ls -l /etc/shadow
-rw------- 1 root root 821 Jun 11 22:13 /etc/shadow

Cela nous indique que le fichier appartient à root et que seul le propriétaire dispose des autorisations de lecture / écriture. Décomposons cette sortie.

-rw-------

C'est l'état des permissions. Le premier bit nous indique le type de fichier ( -fichier standard). Les trois bits suivants représentent les actions disponibles pour le propriétaire du fichier. Les trois autres bits représentent le groupe et les trois derniers sont destinés aux autres ou à tous les autres. Ainsi, un répertoire avec des autorisations complètes ressemblerait à ceci:

drwxrwxrwx  10 root root   280 Jun 20 11:40 tmp/

Il s’agit des autorisations de lecture, d’écriture et d’exécution pour le propriétaire, le groupe et tous les autres.

La prochaine partie importante est les deux noms. Dans notre cas root root. Le premier utilisateur est le propriétaire du fichier. Le second est le groupe d'utilisateurs . Par exemple, il serait courant de voir:

drwxr-xr-x  10 pi users   280 Jun 20 11:40 home/pi

Cela permettrait un accès en lecture / écriture à l'utilisateur pisur son répertoire personnel et un accès en lecture à tous les autres utilisateurs.

Les autorisations sont le plus souvent référencées et contrôlées à l'aide de valeurs octales. Par exemple, si nous voulons définir rw uniquement pour le propriétaire, nous tapons:

chmod 600 /path/to/file

Ceci est un aperçu de base. Pour plus de détails sur les autorisations de fichiers Linux, voici un bon article.

Cette compréhension est importante lors de la sécurisation de fichiers et de dossiers. Par exemple, supposons que nous venons de configurer des clés SSH. Nous ne voulons absolument pas que d'autres utilisateurs voient dans notre ~/.sshannuaire, sinon ils pourraient prendre notre clé privée. Ainsi, nous supprimons leurs privilèges de lecture:

chmod 700 ~/.ssh
ls -la ~/.ssh 
drwx------   2 james users  4096 Jun 18 03:05 .

J'espère que cela clarifie certaines de vos préoccupations concernant la sécurisation de Linux. A partir de cela, vous devriez pouvoir voir que c'est un système assez sécurisé et si vous faites attention, vous ne devriez avoir aucun problème de sécurité.

Pour empêcher les attaques brutales, vous pouvez installer et configurer fail2ban. Il analysera les fichiers journaux (tels que /var/log/auth.log) et essaiera de détecter si plusieurs tentatives de connexion ont échoué. Ensuite, il interdira automatiquement les adresses IP source avec iptables.

Il y a un tas de howtos sur Internet.