sécurité - Prendre un Café

Keyword - sécurité

lundi 5 février 2007

Sécuriser son Ubuntu-server

Par NiKo le lundi 5 février 2007, 23:00 - Ubuntu

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...

19 commentaires un rétrolien

lundi 29 août 2005

Installer sa clé SSH sur un serveur distant

Par NiKo le lundi 29 août 2005, 23:33 - Ubuntu

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

14 commentaires un rétrolien

mercredi 17 août 2005

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

Par NiKo le mercredi 17 août 2005, 19:03 - Ubuntu

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

4 commentaires

dimanche 24 avril 2005

Mais où s'arrêtera Google ?

Par NiKo le dimanche 24 avril 2005, 13:23 - Divers

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 ?

2 commentaires