Déployer application Ruby On Rails de A à Z - Partie 2

Catégories:

Ruby On Rails

Par Régis Millet , publié le 2 Décembre 2015

Deuxième partie du guide d’installation d’un serveur dédié RoR pas à pas.
Dans cette partie nous allons installer les premières briques à mettre en place sur tout serveur dédié : des briques de sécurité. Car la sécurité, c’est bien !

Pourquoi sécuriser son serveur ?

Il y a de nombreuses raisons, la principale étant d’éviter au maximum que votre serveur ne se fasse pirater. Notez qu’encore une fois la sécurisation d’un serveur ne se limite pas aux serveurs dédiés, les VPS ou serveur cloud (comme les EC2) doivent également être protégés.

Les attaques pirates peuvent avoir de multiples formes et intervenir à différents niveaux sur vos applications Webs. Si RoR possède des sécurités par défaut (comme des protections contre des injections de code), il est important de bien sécuriser également son serveur.

Les attaques les plus graves étant lorsqu’un pirate parvient à accéder au compte root ou avoir des privilèges similaires sur votre serveur. Il lui est ainsi possible de perpétuer d’énormes dégâts sur votre système, de voler des données, d’installer des virus pour récupérer des données confidentielles ou de casser tout votre environnement de production.

La sécurité 100% n’existe pas, mais il existe des logiciels et des bonnes pratiques simples à mettre en place permettant de réduire drastiquement les risques. Nous allons en effectuer quelques-unes ci-après.

Note : De nombreuses bonnes pratiques de sécurité sont explicitées dans ce document :
https://benchmarks.cisecurity.org/tools2/linux/CIS_Ubuntu_12.04_LTS_Server_Benchmark_v1.1.0.pdf - ce dernier fait toutefois 150 pages.

Si vous avez assez de ressources, vous pouvez vous référer à ce document pour mettre en place une sécurité bien verrouillée sur votre serveur. Malheureusement, avec peu de ressources humaines il paraît difficile de toutes les appliquer…

Sécuriser SSH

Si vous vous connectez sur le compte « root » directement

C’est pas bien.

Plus sérieusement, c’est ce que propose bon nombre d’hébergeurs par défaut. Effectuez donc une première connexion en ssh :

$ ssh root@ip.server

Une fois connecté, créer un utilisateur :

$ createuser nom_user

Mettez-lui le mot de passe (fort : 8 caractères mini, alpha numérique avec 2 caractères spéciaux) que vous voulez. Ajoutez-le ensuite au groupe « sudo » :

$ adduser nom_user sudo

Cette petite étape permettra à cet utilisateur d’exécuter des commandes administratives. Déconnectez-vous et reconnectez-vous avec le compte fraîchement créé :

$ ssh nom_user@ip.server

Ajouter une clef SSH – pour un terminal local sous Ubuntu/Linux

La clef SSH a un double avantage. Déjà elle permet de ne plus avoir à écrire son mot de passe pour se connecter. Ensuite elle est utilisée pour crypter les communications entre votre terminal et le serveur.
En local, sur votre terminal, exécutez la commande suivante :

$ ls ~/.ssh

Si dans la liste des fichiers affichés vous voyez « id_rsa.pub », alors vous pouvez sauter la prochaine commande. Sinon exécutez :

$ ssh-keygen

Laissez tout par défaut. Vous pouvez assigner un mot de passe si ça vous amuse ou si d’autres personnes que vous peuvent accéder à votre terminal.
Maintenant, exécutons :

$ cat ~/.ssh/id_rsa.pub | ssh nom_user@ip.server "cat - >> ~/.ssh/authorized_keys"

Cela aura pour effet de copier la clef fraîchement créée dans les « clef autorisées » à se connecter sur le compte « nom_user » sur le serveur.
Connectons-nous de nouveau :

$ ssh nom_user@ip.server

Normalement, plus besoin du mot de passe.

Note : s’il vous est encore demandé, ça peut être lié à un problème de droits soit sur le serveur, soit localement.

Modifier le port SSH

Si la modification du numéro de port SSH n’évite pas à coup sûr les piratages sur ce service, elle amoindrit toutefois considérablement les risques pour un minimum d’efforts de configuration.
Il faut éditer le fichier /etc/ssh/sshd_config, vous pouvez exécuter la commande suivante pour ce faire :

$ sudo vim /etc/ssh/sshd_config

Note : si vous ne connaissez pas vim, vous pouvez tout à fait utiliser un autre éditeur comme nano. Sinon je vais tâcher de vous guider pour son utilisation.

Pour passer en mode « édition » dans cet éditeur en ligne de commande, appuyez sur la touche « i » (comme insert, la touche insert fonctionne aussi d’ailleurs). Vous pouvez ensuite naviguer avec les flèches directionnelles, les touches fin / début, page suivante / précédente, etc.

Vous voyez en bas à droite du terminal deux chiffres, « 1,1 » : le premier indique le numéro de ligne où est votre curseur, le second le numéro de la colonne (Xème caractère sur la ligne).

Allez à la ligne 5 et modifiez « Port 22 » comme ceci :

Port 12765

Vous pouvez définir n’importe quel numéro de port > 10000 (ceux inférieurs sont souvent utilisés par des applications comme Mysql 5432 ou 8443 pour plesk), mais gardez-le bien dans un coin (dans un document si vous voulez, crypté et protégé par mot de passe si vous y mettez aussi vos identifiants).

Interdire les connexions root

Maintenant que nous avons un compte « sudo », il est de bon ton d’interdire les connexions directes sur le compte root. Une nouvelle fois c’est une bonne pratique de sécurité pour peu d’efforts. Dans le fichier sshd_config ouvert ci-dessus, repérez la ligne « PermitRootLogin » et remplacez sa valeur par « no » :
PermitRootLogin no

Appuyez maintenant sur la touche « echap » de votre clavier pour quitter le mode d’édition. Appuyez ensuite sur les touches « : » puis « w » puis « q » puis « entrée ». Ne fermez pas votre terminal, il faut d’abord tester.

Note : la touche « : » permet d’entrer des commandes spéciales dans vim. « w » signifie « write » pour « enregistrer » et « q » signifie « quit » pour quitter vim.

Test

Depuis un autre terminal, en local, exécutez :

$ ssh nom_user@ip.server –p numéro_port_choisi

Ca devrait normalement vous connecter. Si ce n’est pas le cas je vous invite à vérifier le numéro de port configuré dans sshd_config.

Installer Fail2Ban

Fail2Ban est un logiciel Linux souvent utilisé et plutôt simple d’utilisation. Pour un serveur « standard », sa configuration par défaut suffit très souvent. Ce logiciel va automatiquement bannir des adresses IPs lors d’échecs répétés de connexion SSH.

Fail2Ban ne se résume pas seulement en un bloqueur d’IPs pour SSH, il propose de nombreuses configurations pour bloquer les accès à diverses applications (nommées Jails). Je vous invite à effectuer des recherches sur un moteur de recherche en ciblant précisément votre application : Fail2Ban apache (par exemple on tombe facilement sur : https://github.com/miniwark/miniwark-howtos/wiki/Fail2Ban-setup-for-Apache )

Pour l’installer, rien de plus simple :

$ sudo apt-get install fail2ban

Ubuntu va se charger de le configurer et de le lancer automatiquement à chaque boot du serveur. Par défaut, seul le blocage SSH est activé. Vous pouvez creuser un peu ce logiciel pour pouvoir modifier différents paramètres comme le temps de ban ou le nombre d’échecs tolérés.

Cela termine cette deuxième petite partie. Dans la suivante nous ajouterons quelques briques de sécurité supplémentaires.

Index -- Article précédent: Déployer application Ruby On Rails de A à Z - Partie 1 -- Article suivant: Afficher une carte google map sur rails 4

Le blog de la CT2C

Article précédent : Déployer application Ruby On Rails de A à Z - Partie 1

Article suivant : Afficher une carte google map sur rails 4