PREMIER MINISTRE

Secrtariat gnral de la dfense et de la scurit nationale Agence nationale de la scurit des systmes dinformation

Paris, le 27 juillet 2012 No DAT-NT-002/ANSSI/SDE/NP Nombre de pages du document : 7

Note technique Recommandations de scurit relatives un systme GNU/Linux

Informations

Personnes ayant contribu la rdaction de ce document: Contributeurs Division assistance technique, Bureau audits et inspections Rdig par Laboratoire architectures matrielles et logicielles Approuv par SDE Date 5 juillet 2012

volutions du document : Version 1.0 1.1 Date 5 juillet 2012 26 juillet 2012 Nature des modications Version initiale Corrections mineures

Pour toute remarque: Contact Bureau Communication de lANSSI Adresse 51 bd de La Tour-Maubourg 75700 Paris Cedex 07 SP @ml Tlphone

communication@ssi.gouv.fr

01 71 75 84 04

No DAT-NT-002/ANSSI/SDE/NP du 27 juillet 2012

Page 1 sur 7

Prambule
Ce document ne se veut pas une procdure gnrique de scurisation dun systme GNU/Linux, les bonnes pratiques appliquer dpendant de la fonction de la machine scuriser (serveur, poste client, passerelle, etc.). Les lments qui suivent ne sauraient donc aucunement avoir un caractre exhaustif. Il sagit simplement dnoncer les principaux axes de durcissement explorer. Ces derniers viennent en complment de principes de base applicables tout systme deploitation comme par exemple lapplication rgulire des correctifs. Il convient bien entendu dtudier lapplicabilit de chaque recommandation au cas despce considr. Il est par ailleurs fortement conseill davoir recours aux comptences dun expert du systme GNU/Linux pour la mise en oeuvre de ces bonnes pratiques.

Principe de base : Rduction de la surface dattaque !

En premier lieu, minimisation est un leitmotiv qui doit guider la conguration scurise dun systme GNU/Linux quel que soit son usage : il faut supprimer tous les lments logiciels superus pour rduire la surface dattaque (tout ce qui est inutile aux utilisateurs lgitimes ne servira qu lattaquant). Le principe de minimisation de la surface dattaque sapplique non seulement la couche utilisateur (userland ), mais aussi au noyau. Au niveau userland : Cela passe notamment par llimination des services inutiles en coute sur le rseau 1 , en priorit, ainsi que des services qui sexcutent sous le compte root et qui ne sont pas ncessaires au fonctionnement du systme (exemples : pulseaudio ou dbus ). Dans le cas dun serveur, cela passe notamment par llimination du serveur X, qui constitue un service particulirement complexe et privilgi. On notera bien que le terme "limination" pris dans ce contexte ne signie pas ncessairement la dsinstallation des programmes associs, qui peut savrer impossible du fait de dpendances entre paquetages. Dans un tel cas de gure, il peut savrer ncessaire de conserver le dmon install sur le systme, mais en faisant en sorte quil ne soit pas lanc automatiquement. De manire complmentaire, on pourra chercher dsinstaller tous les programmes qui ne sont pas utiles dans le contexte dutilisation lgitime du systme, et dont linstallation nest pas strictement ncessaire au titre des dpendances entre paquetages. De tels programmes ne peuvent en eet servir qu un attaquant. A titre dexemple, si la prsence dun compilateur ou dun dbogueur (gdb) sur le systme cible nest jamais strictement ncessaire la mise en oeuvre dune attaque, la disponibilit de tels outils peut souvent faciliter grandement la tche de lattaquant. Lorsque la machine comporte plusieurs interfaces rseau, il est souhaitable de spcialiser celles-ci pour dissocier les dirents type de ux mtiers et les ux dadministration. Il convient alors dimposer que les services soient en coute uniquement sur les interfaces adaptes. Par exemple, dans le cas dun serveur Web dot de deux interfaces, le serveur http ne sera en coute que sur linterface de production alors que le serveur ssh ne sera en coute que sur linterface dadministration. Le principe de moindre privilge doit aussi tre gard lesprit tout au long de la conguration du systme. On limitera ainsi autant que faire se peut lensemble des programmes privilgis. En particulier, outre les dmons excuts en tant que root (dcrits plus haut), les ventuels scripts lancs en arrire plan par un cron et les programmes setuid doivent tre les moins nombreux possibles. 2 On
1. La commande netstat --programs --listening permet dinventorier les programmes en coute sur une socket rseau ou locale. 2. La commande find / -user root -perm /u+s permet de lister les excutables setuid root du systme.

No DAT-NT-002/ANSSI/SDE/NP du 27 juillet 2012

Page 2 sur 7

notera en particulier quattribuer un bit setuid un programme qui na pas t dvelopp spcialement pour cela constitue gnralement une grave erreur. A ce titre, lorsquil est ncessaire de dlguer des privilges daccs via un excutable spcique, il est prfrable de raliser un contrle daccs par groupe en sappuyant sur le bit setgid, plutt quun contrle daccs par utilisateur reposant sur un bit setuid. Lorsquelles sont disponibles, il conviendra enn dactiver les options de certains programmes privilgis (par exemple dmons SSH ou IKE) permettant une rduction de privilges 3 ou une sparation de privilges 4 . De manire complmentaire, les mcanismes de contrle daccs obligatoires constituent un trs bon moyen de limiter les privilges de programmes. La dicult de mise en uvre de ces mcanismes rside souvent dans leur conguration. Cest particulirement le cas de SELinux. Certaines alternatives moins complexes que SELinux sont alors envisageables (Tomoyo, AppArmor, ACL grsecurity, etc.). Lutilisation des capacits (capabilites ) permet aussi de rduire le pouvoir de nuisance de programmes privilgis compromis. Ces capacits, qui consistent en une discrtisation des dirents privilges associs en gnral root, peuvent tre utilises de deux manires distinctes. Dune part, pour les distributions qui le supportent, le mcanisme des capacits de chiers (le capabilities ) ore une alternative mieux matrise lattribution de bit setuid root des excutables. Dautre part, certains programmes et dmons excuts par root orent optionnellement (par une option de compilation ou de conguration selon le cas) la possibilit de rduire leurs privilges au strict ncessaire - ces options doivent tre actives lorsquelles sont supportes. Enn, il est important de limiter de manire gnrale les programmes ralisant une analyse (parsing) sur des donnes non matrises de format complexe quelles soient issues du rseau ou locales appartenant un utilisateur non privilgi. En eet, les fonctions de parsing associs des formats complexes prsentent frquemment des vulnrabilits. titre dexemple, un navigateur web traite des donnes extrmement complexes et, il est impossible de garantir labsence de vulnrabilits dans les traitements eectus. Ainsi, un tel navigateur ne doit pas tre mis en uvre sur une machine autre quun poste client mme sous une identit non privilgie. Au niveau du noyau : Il est fortement recommand de mettre en uvre un noyau sur mesure vis--vis des priphriques matriels et des fonctions logiques dont aura besoin le systme. Par exemple, un serveur naura probablement pas besoin de wi, de bluetooth et de manire gnrale de toutes les piles protocolaires qui sont susceptibles de contenir des failles permettant un attaquant dobtenir des privilges noyau. Un serveur naura pas non plus besoin de supporter plusieurs modles de cartes rseau, de cartes graphiques, etc. On prfrera des noyaux non modulaires pour contrer des lvations de privilge via des modules malveillants. Faute de pouvoir dsactiver compltement le support des modules, on bloquera leur insertion dans le noyau au terme du dmarrage du systme 5 . Cette dernire recommandation sapplique galement dans les situations o la conguration dun noyau sur mesure est trop complexe mettre en uvre, soit parce que le parc de machines est trs htrogne, soit parce quon ne dispose pas des moyens humains ncessaires au suivi des mises jour du noyau. Un noyau de distribution gnrique jour peut en eet tre prfrable un noyau sur
3. Le programme rvoque ses privilges ds lors quil nen a plus besoin. 4. Les traitements les plus complexes sont relgus un programme esclave non privilgi. 5. crire 1 dans /proc/sys/kernel/modules_disabled.

No DAT-NT-002/ANSSI/SDE/NP du 27 juillet 2012

Page 3 sur 7

mesure sur lequel les correctifs de scurit ne sont pas appliqus. Enn, la posture de mance lgard des fonctions de parsing, recommande plus haut, sapplique plus forte raison au niveau du noyau.

En complment, raliser une dfense en profondeur.

Dfense en profondeur est galement une autre rgle qui sapplique la conguration scurise dun systme : il convient dviter de satisfaire une exigence de scurit par un seul mcanisme. Au contraire, il est recommand de multiplier les barrires. Par exemple, la mise en place dun pare-feu local en complment de la suppression des services inutiles est recommande. Un tel pare-feu permettra aussi par exemple contrler les connexions inities depuis un serveur (celui-ci a-t-il dailleurs vocation ouvrir des connexions ?) Il est fortement recommand de partitionner un systme de manire rationnelle. Un partitionnement bien rchi a plusieurs vertus : viter la saturation. Il est ce titre utile de placer sur une partition distincte tout rpertoire susceptible dtre rempli la suite dactions extrieures (journaux, "spool" dimpression, le dattente de messages ou base de donne associe un serveur web), en particulier lorsque le service susceptible de remplir le rpertoire tourne sous lidentit root ; simplier la sauvegarde ; appliquer des options de montages ncessaires et susantes (ro, nodev, noexec et nosuid). Le dernier point est souvent ignor et pourtant il est extrmement important et permet de contrer facilement un grand nombre dattaques. Par exemple, les supports de stockage amovibles doivent imprativement tre monts en nodev,noexec,nosuid (cest normalement le cas par dfaut, mais il est important de le vrier). Cette mme combinaison peut ventuellement sappliquer aussi /home (les utilisateurs ont-ils besoin dexcuter du code prsent dans leur home ?). /tmp et /var/tmp nont gnralement pas besoin de exec (il convient dexaminer scrupuleusement les ventuels programmes qui imposeraient de contrevenir cette rgle : cela dnote frquemment une mauvaise conception logicielle). En outre, la grande majorit des montages se fait en nodev mais lorsquelles le supportent, les partitions doivent tre montes de prfrence en lecture seule. Il est utile de noter que certaines distributions Linux crent automatiquement des rpertoires et points de montage accessibles en criture universelle et disposant de loption exec (par exemple /dev/shm, /run/shm, /run/lock etc.). Il est souhaitable dajouter loption "noexec" ces montages selon les modalits propres chaque distribution. En gnral, le rajout dune ligne correspondant au montage dans /etc/fstab sut. En lien avec le partitionnement des supports de stockage, il y a lieu de sinterroger sur le chirement des donnes. Le chirement du disque, de prfrence avec des moyens qualis par lANSSI est videmment indispensable sur un poste client (a fortiori si celui-ci est utilis en condition de nomadisme). La question se pose plus sur une machine faisant oce de serveur. Tout dpend du niveau de sensibilit des donnes quil hberge et de la protection physique de lquipement. Dans le cas de donnes sensibles, mme si le serveur est stock dans un bunker, le chirement permet de se rassurer pour le cas o les procdures de recyclage de disques savrent laxistes (concrtement, si les disques ne sont pas dtruits physiquement aprs usage), ce pour un surcot relativement modeste. En revanche, dans de rares cas quil convient dapprcier, le chirement peut prsenter un risque pour la disponibilit (si ladministrateur perd les cls, par exemple). No DAT-NT-002/ANSSI/SDE/NP du 27 juillet 2012 Page 4 sur 7

Il est aussi fortement recommand dappliquer des correctifs (patchs ) de durcissement du noyau lors de la recompilation de ce dernier. Il est par exemple ici question des protections gnriques du sous-systme de gestion de la mmoire servant protger le systme contre des attaques qui exploitent des vulnrabilits de type corruption mmoire (PaX), mais aussi des options de durcissement diverses proposes par grsecurity (masquage des entres de /proc, listes blanches dutilisateurs autoriss crer des sockets, durcissement de chroots, etc.). Dans tous les cas, une analyse ne des droits positionner sur les chiers devra tre eectue. En eet, labsence de rgles peut laisser la porte ouverte des lvations de privilges ! Il est notamment recommand de limiter autant que possible le nombre de chiers systmes sur lesquels lon attribue des droits dcriture tous les utilisateurs. On peut aisment raliser une revue des chiers prsentant cette caractristique avec la commande find /etc /usr /bin /sbin /var -type f -perm /o+w, an de sassurer que les recours cette conguration sont tous rellement ncessaires. Pour une analyse plus ne de la conguration des droits, il est galement possible de mettre en oeuvre des scripts spcialiss, comme ceux issus du paquetage Bastille Linux, qui sont en mesure de dtecter et ventuellement corriger un certain nombre derreurs classiques de conguration.

Cloisonner les dirents services.

Pour accompagner ces mesures (exceptionnellement en substitut), cloisonnement et isolation sont galement des aspects primordiaux de la conguration scurise, tout particulirement dans le cas dun serveur. Il est ainsi fortement recommand denfermer les services dans des environnements dexcution isols du reste du systme (socle et autres services) an de circonscrire au mieux les consquences dune intrusion. On privilgiera pour ce faire les solutions de type lxc, vservers ou openvz qui sont globalement plus robustes quun chroot et dont lisolation ne se cantonne pas au systme de chiers.

Autres points de scurisation !

Il faut videmment scuriser les modes de connexion et dauthentication au serveur, notamment pour les accs dadministration. On imposera par exemple lutilisation de comptes non privilgis et traables 6 et un emploi correct de cls SSH, cest dire protges par des passphrases dont la partie prive nest pas copie sur les serveurs facilitant ainsi des attaques par rebonds 7 . Comme dj voqu en prambule, les systmes GNU/Linux nchappent bien entendu pas aux thmatiques de scurit usuelles pour tous systmes : procdure de mise jour avec une attention particulire sur leur origine 8 (penser aux implications du durcissement du socle de base et du remontage de partitions en lecture/criture, par exemple) ; gnration et exploitation des journaux du systme ; problmatiques de sauvegarde ; supervision en temps rel, notamment pour les indicateurs de scurit (checs de connexion, utilisation du compte root, etc.) ; scurit physique, notamment pour laccs la console locale.
6. et pas ssh root@server. 7. Dans le cas o les rebonds sont lgitimes, on privilgiera le mcansime d agent-forwarding . 8. La signature cryptographique des mises jour permet par exemple de les authentier.

No DAT-NT-002/ANSSI/SDE/NP du 27 juillet 2012

Page 5 sur 7

Pour pousser la scurisation un peu plus loin, il est possible dutiliser certaines distributions qui proposent la recompilation systmatique des logiciels pour matriser et durcir la chane de compilation des paquetages (imposer par exemple que les excutables soient relocalisables (CFLAGS="-fpie") pour que la randomisation dadresse (ASLR) puisse tre ecace, protger le systme contre les buer overow dans la pile (CFLAGS="-fstack-protector-all"), le durcir de manire gnrique (CFLAGS="-D_FORTIFY_SOURCE=2") ou encore scuriser le chargement dynamique (LDFLAGS="-Wl,-z, relro -Wl,-z, now")). Cela ncessite toutefois un suivi et une organisation rigoureuse. Une alternative moins lourde peut consister ne recompiler localement que certains paquetages dune distribution classique, par exemple ceux correspondant des dmons rseau exposs lextrieur. dfaut, on privilgiera les distributions rputes qui proposent une politique de mise jour de scurit claire et srieuse sur les distributions plus condentielles. Il est en eet souhaitable de rduire le plus possible la fentre temporelle entre la dcouverte dune faille dans un logiciel et le dploiement du correctifs dans la distribution considre.

No DAT-NT-002/ANSSI/SDE/NP du 27 juillet 2012

Page 6 sur 7

En synthse, les recommandations minimales respecter :

A minima, lANSSI estime que les 5 recommandations suivantes doivent tre appliques. Lorsque leur suivi nest pas possible, il doit tre justi et les risques induits assums. R1 Rduire la surface dattaque en : mettant jour rgulirement le systme ; supprimant les logiciels inutiles ; limitant au juste besoin les services en coute pour chaque interface rseau ; dsactivant le chargement dynamique des modules ; appliquant le principe de moindre privilge aux logiciels ; utilisant un mcanisme de contrle daccs reposant sur les rles (Tomoyo, AppArmor, ACL grsecurity) ; adaptant le noyau (suppression des lments inutiles, application des patchs de durcissements) au contexte demploi envisag.

Note : Certaines mesures ncessitent une certaine expertise technique et leur mise en uvre peut impacter la disponibilit du systme quil convient de bien apprcier au pralable. R2 Appliquer le principe de dfense en profondeur en : utilisant un pare-feu local ; implmentant un schma de partitionnement et les options de montage adapts au contexte demploi ; positionnant les droits en lecture, criture et excution sur les chiers aprs une analyse ne des besoins des utilisateurs mais aussi des services locaux. Une attention particulire sera porte sur les scripts lancs automatiquement ; chirant les donnes.

Note : L aussi, il convient de bien apprcier limpact de ces mesures avant de les mettre en uvre. R3 R4 Mettre en place des mesures de cloisonnement pour isoler les dirents lments applicatifs. Rdiger et appliquer les procdures dadministration scurises (enregistrement des donnes de connexion des exploitants, supervision, mises jour, sauvegardes, etc.). Dnir et mettre en place une politique de journalisation dvnements cohrente : distinguant dirents niveaux de criticit selon leur impact sur la scurit du systme ; permettant la remonte dalertes en fonction de ces niveaux.

R5

No DAT-NT-002/ANSSI/SDE/NP du 27 juillet 2012

Page 7 sur 7