Quelques bonnes pratiques de sécurisation d’un serveur Linux, partie 6

Twitter Facebook Google Plus Linkedin email
closeCet article a été publié il y a 2 ans 11 mois 6 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées, les commandes ne sont peut-être plus valides.

Ce coup-ci, c’est le dernier, promis. En conclusion, j’aimerais évoquer d’autres outils permettant de renforcer la sécurité d’un système, mais que je n’ai jamais approché, soit par opportunité, soit par crainte, notamment de ne pas avoir le niveau pour comprendre leurs implications. En clair, des outils de vrais barbus 🙂 Et aussi l’activité reine du domaine : la veille.

Rappel : il est évident qu’on ne saurait être exhaustif quand il s’agit de sécurité. Que ce soit le contexte d’installation du serveur ou son utilisation, je ne saurais couvrir tous les besoins. Aussi, il ne faut pas hésiter à me corriger quand je dis une énorme connerie 🙂

SELinux (et autres LSM)

SELinux est l’un des nombreux LSM (Linux Security Module) du noyau. Un de ses principes de fonctionnement est de définir plus finement les conditions et droits d’exécution/accès des processus sur un ensemble de règles. Par défaut sous Linux, les droits d’accès au fichier se résument à lecture, écriture, exécution pour propriétaire, groupe, autres. SELinux permet de définir des rôles, des contextes, des utilisateurs « virtuels », entre autres.

Il a été en partie développé au départ par la NSA, ce qui paraît marrant à l’ère post-snowden. Vous pouvez lire son histoire et plus profondément ses principes de fonctionnement sur l’article anglais de Wikipedia, plus complet que le français. Il n’en reste pas moins efficace, et il n’est pas utilisé par hasard dans la distribution Fedora Linux, chapeautée par Red Hat.

Parmi les autres modules de sécurités du noyau, on peut citer AppArmor et Tomoyo. D’autres modules qui ne sont pas inclus existent aussi, comme grsecurity.

Intrusion Detection System (IDS)

Les Systèmes de détection d’intrusion sont destinés à analyser le comportement sur un réseau ou une machine. À la manière des antivirus ils vont repérer les comportements à l’aide de signatures et alerter l’administrateur sur ce qui se passe. Parmi ceux-ci, l’un des plus connus est Snort.

On remarquera sur la page wikipedia qu’rkhunter, présenté dans la troisième partie, est considéré comme un détecteur d’intrusion d’hôte.

Intrusion Prevention System (IPS)

Les IPS sont similaires aux IDS, mais ils permettent directement d’intervenir lorsqu’une attaque survient. J’ai cité Snort en tant qu’IDS, mais il permet aussi de définir des actions à effectuer en cas de détection. On retrouve alors un fonctionnement proche des antivirus, même si les signatures et les moteurs de détection sont différents.

Pare-feux matériels

Là, on quitte le serveur lui-même, et une fois encore, je n’ai jamais approché ce type d’appareils dédiés, qu’on appelle souvent appliances (cherchez une trado française qui convient). Contrairement à iptables, qui est installé sur la machine en question, il permet généralement de protéger plusieurs appareils d’un seul coup. Ils sont souvent vendus par les grands fournisseurs de matériel réseaux d’infrastructure, comme Cisco et Juniper pour ne citer que les deux plus gros (Nokia en Europe en propose aussi je crois).

Certains se montent néanmoins des machines à bas coût et utilisent des solutions à base de pfSense qui peuvent faire l’affaire suivant la taille de l’infrastructure. Xhark en parle sur le Blogmotion par exemple, même s’il n’est pas seul.

La veille

On arrête la technique pure pour se concentrer sur l’information. En effet, il est inutile de se dire qu’on va gérer la sécurité si on en suit pas l’actualité. Avec un nombre effarant de virus créés chaque jour, de failles de sécurité découvertes, il faut se tenir au courant des évolutions pour être le plus réactif possible face aux nouvelles menaces.

Personnellement, mangeant du Debian dès le petit déjeuner, je mange du flux RSS des Debian Security Advisories. Ils alertent des failles détectées et corrigées dans la distribution, et c’est donc généralement à ce moment que je m’attarde à mettre à jour mes instances. Sans avoir trop regardé, je pense qu’il est possible que de tels informations existent pour d’autres distributions. Le cas de Manjaro et Arch est différent : comme les paquets sont mis à jour en permanence, on est assuré de la correction très rapidement, et donc aucune alerte n’est émise.

Plus largement, l’Agence Nationale de la Sécurité des Systèmes d’Information se charge de proposer ses propres alertes CERT (Computer Emergency Response Team) sur les failles de sécurités détectées dans les logiciels. Mais il n’est pas le seul, et il sera alors probablement nécessaire de vous rapprocher d’autres sources (celle du Gouvernement Américain par exemple), et parfois directement auprès de l’éditeur d’une solution utilisée sur le serveur (pourquoi pas par le biais de mailing-lists). Bref, le maître mot, c’est multiplicité des sources.

Il sera alors à votre charge de vous assurer des corrections si vous êtes concernés. Difficile d’être plus précis, le contexte de mise à jour étant très différent en fonction de votre installation (mise à jour du paquet depuis les dépôts, téléchargement/installation d’un correctif, par exemple sous Windows).

Et tout ce que je ne connais pas

Je n’ai pas la science infuse, et il est certain que j’ai oublié un tas de choses, voire, comme certains commentaires peuvent le montrer, que parfois, une des solutions que j’ai présenté dans cette série possèdent leurs propres points faibles. Une chose est certaine : il n’y a pas de sécurité absolue, à moins de ne pas être relié au réseau, ce qui de nos jours, rend un ordinateur particulièrement inutile pour 99% des cas. Tout ce qu’on peut faire, c’est soit être assez réactif pour ne pas être touché, soit faire en sorte que ça coûte trop cher de nous attaquer.

L’étape ultime : devenez attaquant, il est évident que pour savoir comment bien protéger un système, il faut être capable d’en connaître les faiblesses, à l’instar des coffre-forts, les plus habiles à les cerner sont ceux qui les ouvrent sans les clés 😉

3
Poster un Commentaire

avatar
2 Comment threads
1 Thread replies
1 Followers
 
Most reacted comment
Hottest comment thread
3 Comment authors
Seboss666yacineLa Mangouste Recent comment authors
  Subscribe  
plus récents plus anciens
Me notifier des
La Mangouste
Invité
La Mangouste

Merci pour l’article, toujours intéressant. Ça fait du bien de lire que la sécurité d’un serveur ne tient pas que de celui-ci, mais aussi de ce qui l’entoure. Ce que tu proposes ici commence à dépasser le cadre du simple serveur particulier (ce n’est absolument pas un reproche). SELinux par exemple, est plutôt indigeste d’utilisation. C’est très performant mais plus taillé pour un serveur d’entreprise, peu amené à évoluer. Côté pare-feu, tu peux regarder aussi les Arkoon-Netasq, français (cocorico). Certains modèles font même IPS. De toute façon, pare-feu et IDS sont amenés à se rapprocher de plus en plus. La… Read more »

yacine
Invité

Article trés intéréssant , serait il possible de publier ton article sur mon Blog ???