Prendre un Café - Tag - sysadmin

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

Synchro distante automatique via un daemon rsync sur Ubuntu

NiKo — Thu, 18 Jan 2007 16:26:00 +0100

Et non ! Rsync n'est pas une voiture des années 90 mais bien un outil de synchronisation de fichiers à distance très puissant. Il peut notamment tourner en daemon afin d'autoriser les appels distants automatiques, via Cron par exemple.

Si par un hasard hallucinant vous ne disposiez pas de rsync sur votre Ubuntu, voici la démarche à suivre pour l'installer en ligne de commande :

$ sudo apt-get install rsync

Bien. Nous disposons de deux machines, la machine A - disposant d'un utilisateur jeanpierre - et la machine B - habitée par edmond. Nous devons automatiser la synchro d'un répertoire présent sur la machine A vers la machine B. On va donc installer un daemon rsync sur la machine A et le configurer en créant le fichier /etc/rsyncd.conf :

uid             = jeanpierre 
gid             = jeanpierre
use chroot      = no    
max connections = 4
syslog facility = local5
pid file        = /var/run/rsyncd.pid

[mon_partage]
  comment = Mon partage
  path = /home/jeanpierre/monpartage
  read only = yes
  list = yes
  hosts allow = *
  auth users = edmond, gerard
  secrets file = /etc/rsyncd.secrets

Je vous renvoie à cette page sur la syntaxe du fichier rsync.conf pour plus de renseignements.

On crée un fichier process vide :

jeanpierre@machineA:~$ sudo touch /var/run/rsyncd.pid

Les comptes utilisateurs se définissent dans le fichier /etc/rsyncd.secrets sous la traditionnelle forme login:motdepasse comme ci-dessous :

edmond:3dm0nd
gerard:g3r4rd

Par souci de sécurité et de confidentialité, ces fichiers ne devront pas être lisibles par un autre utilisateur que le root, donc :

jeanpierre@machineA:~$ sudo chmod 640 /etc/rsyncd.conf
jeanpierre@machineA:~$ sudo chmod 640 /etc/rsyncd.secrets

Lancer rsync en daemon sur la machine A (machinea.domain.tld) :

jeanpierre@machineA:~$ sudo rsync --daemon

Et depuis la machine B (machineb.domain.tld) :

edmond@machineB:~$ rsync -avz edmond@machinea.domain.tld::mon_partage ~/mon/repertoire/cible

La saisie du password de l'utilisateur edmond défini précedemment lancera la synchronisation effective des fichiers. Pour éviter la saisie manuelle du password, il faut envisager d'utiliser l'option --password-file=FILE. Pour se faire, il faut créer un fichier contenant juste le mot de passe en clair, par exemple dans /home/edmond/.rsync_passwd comme ceci :

3dm0nd

Ce fichier devra n'être accessible que par l'utilisateur système utilisant la commande rsync. Dans le cas de l'utilisateur connecté à la machine B :

edmond@machineB:~$ chmod 640 /home/edmond/.rsync_passwd

On peut alors lancer une synchro de cette façon :

edmond@machineB:~$ rsync -avz edmond@machinea.domain.tld::mon_partage ~/mon/repertoire/cible --password-file=/home/edmond/.rsync_passwd

L'avantage de cette ligne de commande est qu'elle peut être appellée depuis un Cron et donc ne pas nécessiter de saisie du mot de passe manuellement.

Enfin, sachez que les éventuelles erreurs d'authentification seront logguées dans le fichier /var/log/syslog.