Prendre un Café - Tag - sécurité

Sécuriser son Ubuntu-server

NiKo — Mon, 05 Feb 2007 23:00:00 +0100

L'intérêt d'avoir une Dedibox sur une classe C réputée niche à boulets, c'est qu'on est confronté à de nombreuses tentatives de hacks, DDOS et autres bruteforce quasi-quotidiennement. De quoi envisager une approche totalement paranoïaque de la sécurité du système ; voila quelques bonnes résolutions pour une Ubuntu-server.

Utilisez de vrais mots de passe

Minimum 8 caractères avec des lettres, des chiffres et de la ponctuation. Changez-en régulièrement.

Mieux, utilisez des clés SSH.

Désactiver l'accès root depuis SSH

Si quelqu'un arrivait à craquer votre accès SSH, il serait dommage qu'il arrive directement en root. Le moyen le plus simple pour éviter cela, c'est de désactiver l'accès SSH en root, en éditant le fichier /etc/ssh/sshd_config et en remplaçant la ligne :

PermitRootLogin: yes

par

PermitRootLogin: no

Changer le port SSH par défaut

Toujours dans le même fichier /etc/ssh/sshd_config, changer le numéro de port par défaut (22) par un autre :

Port 12345

Attention, ne prenez pas un numéro de port utilisé par un des autres services que vous utilisez sur le serveur (80 pour http, 25 pour smtp, 443 pour https, etc.)

Par exemple si vous déclarez le port 12345 pour SSH, vous vous connecterez ainsi sur la machine :

$ ssh user@machine.tld -p 12345

Note : Chaque modification du fichier sshd_config doit occasionner un redémarrage du service :

$ sudo /etc/init.d/ssh restart

Blacklister les IP malsaines

fail2ban est un petit utilitaire qui scanne les logs d'accès sshd et blackliste les IP depuis lesquelles émanent trop de tentatives de connexion échouées. Pour l'installer :

$ sudo apt-get install fail2ban

Plus d'infos sur la configuration et l'utilisation de fail2ban.

Interdire l'execution depuis /tmp

Le répertoire /tmp est souvent utilisé par les script-kiddies de tous poils pour y déposer leurs executables et les lancer. Une approche intelligente du phénomène est d'interdire l'execution de programme sur ce point de montage, en ajoutant la directive noexec à votre fichier /etc/fstab, comme dans cet exemple :

/dev/sda3   /tmp    ext3   noexec,nosuid     0    2

Si vous ne possédez pas de point de montage pour /tmp, pas de panique : vous allez pouvoir en créer un à l'arrache

Attention :

Le gestionnaire de paquet apt a parfois besoin d'executer des scripts depuis cet emplacement lors de certaines mises à jour, chose que la drective noexec interdit;
MySQL a parfois besoin de créer des tables temporaires à cet emplacement pour traiter des requêtes coûteuses, chose que le nosuid interdit.

La manipulation décrite ci-dessus n'est donc à appliquer en connaissance de cause. (voire à ne pas appliquer du tout, en fait. Hem.)

Installer un firewall

Shorewall est un firewall simple à administrer, mais pas pour autant moins efficace que les autres. L'installation se fait par un traditionnel :

$ sudo apt-get install shorewall

Un très bon tutoriel de configuration du logiciel existe, n'hésitez pas à aller y faire un tour. L'idée est dans tous les cas de tout interdire par défaut et d'ouvrir les ports un à un en fonction de vos besoins.

Vérifier régulièrement la présence de rootkits

Chkrootkit scanne votre machine et y déniche les rootkits les plus répandus. Le programme s'installe facilement via la commande :

$ sudo apt-get install chkrootkit

Et se lance de cette façon :

$ sudo chkrootkit

Vous pouvez croner l'exécution du programme quotidiennement et vous en envoyer le résultat par email, en ajoutant cette ligne dans votre crontab :

0 3    *   *   *   chkrootkit 2>&1 | mail vous@domain.tld -s "Rapport de chkrootkit"

D'autres outils peuvent tout aussi bien faire l'affaire et peuvent être utilisés de façon complémentaires :

Ces deux outils sont disponibles dans les dépôts officiels Ubuntu et sont d'une utilisation très simple.

Note : si la commande mail est inconnue de votre système, installez le paquet mailx :

$ sudo apt-get install mailx

Emprisonnez vos programmes et utilisateurs

Chroot est un programme qui permet de littéralement emprisonner un utilisateur ou un programme dans un environnement désolidarisé du reste du système, ce qui garanti une réversibilité des dommages occasionnés.

Plus d'informations sur la commande chroot.

Encore quelques conseils de base

Mettez régulièrement à jour votre système
Utilisez toujours les dépôts officiels Ubuntu
N'installez jamais de softs pour tester en oubliant de les désinstaller par la suite
N'ouvrez de nouveaux services que si vous en avez réellement besoin
Surveillez vos logs
Surveillez régulièrement les process système
Monitorez votre machine, surveillez les comportements anormaux
Ne donnez jamais vos mots de passe
Touchez du bois

Les commentaires bouillent d'impatience de recevoir vos remarques, suggestions et contributions.

Edit : Prise en compte de certains commentaires judicieux.

Edit 2 : JJL pose une vraie question : Ubuntu est-elle prête pour le serveur ? Sachant que les paquets Universe contenant des choses comme Trac ou Bacula ne sont pas maintenues au niveau patches de sécurité, cela laisse songeur...

Ce billet intitulé Sécuriser son Ubuntu-server a été rédigé par Nicolas Perriault et publié sur le blog Prendre un Café sous licence Creative Commons BY-NC-SA.

Installer sa clé SSH sur un serveur distant

NiKo — Mon, 29 Aug 2005 23:33:08 +0000

Qui n'a jamais pesté d'avoir à constamment taper et se souvenir de dizaines de mots de passe, quand on utilise plusieurs serveurs différents ? Moi, en tous cas.

Le principe est simple : générer une clé privée et une clé publique, toutes deux cryptées, et d'ajouter votre clé publique à la liste des clés autorisées du serveur distant afin de permettre l'authentification automatique sur ce dernier. Ainsi, vous pouvez définir une seule et même passphrase (mot de passe) pour vous logguer à toutes vos machines

Voici la procédure : d'abord - et si ce n'est déjà fait - il vous faut installer le client openSSH :

$ sudo apt-get update
$ sudo apt-get install openssh-client

Il faudra de même disposer de ssh-server sur la machine distante.

Ceci fait, il vous faut générer vos clés publiques et privées :

$ ssh-keygen -t dsa -b 1024
Generating public/private dsa key pair.

Là, il vous faut répondre à une petite série de questions :

Enter file in which to save the key (/home/monlogin/.ssh/id_dsa):

Appuyez sur Entrée, vos clés seront sauvegardées dans le repertoire caché .ssh.

Enter passphrase (empty for no passphrase):
Enter same passphrase again:

Une fois votre passphrase entrée, un message de confirmation de création est affiché :

Your identification has been saved in /home/monlogin/.ssh/id_dsa.
Your public key has been saved in /home/monlogin/.ssh/id_dsa.pub.
The key fingerprint is:
XX:8a:XX:91:XX:ae:XX:23:XX:2e:XX:ed:XX:4e:XX:b8 monlogin@mamachine

Ensuite, il vous faut ajouter votre clé publique à la liste des clés autorisées du serveur distant. En admettant que votre serveur se nomme toto.host.org et que votre nom d'utilisateur est titi ^[1], cela donne :

$ ssh-copy-id -i ~/.ssh/id_dsa.pub titi@toto.host.org
Password:

Entrez le mot de passe de l'utilisateur titi sur la machine distante. Si l'opération d'ajout de votre clé a réussi, un message est affiché :

Now try logging into the machine, with "ssh 'titi@toto.host.org'", and check in:

  .ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

Et voila, il ne vous reste plus qu'à lancer un ssh titi@toto.host.org, il vous sera demandé votre passphrase et vous serez loggué

$ ssh titi@toto.host.org
Enter passphrase for key '/home/monlogin/.ssh/id_dsa':

Elle est pas belle, la vie ?

Pour aller plus loin

Vous pouvez automatiser encore plus le process d'accès à vos serveur en définissant des aliases, via votre fichier .bashrc. Ce sont des raccourcis de commandes propres à l'utilisateur courant du shell de la machine.

$ gedit .bashrc

Une fois le fichier ouvert, vous pouvez ajouter vos aliases en respectant la syntaxe suivante :

alias <raccourci>='<commande>'

Ce qui donne pour notre accès SSH à toto.host.org :

alias sshtoto='ssh titi@toto.host.org'

Sauvegarder le fichier. Pour que les modifications soient prises en compte, il faut recharger le fichier .bashrc :

. .bashrc

Voila ! Maintenant vous pouvez tester votre tout nouvel alias en lançant :

$ sshtoto

Cela ne vous dispensera pas cependant de saisir votre passphrase à chaque fois, mais c'est là un moindre mal et surtout un gage minimum de sécurité

Notes

[1] On accède JAMAIS à un serveur en root directement. C'est TRÈS mal. De toutes façons, si vous utilisez sudo et que vous n'avez pas créé de compte root en lui assignant un mot de passe, le problème de ne se pose pas

Ce billet intitulé Installer sa clé SSH sur un serveur distant a été rédigé par Nicolas Perriault et publié sur le blog Prendre un Café sous licence Creative Commons BY-NC-SA.

Redéfinir de force le mot de passe root de MySQL

NiKo — Wed, 17 Aug 2005 19:03:09 +0000

Il peut arriver d'oublier son mot de passe root MySQL ^[1], n'est-ce pas blowup ?

C'est très embêtant car pour redéfinir un nouveau mot de passe root, il faut entrer le mot de passe... root, et réinventer ainsi le mouvement perpétuel...

Voici une méthode pour lancer MySQL sans requérir d'authentification, et ainsi pouvoir assigner un mot de passe à l'utilisateur root. Attention, cette méthode ne doit pas être utilisée sur des serveurs de production et/ou sensibles, car à ce moment toutes vos bases sont accessibles à tous les utilisateurs MySQL.

Dans un shell, entrez la séquence de commandes suivante :

$ sudo -s
# /etc/init.d/mysql stop
# mysqld -u mysql --skip-grant

Attention, maintenant MySQL est lancé sans authentification, c'est à dire qu'il est ouvert à tous les utilisateurs. Vous pouvez également arrêter Apache2 afin de limiter les possibilité d'execution de scripts accédant à des bases non autorisées :

# apache2ctl stop

Note : Si vous utilisez d'autres services permettant l'accès à MySQL, je vous recommande fortement de les arrêter de même. Vous pourrez les relancer à la fin de l'opération.

Là, ouvrir un nouveau shell pour définir un nouveau mot de passe root/MySQL (CTRL + Shift + T dans gnome-terminal)

# mysqladmin -u root flush-privileges password "nouveau_mot_de_passe"

Fermer le premier shell, et tuez le daemon mysql ignorant l'authentification, puis relancez mysql au moyen de la commande :

# /etc/init.d/mysql restart

Si vous aviez stoppé Apache, voire d'autres services, il est tant de les relancer :

# apache2ctl start
# ...

Normalement, ça devrait rouler...

Notes

[1] qui, rappelons-le, n'est pas le même que l'utilisateur root du système

Ce billet intitulé Redéfinir de force le mot de passe root de MySQL a été rédigé par Nicolas Perriault et publié sur le blog Prendre un Café sous licence Creative Commons BY-NC-SA.

Mais où s'arrêtera Google ?

NiKo — Sun, 24 Apr 2005 13:23:42 +0000

Je ne sais vraiment plus quoi penser de Google. D'un côté, ils proposent de plus en plus de services en lignes potentiellement interessants et innovants, souvent spectaculaires (Google Maps, GMail, Google Groups V2, et plus généralement tout le bazar du Google Lab), et de l'autre, ce côté tentaculaire voire monopolistique d'une seule et même société en plein essor sur des services courants m'inquiète vraiment. A quand la Google Bank, le Google Fooding ou la Google TV ?

Un nouveau service Google apparu recemment illustre cette dichotomie^[1] : Google History, qui n'est ni plus ni moins qu'un service de sauvegarde de son historique des recherches effectuées sur Google - le tout stocké sur les serveurs Google afin de pouvoir récupérer son historique sur n'importe quel ordinateur relié au net. Tout y est : date, heure, référants, sites consultés, durées de consultation... Brrrrr. On imagine aisement quelques chefs d'état aux velleïtés totalitaires baver d'envie à l'idée de mettre la main sur la base de données dudit service. Et la question est : comment être sûrs que cela n'est pas/ne sera jamais le cas ? Impossible ! Les sources des applications proposées par Google ne sont pas consultables/compilables, impossible donc de s'assurer de ce qui se trame sur les serveurs une fois les requêtes envoyées.

Google serait-il donc en train de prendre le même chemin que - au hasard total - Microsoft, obfuscant toutes leurs technologies (essayez de mater le code source javaScript de GMail, vous comprendrez mieux), et en ne proposant que des frontends aux utilisateurs lesquels seront gentils de ne pas trop poser de questions ?

La réponse est peut-être dans la page de la Politique de Confidentialité Google :

Google peut dans certains cas partager les informations qui vous sont propres avec des annonceurs, des partenaires, des sponsors et certaines autres tierces parties. Toutefois, cette diffusion porte exclusivement sur des informations globales et génériques : nous nous engageons à ne pas publier d'informations permettant l'identification des personnes sans avoir obtenu au préalable l'accord explicite de celles-ci. Par exemple, nous pourrions indiquer le nombre de visites effectuées par l'utilisateur moyen sur le site de Google, les termes de recherche qui accompagnent le plus souvent le mot « Linux » ou le mot « cabriolet », etc. Enfin, vous devez être conscient du fait que nous sommes tenus de révéler vos informations personnelles dans le cadre de procédures légales telles que mandat de perquisition, assignation à comparaître, décision judiciaire, etc.

Ce sont les certaines tierces parties et le dernier etcaetera qui me laissent particulièrement perplexe.

Notes

[1] Merci Mitternacht, en effet : ça rox ^^

Ce billet intitulé Mais où s'arrêtera Google ? a été rédigé par Nicolas Perriault et publié sur le blog Prendre un Café sous licence Creative Commons BY-NC-SA.