Admin-admin plus-secur
- Sécuriser linux.
- 1. Stratégie de mot de passe, de comptes et shadowing.
- 2. Stopper les services inutiles et dangereux.
- 3. Filtrer les services
- 4. Mettre à jour son kernel et ses packages contre les bugs connus
- 5. Vérifier les permissions.
- 6. Bloquer les logins dangereux des services.
- 7. N'autoriser les services qu'à certaines machines distantes.
- 8. Conclusion.
- Copyright
Sécuriser linux.
Cette partie va vous permettre de sécuriser votre machine Linux, déjà contre des attaques lorsque vous vous connectez sur Internet (surtout si vous faites de l'IRC, les attaques sont fréquentes), si votre machine sert de serveur WEB, etc... Bien sûr si votre machine est en poste isolé et que vous ne vous connectez jamais à l'Internet, ce n'est pas la peine de sécuriser votre machine.
Attention : je ne me considère absolument pas expert en sécurité réseau, je vous donne juste des conseils de bases pour un premier niveau de sécurité, je vous rappelle que des bugs de sécurité apparaissent quasiment tous les jours, à vous donc de vous informer et de vous tenir à jour pour une plus grande sécurité. Je ne vous donne QUE ma connaissance et des principes de bases.
1. Stratégie de mot de passe, de comptes et shadowing.
Tout d'abord la sécurité passe par des mots de passe utilisateurs. Il est impensable de laisser un compte utilisateur sans mot de passe. Pour une sécurité accrue je vous conseille fortement de :
- Mettre des mots de passe de 8 caractères minimum. (entre 10 et 12 est fortement recommandé)
- Mélanger des caractères minuscules, majuscules et numériques (ex: imDe56T4z).
- Ne pas mettre des mots contenus dans un dictionnaire (style nom propre ou nom commun).
Ok, les mots de passe de ce style sont très durs à retenir soi-même, mais si votre site est sensible cela est nécessaire. Même si les mots de passe sont encryptés sous linux il existe des décrypteurs de deux types, soit basés sur un dictionnaire (donc si votre mot de passe n'existe pas dans un dictionnaire un tel décrypteur ne le trouvera jamais), soit un décrypteur dit de force, ceux-là par contre essayent toutes les possibilités pour découvrir votre mot de passe. Il renvoie donc plusieurs mots de passe possibles. Si votre mot de passe est du style MédOr1999 il sera vite repéré dans la liste des mots de passe obtenus et l'attaquant est quasi sûr de l'avoir trouvé. Par contre s'il obtient 100 mots de passe de style efTDgf45Ft il sera déjà plus découragé. Mais il risque de le trouver quand même, s'il s'acharne. Donc on va déjà essayer aussi de sécuriser encore plus.
Les mots de passe sous Linux ou UNIX sont généralement contenus dans le fichier /etc/password ainsi que toutes les infos systèmes des comptes utilisateurs. Ce fichier est en lecture seule pour tout le monde pour le besoin de différents programmes, et juste en écriture pour le ROOT pour l'administration. Le problème est que si on peut le lire, on peut donc le récupérer et tenter un décryptage de force dessus. Alors on a inventé le shadowing. Les mots de passe ne sont plus stockés dans le fichier /etc/password mais dans un fichier généralement (pas toujours) appelé /etc/shadow. Ce fichier est par contre illisible par tout le monde sauf le root bien sur. Ce qui permet déjà à tous les utilisateurs non root de ne pas pouvoir récupérer ce fichier. Donc je vous conseille FORTEMENT d'installer le package SHADOW sur votre machine.
Tester aussi le guest, celui-ci est présent sur certaine distribs sans mot de passe (très dangereux !), essayez de vous loguer en guest, si ça marche c'est un trou de sécurité énorme! je vous conseille même d'enlever complètement ce compte utilisateur (supprimez la ligne correspondante dans /etc/passwd). De même pour les comptes systèmes comme FTP, UUCP, etc etc. Vérifiez bien que ces comptes soient désactivés, c'est-à-dire que le système lui-même peut s'en servir mais que l'on ne peut pas se loguer avec. Pour vérifier cela, ces comptes doivent apparaître comme ceci :
Pour ceux qui n'ont pas de shadow, dans /etc/password les comptes systèmes apparaissent comme ceci :
nomducompte:*: .... l'étoile désactive le compte (si n'y a pas * le compte est SANS MOT DE PASSE!!)
Pour ceux qui ont shadow, dans /etc/passwd :
nomducompte:x:.....
et dans /etc/shadow :
nomducompte:*:.....
Attention donc à cette syntaxe.
2. Stopper les services inutiles et dangereux.
Par défaut plusieurs services réseau sont installés et démarrés par Linux, dont certains très dangereux.
Pour désactiver ces services, tout dépend de la version du super démon dont vous disposez sur votre distribution :
- vous disposez de inetd : éditez le fichier /etc/inetd.conf, repérez la ligne contenant le nom du service que vous voulez désactiver. Commentez la ligne (ajoutez # devant s'il n'y est pas déjà).
Puis faire reloader la configuration pour prendre en compte les modifications :
root@pingu# kill -HUP n°PID_de_inetd - vous disposez de xinetd : éditez le fichier correspondant au service que vous voulez désactiver, dans /etc/xinetd.d. Editez-le et à la ligne disable = no, remplacez no par yes. Enregistrez les modifications et reloadez xinetd
root@pingu# kill -HUP n°PID_de_xinetd
Tout d'abord le service fingerd doit être absolument arrêté ! Désactivez netstat de la même façon. On peut dire que ces deux services sont très dangereux pour la sécurité de votre système, le premier fournissant les noms des users présents sur votre machine, le deuxième donnant tous les services démarrés donc ceux qui sont vulnérables à des bugs de sécurité.
De même stoppez tous les services qui ne vous servent pas, par exemple ftpd, pop2, pop3, telnetd, ... Bien sûr laissez ouvert les services dont vous avez besoin. Voici quelques bugs connus de services :
- httpd : si vous faites de votre Linux un serveur Web, faites attention au bug du PHP, langage de page dynamique sous Apache. Si vous ne vous servez pas de PHP, désactivez le tout simplement (dans les fichiers de conf de apache, je vous renvoie à son HOWTO), par contre si vous l'utilisez, attention à bien utiliser la version 3 de PHP ainsi que de la dernière version d'Apache avec ses fichiers de conf (corrigés pour enlever le bug de PHP). Utilisez toujours la dernière version stable ! Des bugs sont corrigés tout le temps sur les serveurs HTTP. N'utilisez pas les extensions Frontpage qui comportent beaucoup de trous de sécurité. Assurez-vous que le daemon tourne en user spécialement créé pour lui (créez un user http par exemple avec des droits très reduits comme ça si quelqu'un trouve un bug de sécu sur votre daemon HTTP il n'aura que les accès de cet user et pas plus). Ne lancez pas le DAEMON HTTP EN ROOT ! Ne lancez pas un CLIENT HTTP EN ROOT ! Si vous avez besoin de scripts CGI, activez le CGIWRAP !
- fptd : wu-ftpd a connu de nombreux bugs de sécurité aussi, je vous conseille donc d'utiliser un autre serveur ftp, comme le beroftpd par exemple. De plus configurez les accès par le fichier /etc/ftpaccess (faite un man ftpaccess, tout est expliqué, regardez le HOWTO aussi). Autorisez le minimum, c'est-à-dire un serveur juste anonymous avec interdiction pour les realusers (compte existant) qui donne accès au répertoire home des users ainsi qu'à ceux du système, alors que les anonymous donnent accès juste au répertoire home du ftp et pas au reste de la machine. Pas de login de user réel tout simplement parce que les mots de passe passent en clair sur le réseau (un coup de sniffeur et votre mot de passe est lisible de tous...).
- sendmail : Attention aussi à avoir la dernière version, configurez aussi pour interdire le forward de courrier (autrement votre machine servira de bonne passerelle pour les hackers).
- telnetd : je vous conseille plutôt de désactiver purement et simplement ce service, préférez plutôt si vous avez à prendre la main à distance sur votre serveur un gettyps (prise de main à distance via un modem sur port série de votre machine, déjà le hacker devra connaître le numéro de téléphone du modem pour se connecter sur votre machine). De plus telnet a le "facheux inconviénient" de faire passer les mots de passe en clair ! Donc un sniff de votre réseau et hop le mot de passe est dans la poche !!!
- Samba : si vous n'avez pas l'utilité de celui-ci ne l'activez surtout pas, il est sujet à des bugs et ouvre des partages. Si vous l'utilisez, attention à avoir une version récente, à bien configurer les partages sur des répertoires ne contenant aucun fichier critique et sur des répertoires non sensibles (pas de partage sur /etc, /bin, /sbin, /usr etc mais sur des homes/smb par exemple, répertoires dédié pour des partages SAMBA).
- Si vous utilisez NFS, utilisez /etc/exports (ou /etc/dfs/dfstab) de manière à exporter que ce que VOUS voulez (voir avec nfs-howto), n'exportez pas les fichiers de configuration NFS non plus bien sûr, exportez seulement vers des domaines connus et pas vers "localhost" non plus. Attention à ne pas depasser aussi 255 charactères dans vos liste d'alias d'export.
- Désactivez toute les commandes de type "r" (rlogin, rexec, etc), elles ont de gros trous de sécurité ; surtout si un malin "sniffe" votre réseau il risque de voir passer en clair des mots de passe.
Bien d'autre services sont dangereux aussi, de toute facon si un service n'est pas utilisé, il vaut mieux le désactiver. Sacher que tout service de type UDP (regarder dans /etc/services, a droite du nom du service vous avez le port et le protocole utilisé, certains utilisent UDP) sont sujet à des attaques DoS, Dénial of Services, c'est à dire qu'en envoyant certains packets UDP on peut faire "planter" soit le service lui-même, soit une série de services soit la machine elle même. Stoppez donc tout service UDP inutile.
Le problème que nous venons d'évoquer n'existe bien sûr que si vous avez besoin de ces services et que votre machine est reliée à l'internet. Le filtrage résoud ce probléme (voir ci-dessous).
3. Filtrer les services
Comme le filtrage n'est pas une chose simple à faire je vous renvoie a la rubrique Sécurité (Firewall) de la section réseau.
4. Mettre à jour son kernel et ses packages contre les bugs connus
Attention aussi si vous êtes possesseur d'une vieille distribution à base de kernel de la série 2.0.x ou 1.x.x . Il y a des bugs réseau qui permettent aux attaquants de faire des attaques DoS (Denial of Service, c'est-à-dire arrêter des services réseaux de votre machine ou de la planter complètement). Je vous conseille donc de mettre à jour le kernel de votre système (à partir de la 2.0.36 pour les séries 2.0.X, pour les séries 1.X.X, je pense qu'il est temps de passer à une série 2.0.X ou 2.2.X) ainsi que les packages réseau (allez voir sur les sites dédiés aux distributions et récupérez les packages réseau mis à jour depuis). Je vous signale aussi que prendre les toutes dernières versions des packages ou kernel n'est pas une si bonne idée si votre site est sensible, en effet des bugs peuvent se révéler plus tard, préférez des kernels et packages réputés stables. Vous comprenez facilement que je ne peux pas dire tel ou tel kernel ou tel package a tels bugs etc... Pour vérifier allez sur www.rootshell.com : les bugs, exploits, etc. y sont référencés, à vous de voir si de tels trous de sécurité existent sur votre machine.
5. Vérifier les permissions.
Attention aussi à ne pas changer des permissions sur des fichiers ou répertoires parce que cela va vous aider à un moment pour votre travail ou un autre, on a souvent la malheureuse manie d'oublier de remettre les bons droits après (surtout ne touchez pas au permissions des programmes administratifs contenus dans /bin, /sbin, /usr/sbin).
Aussi, n'activez jamais le bit SUID root sur des fichiers, c'est là aussi un énorme trou de sécurité ! Même si certains HOWTOs (celui de quake par exemple) vous indiquent cette solution pour faire tourner des programmes par un simple user, je vous déconseille fortement de mettre cette permission sur un fichier exécutable. De tels fichiers avec cette permission permettent d'agir en tant que root directement et c'est une porte ouverte à un hack ! Ne fixez jamais une telle permission sur un fichier.
Vérifiez aussi :
- /etc/hosts.lpd : si vous en avez besoin, vérifiez que les permissions sur ce fichier sont bien 600 et que le propriétaire est "root".
- /etc/securetty : en plus de sa configuration expliquée plus haut, assurez vous que le propriétaire de ce fichier est root et "644" comme permission.
- /etc/inetd.conf : propriétaire root et "600" comme permission.
- /etc/services : propriétaire root et "644" comme permission.
6. Bloquer les logins dangereux des services.
Si vous devez fournir certains services comme le FTP, telnet... il vaut mieux bloquer certains logins dangereux. Si vous devez absolument permettre aux utilisateurs d'utiliser le FTP, bloquez la connexion des comptes critiques comme le root, comptes systèmes etc. (même si cela à déjà été bloqué par le /etc/passwd).
Pour le FTP, éditez le fichier /etc/ftpusers et incluez les comptes dont vous interdisez l'accès :
root
uucp
bin
mail
Et oui il vaut mieux désactiver le compte root pour le ftp aussi ! D'ailleurs pour ce compte on va interdire l'accès de partout sauf sur la console (c'est-à-dire sur la machine physiquement), grâce au fichier /etc/securetty :
tty1
tty2
tty3
tty4
Logiquement jusqu'au tty7. Si on veut faire de la téléintervention par modem, on peut alors aussi ajouter le ttySx ou ttySx est le port série du modem qui sert à la télémaintenance. Dans ce fichier on inclut les terminaux où on autorise le root à se connecter.
7. N'autoriser les services qu'à certaines machines distantes.
Toujours dans le cas où les services ne sont pas stoppés parce que vous savez que certains utilisateurs distants doivent s'en servir, il est judicieux aussi de n'autoriser que ces machines et pas d'autres. Cela se fait à l'aide du fichier /etc/hosts.allow dont la syntaxe est très simple :
<listes des services>:<listes des machines>:<commandes spéciales à exécuter>
La liste des services est du style telnetd, ftpd, etc etc...
La liste des machines ou d'un domaine (LOCAL donne accès au domaine local, très utile, ALL pour tout le monde, toutes les connexions donc)
Les commandes spéciales : une commande à exécuter quand il y a une connexion sur ce service, par exemple un "mail -s "connexion par la machine %h" root " sur le service telnetd enverra automatiquement un mail au root local donnant l'adresse de la machine distante qui s'est connectée au service telnet de votre machine.
De même qu'il y a un fichier qui autorise les connexions, il y a un fichier qui interdit les connexions et qui s'appelle /etc/hosts.deny. Le plus simple dans ce fichier est de mettre ALL:ALL qui interdit tout à tout le monde et de laisser les autorisations dans le fichier /etc/hosts.allow, comme ça seul ceux qui sont présents dans /etc/hosts.allow pourront utiliser les services.
Ne croyez pas que vous êtes protégés contre toute machine inconnue avec cette technique, car il existe des techniques de "SPOOF" qui permettent à une machine de se faire passer pour une autre en lui usurpant son adresse. Certain hackers sont passés maîtres dans ces techniques, donc prudence quand même ! De plus comme vous autorisez l'accès par une autre machine soyez sûr que l'administrateur de cette machine l'a bien protégée, autrement un piratage chez lui donnera au pirate un accès chez vous !
Attention au fichier /etc/hosts.equiv qui donne l'accès aux machines présentes dans ce fichier à votre machine SANS MOT DE PASSE !!! à ne pas utiliser sauf si vous êtes dans un environnement sécurisé sans accès par l'extérieur (aucun modem, ligne, etc etc...).
8. Conclusion.
On peut dire que dès qu'un service réseau n'est pas utilisé, desactivez le tout simplement. Tout service utilisé ne doit jamais être lancé en root (celui qui trouve un bug sur ce service peut s'en servir pour exécuter des commandes, s'il tourne en tant que root il pourra tout faire, même le pire.
Ce que je vous explique là-dedans, c'est pour un premier niveau de sécurité, pour augmenter encore plus la sécurité je vous conseille vivement de lire la rubrique FIREWALL.
Copyright
Copyright © Serge Tchesmeli
| Vous avez l'autorisation de copier, distribuer et/ou modifier ce document suivant les termes de la Licence pour documents libres, Version 1.1 publiée par la La Guilde des Doctorants. Pour plus d'informations consulter la LDL sur le site de La Guilde des Doctorants. |



