Guide de sécurisation

Guide de sécurisation d’une architecture Linux

Introduction

Ces dernières années, les entreprises ont du suivre le phénomène Internet. Elles ont concédé de gros efforts financiers pour mettre en place leurs architectures ouvertes sur l’internet. La sécurité a d’abord été sacrifiée. Aujourd’hui, le nombre d’entreprises piratées est très important, et encore beaucoup ne savent pas qu’elles le sont ! L’explosion du marché de la sécurité en 2001 témoigne d’une réelle prise de conscience des dangers liés au réseau.

Ce guide propose une organisation de la sécurité qui suit le chemin de données informatiques dans le sens réseau, système et application. Les couches sont théoriquement indépendantes d’un système d’exploitation. En pratique, il en est tout autrement, surtout pour les couches système et application. Linux dispose alors d’atouts intéressants : son esprit de gratuité et de sources libres permettent un développement rapide de solutions de sécurité à bas coût. Par ailleurs, la solidité de ces serveurs (web, mail, DNS,…) n’est plus à prouver.

Chaque couche (et sous couche) est un point d’arrêt pour un agresseur. Il est courant de dire que la sécurité est celle du plus faible maillon de la chaîne. Ceci est vrai pour certaines couches. Si, par exemple, les patchs de sécurité ne sont pas appliqués à une application, les autres couches ne serviront qu’à détecter une compromission du système.

Sécuriser une architecture sans politique définie au préalable est une erreur. Les couches proposées sont techniques. Seulement, la sécurité est avant tout une affaire d’hommes et la technique ne vient qu’après.

Par ailleurs une politique de sécurité permet :

• une prise de conscience au niveau managerial des dangers informatiques
• une prise de conscience au niveau du personnel des dangers informatiques
• une maîtrise et une optimisation des coûts de sécurité
• une maintenance aisée de la sécurité
• un réactivité efficace en cas d’attaque(s)
• une traçabilité exploitable en cas d’incident

Sécuriser une architecture ne revient pas à suivre une fois les recommandations d’un guide de sécurisation. Des failles sont trouvées tous les jours, il est donc important de se tenir au courant de l’actualité et de mettre à jour son architecture en conséquence.

• Politique
  • Analyses (Risk assessment)
  • Utilisateurs
  • Fonctionnement
  • Architecture
• Couche réseau
  • NIDS – Détection d’intrusions réseau
  • Firewall
  • Proxy (*)
  • Audit Réseau
• Couche système
  • HIDS – Détection d’intrusions (*)
  • Audit système
  • Protection du noyau (*)
  • Contrôle d’intégrité
  • Logs (sept)
• Couche applications
  • Web
  • Mail
  • Autres (DNS, SSH)
  • (*) NFS, NIS

Les (*) indiquent des couches qui n’ont pas été étudiées.

Politique de sécurité

Une politique de sécurité est un ensemble écrit de règles auxquelles ceux qui ont accès à des valeurs liées aux technologies de l’information doivent se plier. Son objet principal est d’informer les utilisateurs et les dirigeants des règles indispensables à la protection des valeurs de l’entreprise . C’est aussi le document de référence pour acquérir, configurer et auditer les systèmes d’informations d’une entreprise.

Au moment de définir une politique de sécurité, il faut avoir en tête un certain nombre de principes de sécurité :

• le coût de protection doit être inférieur au coût de récupération
• interdire tout ce qui n’est pas spécifiquement autorisé
• une politique de sécurité doit être applicable
• des mots clés de la sécurité : disponibilité, intégrité, confidentialité et authentification
  • la disponibilité
  • l’intégrité
  • la confidentialité
  • l’authentification
• la sécurité est une affaire de responsabilités. Elles doivent être clairement définies
• une des clé de la sécurité est la prise de conscience de risques, d’où l’importance de la communication
• la plupart des attaques viennent de l’intérieur
• la confiance est une grande faille de sécurité
• la sécurité n’est qu’aussi forte que le plus faible maillon de la chaîne

Quelques analyses préalables (risk assessment)

• Analyse des buts poursuivis
  • services offerts versus la sécurité
  • facilité d’utilisation versus la sécurité
  • risques de pertes versus coûts de la sécurité

• Identification des ressources et des risques associés
  • Hardware
  • Software
  • Données
  • Personnel
  • Documentation
  • Fournitures
  • Réputation

• Analyse des menaces
  • Accès non autorisé aux ressources et/ou à l’information
  • Divulgation non intentionnée ou non autorisée d’information
  • Attaque de déni de service

A chaque menace doivent être associées les ressources concernées ainsi que les pertes potentielles.

Politiques

La viabilité d’une politique de sécurité dépend de son aptitude à être appliquée et de sa flexibilité. Ainsi, elle doit être indépendante de configurations spécifiques tant sur le plan logiciel que matériel. Les modalités de mise à jour de la politique doivent être précisées.

Avant de préciser les politiques utilisateurs, de fonctionnement et d’architecture, il est primordial de définir les services offerts en interne comme à l’extérieur ainsi que les services extérieurs autorisés. Les flux d’information doivent être maîtrisés.

Politique utilisateurs

• protection des données (confidentialité et intégrité)
• accès
• authentification

Politique de fonctionnement

Il est important de bien définir les règles fixées et les responsabilités associées. Les coûts de cette politique doivent clairement ressortir.

• disponibilité
• maintenance et sous-traitance
• sauvegardes
• surveillance du système (logs)
• traçabilité
• audit
• rapports et gestion d’incidents

Politique d’architecture

Cette partie est plus technique. Il est donc important qu’elle soit expliquée clairement et que les coûts associés soit définis avec précision. Chaque partie doit être confrontée aux analyses menées au préalable ainsi qu’aux buts définis.

• Protection des services
  • séparation des services
  • confidentialité
  • intégrité
  • disponibilité

• Protection réseau
  • détection d’intrusions (réseau)
  • firewall
  • audit réseau

• Protection des systèmes
  • détection d’intrusions (hôte)
  • audit système
  • protection du noyau
  • contrôle d’intégrité
  • logs

Sécurité Réseau

L’importance de la sécurité réseau provient de deux éléments essentiels :

• le réseau est le premier point de passage des données
• il est moins fastidieux de sécuriser un réseau qu’un grand nombre de systèmes

Détection d’intrusions réseau

Au contact de l’extérieur et en amont du Firewall, il est bon d’installer un IDS (Intrusion Detecting System). Un système de détection d’intrusion écoute et surveille le trafic réseau. En cas d’anomalies, il doit s’appuyer sur un système d’alertes pour prévenir les administrateurs.

L’intérêt

Les systèmes de détections d’intrusions reposent sur la technique de recherche d’attaques connues appelées signatures. Surveillant le réseau, ils sont très efficaces sur trois points particuliers :

• la détection de balayage de réseau, ce qui permet de repérer l’ennemi avant qu’il ait agi.
• la détection de DoS (attaque par déni de service), ce qui permet de mettre en place des mesures appropriées.
• la détection d’un hôte compromis

Ils repèrent aussi un grand nombre de comportements anormaux, au niveau des couches IP mais aussi au niveau du « payload » (contenu d’un paquet). Ils permettent ainsi de déterminer la menace potentielle qui pèse sur le réseau.

Les critères techniques

Les facteurs naturels à considérer dans le choix d’un IDS sont :

• la réactivité en temps réel
• la capacité à tout détecter sans fausses alarmes
• les coûts (matériels, administration…)
• la performance (débit supporté, taille de logs)
• la facilité d’administration (système d’exploitation connu, …

L’administration

Il est évident qu’il faut au minimum connaître les protocoles IP, TCP, UDP et ICMP pour mettre en place et administrer efficacement un IDS.

Par ailleurs, l’administration de l’IDS doit être la plus simple possible. Ainsi l’IDS doit :

• pouvoir être administré à distance
• pouvoir réagir rapidement à des attaques
• fournir des données lisibles et exploitables

La réaction à des attaques peut être :

• fermer des connexions
• changer des règles du firewall
• affiner les règles d'IDS ou de supervision

Il est cependant important de garder en mémoire que les adresses IP des attaquant sont très souvent des adresses usurpées. Cela veut dire que les bloquer peut être dangereux. Il faut notamment faire attention à tout changement de règles du firewall et au moins à ne pas bloquer ses propres adresses.

Les données doivent être exploitables. On peut recourir à une base de données, qui fera les liens entre tous les IDS ou autres systèmes de détection (logs). Les bases de données, qui doivent au moins contenir les champs date, heure, IP et ports sources, IP et ports destinations, protocole, permettent aux analystes de comparer ce qu’ils voient avec un historique. Cependant, elles ne permettent pas un degré élevé d’interactivité.

La mise en place

Une politique de détection

La mise en place d’un IDS fait partie d’une stratégie globale de sécurité. De la même manière, il faut définir une stratégie propre à l’IDS:

• définir les menaces (internes – externes)
• définir les flux de données
• définir le trafic attendu pour chaque flux

L’emplacement

Il existe principalement deux choix pour placer l’IDS :

• en amont du firewall
• en aval du firewall

Mettre l’IDS en amont du firewall est un avantage dans la mesure où il peut voir toutes les attaques venant de l’extérieur. De nombreuses attaques ne peuvent être détectées qu ‘à partir de la correspondance avec une signature chaîne.

Mettre un IDS en aval du firewall permet toutefois de saisir les failles de ce dernier. Cela permet aussi de diminuer (légèrement) le nombre de données à traiter et surtout le nombre d’alertes.

Le mieux est d’avoir deux IDS, un de chaque côté. Il faut, au minimum, en avoir un du côté amont.

Configuration réseau

Un détecteur doit être fourni avec deux cartes réseau (NIC – Network Interface Card) :

• une carte en mode promiscuité (qui permet de lire tous les paquets qui arrivent sur la carte mais qui ne lui sont pas destinés), mais sans adresse IP, ce qui complique la tâche de l’attaquant pour trouver le détecteur
• une seconde carte, avec une adresse IP, utilisée pour communiquer avec le détecteur

Firewall

Le firewall est l’élément le plus connu d’une défense par couches. Cependant, s’il est indispensable, il n’est véritablement efficace qu’en association avec d’autres couches - Détection d’intrusions, Audit Réseau et Logs tout particulièrement.

Qu’est-ce qu’un firewall ?

Le terme « firewall », que l’on traduit par par-feu ou garde-barrière en français, indique une structure protégeant un réseau du trafic provenant de l’extérieur. On distingue deux types de firewall :

• filtre de paquets
• proxy

Un filtre de paquets surveille les en-têtes de protocoles transports (TCP, UDP) et réseaux (IP,ICMP). En fonctions de ses règles de configuration, il autorise ou non un paquet à passer. La technologie a évolué avec la notion de « stateful inspection » : ces firewall garde en mémoire les connexions en cours ce qui a pour conséquence d’affiner le filtrage.

Un proxy est un point de passage pour les connexions associées à un protocole d’application particulier ( HTTP, FTP, telnet…). Il initie lui même les connexions vers l’extérieur (pour l’intranet) ou vers les serveurs internes (pour les connexions de l’extérieur). Ainsi, il cache à l’extérieur les adresses des serveurs et des clients intranet . Dans le même temps le contenu des paquets est filtré.

Le NAT (Network Address Translation) peut être implémenté par les firewall filtre. La fonctionnalité peut remplacer les adresses sources des connexions sortantes par la sienne. Elle permet aussi au firewall d’être l’unique adresse visible de l’extérieur. Le NAT redirige les connexions de l’extérieur vers le serveur compétent.

La mise en place

Une politique de filtrage

La mise en place d’un firewall commence par la définition d’une politique de filtrage :

• définition des zones/flux
• définition des services associés
• définition des risques par flux/services
• définition des menaces par flux/services

Une politique rigoureuse de firewall doit être marquée par la maxime : «  tout ce qui n’est pas autorisé est interdit ».

Une politique peut s’exprimer par un tableau. L’exemple suivant s’appuie sur trois zones :

• l’extérieur qui correspond à l’internet
• la DMZ (demilitarized zone) qui contient un serveur web
• l’intranet qui correspond à un réseau local d’utilisateurs

Le tableau indique le sens des flux, les port des destination (colonne Port) et les ports sources (UP pour les ports non privilégiés : 1024 - 65535 ).

Service	Protocole	Port	EXT->LAN	EXT->DMZ	LAN->EXT	LAN->DMZ	DMZ->EXT	DMZ->LAN
DNS	tcp	53	-	-	-	-	-	-
DNS	udp	53	-	-	UP	UP	UP	-
IDENT	tcp	113	-	-	UP	-	UP	-
NNTP	tcp	119	-	-	UP	-	-	-
telnet	tcp	23	-	-	UP	-	-	-
SSH	tcp	22	-	UP	UP	UP	UP	-
FTP	tcp	21	-	-	UP	-	-	-
HTTP	tcp	80	-	UP	UP	UP	UP	-
HTTPS	tcp	443	-	-	UP	-	-	-
traceroute	udp	33434:33523	-	-	-	-	-	-

Le placement

Un firewall qui protège un réseau est appelé firewall bastion. Il existe deux types d’architectures réseau basées sur un ou plusieurs firewall.

Architecture à trois pattes

L’architecture à trois pattes définie trois zones à partir d’un seul firewall :

• la zone internet
• le zone réseau local
• la zone DMZ

Ces trois zones correspondent à trois cartes réseaux différentes de la machine firewall. Il est important de les séparer car les trafics associés sont très différents.

Architecture à deux firewall

Cette architecture sépare chaque zone par un firewall. Ainsi, chaque firewall dispose de deux cartes réseau. Le firewall le plus important est le premier car il protège l’architecture des accès extérieurs. On l’appelle firewall bastion. Le deuxième, appelé « choke », protège le réseau interne de la DMZ.

Il faut choisir une architecture, et c’est une question de goût. L’architecture à trois pattes est tout de même plus simple car elle ne nécessite qu’un seul firewall à configurer et à surveiller.

Audit et debuggage

Après la mise en place d’une architecture et l’écriture des règles du firewall correspondant à la politique de filtrage définie, il faut les auditer. L’audit de firewall se fait à l’aide d’un outil de scan tel nmap d’un côté et d’un sniffer de l’autre tels snort ou tcpdump. Il faut scanner chaque branchement du firewall, en particulier :

• internet -> réseau local
• internet -> DMZ
• réseau local -> DMZ
• DMZ -> réseau local

Pour les deux derniers scans, il peut être judicieux de remplacer une machine de production par un ordinateur portable d’audit . Cela simule une compromission. Chaque scan peut être long dans la mesure où le firewall peut laisser des scans sans réponse.

L’analyse des logs permet de terminer l’audit des règles : le firewall a t’il détecté les attaques, a t’il lancé les alertes attendues ?

Audit Réseau

Le principe de sécurisation réseau est très simple. Le danger vient des applications « communicantes », c’est dire qui ouvre un port à l’extérieur. Il faut donc :

• limiter aux maximum le nombre d’applications communicantes
• s’assurer que les derniers patchs de sécurité sont appliqués
• les configurer correctement

Les outils d’audit réseau scannent les systèmes d’un réseau à la recherche des vulnérabilités des services offerts qui peuvent être de plusieurs types :

• DoS (Attaques par déni de service)
• Vulnérabilités CGI (Script internet ouvrant un accès au système)
• Débordement de pile (Mauvaise programmation mémoire)
• Problèmes de mots de passe
• Règles trop souples de firewall
• Fuite d’information (n° de version, coordonnées administrateur,…)

Les critères techniques

Les critères naturels à considérer dans le choix d’outils de détection d’intrusions sont :

• la facilité d’installation et de configuration
• la performance (trouver toutes les failles !)
• la mise à jour rapide des failles détectées
• la rapidité
• les rapports fournis
• le coût

En réalité, aucun outil d’audit réseau n’est parfait. Il est bon d’en utiliser plusieurs pour augmenter le nombre de failles découvertes. De plus, ce n’est pas parce que l’audit est bon que le réseau est complètement sécurisé. Il peut rester des failles indétectées.

Standardisation des vulnérabilités

Il est à noter que, dans l‘évolution de ses outils, il existe une tentative de standardisation des vulnérabilités nommée CVE (Common Vulnerabilities and Exposures).

La liste CVE se veut être un dictionnaire et non une base de données de vulnérabilités. Les éléments de la liste contiennent un nom, une description rapide de la vulnérabilité ainsi que des références pertinentes. La liste CVE est récupérable sur le site cve.mitre.org.

Sécurisation système

Les couches réseaux protègent essentiellement de l’extérieur. Seulement, selon les sources, entre 50% et 90% des attaques proviennent de l’intérieur. La sécurisation des couches systèmes en est d’autant plus importante.

Audit système

Avant de mettre un système sur le réseau, il faut s’assurer qu’il est correctement configuré. Linux s’appuie sur une architecture en système de fichiers et sécuriser un système revient à :

• vérifier la configuration
• vérifier les permissions
• vérifier les propriétaires

d’un grand nombre de fichiers.

Ces fichiers peuvent être de différentes natures :

• fichiers de configuration de services
• fichiers de mots de passe
• fichiers binaires
• autres fichiers.

Méthode de sécurisation

Une méthode de sécurisation revient à ordonner l’audit de fichiers de façon à ce qu’il soit rapide et rigoureux. Voici une catégorisation possible des fichiers à auditer :

• Services
• Permissions des utilisateurs
• Mots de passe
• Noyau

Services

Tout service inutile doit être désactivé.

Aujourd’hui, l’ensemble inetd et TCPwrappers est remplacé par xinetd. Il faut cependant s’assurer de disposer d’une version récente de xinetd dans la mesure où des faille ont été trouvées.

Tous les services ne demandent pas une connexion au préalable par xinet. C’est le cas notamment de SSH, Apache, BIND, Sendmail, Postfix, mysql. Les services passant par xinet sont FTP (à éviter !), pop et imap.

Les services en « r » (rlogin ,rsh,rcp) ne doivent plus être utilisés. Tout comme les serveurs FTP, ils doivent être remplacés par SSH qui crypte les communications.

Des clients FTP Windows pour SSH existent et sont améliorés tous les jours.

Les services RPC sont dangereux. Le plus connus d’entre eux est NFS (network file system) qui permet l’utilisation d’un serveurs de fichiers.

es fichiers de configurations des différents services se trouvent dans /etc. Les fichiers de configuration par utilisateurs $HOME/.* sont aussi à surveiller et vérifier.

Permissions des utilisateurs et des fichiers

La validité et les configuration des comptes utilisateurs doivent être vérifiés. La validité d’un compte est définie dans le fichier /etc/passwd. La configuration de compte par défaut se trouve dans /etc/profile et les configurations personnalisées se trouvent dans le répertoire de chaque utilisateur. Le compte root est à protéger particulièrement. Ainsi la commande sudo et le compte wheel doivent être correctement configurés. Il faut vérifier que tous les binaires lancés un jour ou l’autre par l’utilisateur root lui appartiennent bien.

Il est très important de limiter l’accès des fichiers systèmes (/dev), de créer plusieurs partitions pour optimiser les droits associés.

Il est aussi possible de limiter l’utilisation des ressources du système par les utilisateurs. Les fichiers setuid ou setgid (qui conservent l’identité du propriétaire que leque soit l’utilisateur ou le groupe qui les lancent) doivent être connus. Ils sont à surveiller de près (cf contrôle d’intégrité). Les fichiers ouverts en écriture, qui n’ont pas de propriétaire ou qui sont des liens peuvent poser des problèmes de sécurité.

Mots de passe

L’utilisation de shadow est un strict minimum. Ce système permet d’interdire la lecture du fichier de mots de passe aux utilisateurs. Les mots de passe cryptés se trouvent alors dans /etc/shadow.

L’utilisation de PAM (Pluggable Autentication Module) permet d’assouplir les droits de connexions et d’améliorer la gestion des mots de passe. Un certain nombre de fichiers peuvent contenir des mots de passe en clair. Les droits de ces fichiers doivent être vérifiés régulièrement, à défaut de les supprimer.

Décrypter des mots de passe n’est pas très dure si le mot de passe est simple. Il existe des utilitaires obligeant les utilisateurs à définir des mots de passe plus difficiles à trouver.

Le noyau

Le noyau et les modules constituent le système d’exploitation. Si ces éléments sont piratés, il devient presque impossible de s’en apercevoir. L’un des seul moyen est l’utilisation d’un système de détection d’intrusions réseau qui devrait s’apercevoir d’une utilisation anormale du système. Il existe des solutions pour sécuriser le noyau (openwall et LIDS). A défaut, on peut toujours surveiller les fichiers correspondants. (cf contrôle d’intégrité).

Les outils d’audit système

Il existe quelques outils d’audit système mais aucun n’est extraordinaire. Ce sont en général un certains nombre de scripts qui vérifient la configuration et les droits de certains fichiers.

On peut définir certains critères pour choisir ces outils :

• nombre de tests
• rapidité
• nature et qualité des rapports
• coût.

En pratique, il y a peu de choix et ces outils ne sont pas vraiment suffisants pour sécuriser ou auditer un système. Par contre, ils sont très intéressants lorsqu’ils sont exécutés régulièrement par l’intermédiaire de la table de cron. Ils peuvent indiquer un changement maladroit de configuration.

Contrôle d’intégrité

L’audit système a montré que la sécurité d’un système dépendait très largement de la configuration et des permissions de fichiers. Les outils de contrôle d’intégrité créent une base de donnée des fichiers sensibles du système et comparent régulièrement le système à cette base. Certains outils permettent aussi la surveillance de processus en temps réel.

Les critères techniques

Les facteurs naturels à considérer dans le choix d’un outil de contrôle d’intégrité sont :

• la rapidité
• la taille de la base de données
• la sécurité de la base de données (cryptage)
• la nature (e-mail, logs) et la lisibilité des rapports
• le coût

La mise en place

Il faut d’abord définir le contenu de la base de donnée. En général, une liste par défaut est proposée. Il est ensuite nécessaire de l’affiner en fonction de son système.

La sécurité de la base de donnée est primordiale. Il est indispensable qu’elle soit cryptée et qu’elle ne soit pas modifiable. Pour cela, il existe plusieurs solutions mais la plus naturelle est d’utiliser un support en lecture seule. Cela peut être une disquette ou un cdrom.

Souvent, on peut configurer l’emplacement des fichiers de l’outil sur le disque. On peut aussi préciser la nature du rapport (mail à la personne responsable, utilisation d’un système de log…). L’utilisation du mail est efficace mais peut être difficile à gérer si d’autres outils de sécurité font la même chose. Il peut être préférable d’utiliser un système de gestion de logs qui envoie les rapports à un système différent qui traite les données des différents outils avant de les envoyer par mail.

Enfin, il faut définir à quelle fréquence on compare le système à la base de données. Le faire une à deux fois par jour semble raisonnable. Il suffit pour cela de rajouter une ligne à la table de cron.

Logs

Linux dispose d’un système de logs intégré appelé syslog. Très simple et très utile, il n’est pas suffisant dans la mesure où les logs ne servent à riens s’ils ne sont pas analysés. Heureusement, il existe un certain nombre d’outils qui simplifient cette tâche.

Syslog

Syslog est lancé par l’intermédiaire de son démon syslogd. Le fichier de configuration associé est /etc/syslogd.conf. Ce fichier permet de définir la destination des logs en fonctions de deux critères, la catégorie de l’application (sécurité, mail, noyau, …) et le niveau de criticité de l’alerte (urgente, …, debuggage).

Les messages d’alertes peuvent être envoyés dans des fichiers, à des utilisateurs connectés, ou à des systèmes distants.

Analyse de logs

Deux méthodes :

• Vérification régulière de logs
• Vérification temps réel de logs

Process Accounting

http://directory.fsf.org/acct.html

Activer le "process acounting" via :

#accton /var/account/pacct

• lastcomm :information sur l'exécution de commandes individuelles
• ac : information sur le temps de connexion de l'utilisateur
• sa : résumé de l'exécution de commandes

Sécurisation applications

Les applications à sécuriser sont toutes celles qui communiquent avec l’extérieur. Les dangers lié à ces applications sont de plusieurs sortes :

• délivrance d’informations sur le réseau, le service (scans de réseau)
• communication en clair (sniffers)
• indisponibilité (attaques DoS – Denial of Service)
• accès possible au serveur (débordement de tampon)

Pour assurer la sécurité de ces applications, il faut :

• correctement configurer l’application
• mettre, si possible, un système de cryptage en place
• appliquer les patchs de sécurité

Un principe de base est que le nombre de services par machine doit être limité au strict minimum. Ainsi, il vaut mieux séparer ces services. En pratique, cela veut dire qu’un serveur mail et un serveur web doivent être installés sur deux systèmes différents. On peut répartir les applications en fonction des services proposés :

• Web
• Mail
• Autres

Copyright

© 2006 Christophe de Livois

Vous avez l'autorisation de copier, distribuer et/ou modifier ce document suivant les termes de la GNU Free Documentation License, Version 1.2 ou n'importe quelle version ultérieure publiée par la Free Software Foundation; sans section invariante, sans page de garde, sans entête et sans page finale. Pour plus d'informations consulter le site de l'APRIL.