Manuel de la sécurité pour Gentoo

Table des matières :

• Votre système et la sécurité
  Sécurisez les différentes parties de votre système.
  1. Considérations avant l'installation
     Pourquoi la sécurité est-elle un aspect important auquel tout administrateur système doit être sensible ?
  2. Améliorer la sécurité
     Améliorez la sécurité pendant et après l'installation
  3. Journalisation
     Choisissez votre système de journalisation. Trois systèmes sont détaillés.
  4. Montage des partitions
     Découvrez les options de sécurité de /etc/fstab.
  5. Limitations pour les utilisateurs et les groupes
     Maîtrisez l'utilisation des ressources.
  6. Permissions de fichiers
     Sécurisez vos fichiers.
  7. PAM
     Utilisez les modules d'authentification PAM (Pluggable Authentication Modules.)
  8. Les « wrappers » TCP
     Contrôlez l'accès aux services.
  9. Sécurité du noyau
     Sécurisez le noyau.
  10. Sécurisation des services
      Sécurisez les démons qui sont en service.
  11. Les environnements chroot et les serveurs virtuels
      Isolez vos serveurs.
  12. Pare-feu
      Filtrez les paquets qui passent sur le réseau.
  13. Détection d'intrusion
      Détectez les intrus.
  14. Rester à jour
      Assurez-vous d'appliquer les correctifs de sécurité.

A. Votre système et la sécurité

1. Considérations avant l'installation

1.a. Sécurité physique

Quel que soit le nombre de protections que vous mettez en place, elles seront toutes aisément contournées par un attaquant disposant d'un accès physique à votre système. Malgré cela, certaines mesures peuvent être prises afin d'améliorer la sécurité face à un attaquant pouvant accéder physiquement à votre système. Gardez votre matériel dans un local verrouillé afin d'éviter qu'un attaquant puisse simplement le débrancher et l'emporter. Fermer à clé les boîtiers des ordinateur est également une bonne idée, et permet d'éviter que quelqu'un ne parte avec votre disque dur. Pour éviter qu'un attaquant n'amorce le système à partir d'un autre disque, ce qui lui permettrait de contourner facilement les restrictions relatives aux permissions et à l'ouverture de sessions, faites de votre disque dur le premier périphérique de démarrage dans votre BIOS, et protégez le BIOS par un mot de passe. Il est également important de définir un mot de passe de démarrage pour LILO ou GRUB, afin d'éviter qu'un utilisateur malicieux ne démarre en mode « single-user » et n'obtienne un accès complet à votre système. Ce sujet est couvert en détail dans le chapitre 3, dans les rubriques Protéger GRUB par un mot de passe et Protéger LILO par un mot de passe.

1.b. Planification des services

Établissez dès le départ une liste des services que le système devrait exécuter. Cela vous aidera à établir un schéma de partition optimal pour votre système, et permettra aussi une meilleure planification des mesures de sécurité nécessaires. Bien sûr, cette n'étape n'est pas nécessaire si le système n'a qu'un rôle simple, tel qu'un ordinateur de bureau ou un pare-feu dédié. Dans un tel cas, vous ne devriez exécuter aucun service, hormis, peut-être, sshd.

Cette liste peut aussi être utile pour l'administration du système. En conservant une liste à jour des versions des programmes utilisés, il vous sera plus facile de maintenir le tout à jour si une vulnérabilité est découverte dans un de vos démons.

1.c. Schémas de partitions

Règles de partitionnement :

• Tout répertoire dans lequel un utilisateur peut écrire (tel que /home et /tmp) devrait se trouver sur une partition séparée et utiliser les quotas de disques. Cela réduit le risque qu'un utilisateur ne remplisse entièrement votre système de fichiers. Portage utilise /var/tmp pour compiler des fichiers ; cette partition doit donc être volumineuse.
• Tout répertoire dans lequel vous souhaitez installer des logiciels qui ne sont pas spécifiques à votre distribution doit se trouver sur une partition séparée. D'après le Standard de hiérarchie des fichiers, cela concerne /opt ou /usr/local. Si ces points de montage sont sur des partitions séparées, ces dernières ne seront pas effacées si vous devez réinstaller votre système.
• Pour davantage de sécurité, les données statiques devraient être conservées sur une partition séparée montée en lecture seulement. Si vous êtes vraiment paranoïaque, vous pouvez même envisager de stocker ce type de données sur un média non inscriptible comme un CD-ROM.

1.d. Le super-utilisateur root

Le super-utilisateur root est l'utilisateur le plus important sur un système et ne devrait être utilisé qu'en cas de nécessité absolue. Si un attaquant obtient les droits root, vous ne pourrez plus jamais considérer votre système comme sécurisé tant que vous n'aurez pas procédé à une réinstallation.

Règles d'or concernant root :

• Créez toujours un utilisateur pour l'utilisation quotidienne. Ajoutez-le au groupe « wheel » ; cela lui donnera la possibilité d'exécuter « su » pour obtenir l'accès root.
• N'utilisez jamais X ou toute autre application utilisateur en tant que root. root ne devrait être utilisé qu'en cas de nécessité absolue ; si une vulnérabilité existe dans une application exécutée avec les droits d'un utilisateur ordinaire, un attaquant peut obtenir un accès utilisateur. Mais, si cette même application est exécutée avec les droits de l'utilisateur root, l'attaquant obtiendra l'accès root.
• Utilisez toujours des chemins absolus lorsque vous utilisez le compte root. (Alternativement, vous pourriez vous assurer de toujours utiliser su -, qui remplace les variables d'environnement de l'utilisateur par celles de root, et vous assurer que la variable PATH de root ne contient que des répertoires protégés tels que /bin et /sbin.) Il est possible de tromper root en démarrant une application différente de celle qu'il pense utiliser. Si le PATH de root est protégé ou si root n'utilise que des chemins absolus, vous êtes assuré que cela ne se produira pas.
• Si un utilisateur n'a besoin que de quelques commandes au lieu de toutes celles disponibles pour root, vous devriez alors envisager l'utilisation de sudo. Faites toutefois attention à qui vous accordez ce privilège !
• Ne laissez jamais un terminal ouvert lorsque vous êtes connecté en tant que root.

Gentoo dispose d'une protection générale contre les utilisateurs normaux qui tentent d'utiliser su pour accéder au compte root. Le comportement par défaut de PAM impose à l'utilisateur d'appartenir au groupe « wheel » pour utiliser su.

1.e. Politique de sécurité

Plusieurs raisons justifient l'écriture d'une politique de sécurité pour vos système et votre réseau.

• Une bonne politique de sécurité vous permet de définir la sécurité en tant que « système », plutôt que comme un ensemble de fonctionnalités pêle-mêle. Par exemple, sans politique de sécurité, un administrateur pourrait décider de désactiver telnet sous prétexte qu'il transmet des mots de passe non cryptés, mais pourrait aussi laisser actif l'accès FTP, alors que ce dernier souffre de la même faiblesse. Une bonne politique de sécurité vous permet d'identifier les mesures qui valent la peine d'être implémentées et celles qui n'en valent pas la peine.
• Afin de diagnostiquer des problèmes, réaliser des audits ou traquer des intrus, il peut être nécessaire d'intercepter le trafic réseau, d'inspecter les ouvertures de sessions et l'historique des commandes des utilisateurs, ainsi que de consulter le contenu des répertoires personnels. Si cela n'est pas clarifié par écrit et si vos utilisateurs n'en sont pas conscients, de telles actions peuvent être illégales et vous causer des problèmes légaux.
• Le détournement de comptes utilisateurs est une des menaces les plus communes à la sécurité d'un système. Si vous n'expliquez pas aux utilisateurs pourquoi la sécurité est importante et quelles sont les bonnes pratiques en matière de sécurité (comme ne pas noter les mots de passe sur des bouts de papier traînant sur les bureaux), il y a peu de chances que vos comptes utilisateurs soient bien protégés.
• Des schémas détaillés de votre système et de votre réseau vous aideront et aideront aussi les inspecteurs des forces policières si besoin est, à retracer les intrusions et à identifier les faiblesses après coup. Un message d'accueil relatif à la politique de sécurité, tel qu'un rappel que le système fait partie d'un réseau privé dont l'utilisation non-autorisée est prohibée, aidera à vous assurer que vous pouvez poursuivre en justice les intrus que vous aurez attrapés.

À la lumière de ce qui précède, la nécessité d'une bonne politique de sécurité devrait être évidente.

La politique en tant que telle est un document, ou un ensemble de documents, décrivant le réseau et les fonctionnalités du système (tel que l'ensemble des services offerts), les utilisations acceptables et celles qui ne le sont pas, les « bonnes pratiques » de sécurité, etc. Tous les utilisateurs devraient être informés de l'existence de la politique, ainsi que de tout changement que vous y apportez pour la mettre à jour. Il est important de prendre le temps d'aider les utilisateurs à comprendre la politique et de leur expliquer pourquoi ils doivent signer cette dernière et quelles sont les conséquences s'ils violent la politique (la politique devrait inclure des informations à ce sujet). Cette pratique devrait être répétée une fois par an, puisque la politique peut changer (mais aussi pour faire un rappel à l'utilisateur).

Une politique de sécurité doit contenir au moins les points suivants :

• Utilisation correcte
  • Économiseurs d'écran
  • Gestion des mots de passe
  • Téléchargement et installation de logiciels
  • Informer les utilisateurs s'ils sont surveillés
  • Utilisation de programmes anti-virus
• Gestion des informations sensibles (sous n'importe quelle forme écrite ou numérique)
  • Rangement du bureau et mise sous clé des informations sensibles
  • Extinction du PC avant de partir
  • Utilisation du cryptage
  • Gestion des clés avec les collègues de confiance
  • Manipulation du matériel sensible en cas de voyage
• Manipulation de l'équipement informatique pendant un voyage
  • Manipulation des portables pendant les voyages et durant les séjours en hôtel

Des utilisateurs différents auront peut-être besoin de niveaux ou de types d'accès variés. Votre politique peut varier afin d'accommoder tous les utilisateurs.

Une politique de sécurité peut devenir très volumineuse et des informations vitales peuvent être facilement oubliées. La politique pour les informaticiens devrait contenir des informations non disponibles pour les autres utilisateurs  ; il est donc intelligent de la découper en chartes plus petites, c'est-à-dire Charte de bon usage, Politique de mots de passe, Politique de courrier électronique et Politique d'accès distant.

Des exemples de politiques se trouvent sur le site du projet de sécurité SANS. Si vous avez un petit réseau et si vous pensez que ces procédures sont trop lourdes, vous devriez consulter le Site Security Handbook.

2. Améliorer la sécurité

2.a. Options USE

Le fichier make.conf contient les options de la variable USE définies par l'utilisateur et /etc/make.profile/make.defaults contient les options USE utilisées par défaut dans Gentoo Linux. Dans ce guide, nous allons nous intéresser aux options pam (Pluggable Authentication Modules), tcpd (couche TCP) et ssl (Secure Socket Layer). Elles sont toutes dans les options USE par défaut.

2.b. Protéger GRUB par un mot de passe

GRUB permet d'ajouter une sécurisation par mot de passe à votre chargeur de démarrage de deux manières différentes. La première utilise un mot de passe en clair et la seconde fait appel à un cryptage md5+salt.

timeout 5
password changez_moi

Cela ajoutera le mot de passe changez_moi. Si aucun mot de passe n'est entré lors du démarrage, les paramètres de démarrage par défaut seront utilisés.

Lorsque vous ajoutez un mot de passe md5, vous devez le convertir en format crypt, qui est le même format que celui utilisé dans le fichier /etc/shadow. Pour plus d'information, lisez man crypt. Le mot de passe crypté changez_moi peut, par exemple, ressembler à : $1$T7/dgdIJ$dJM.n2wZ8RG.oEiIOwJUs.

Vous pouvez convertir votre mot de passe directement dans le shell de GRUB :

#/sbin/grub

    GRUB  version 0.92  (640K lower / 3072K upper memory)

   [ Minimal BASH-like line editing is supported.  For the first word, TAB lists
     possible command completions.  Anywhere else TAB lists the possible
     completions of a device/filename. ]

grub> md5crypt

Password: ***********
(Tapez changez_moi à l'invite de commande)
Encrypted: $1$T7/dgdIJ$dJM.n2wZ8RG.oEiIOwJUs.

grub> quit

Ensuite, copiez/collez votre mot de passe dans /boot/grub/grub.conf.

timeout 5
password --md5 $1$T7/dgdIJ$dJM.n2wZ8RG.oEiIOwJUs.

Le temps limite de 5 secondes devient très pratique si votre système est controlé à distance et doit pouvoir redémarrer sans utiliser le clavier. Vous pouvez obtenir plus d'informations sur GRUB et les mots de passe en exécutant info grub.

2.c. Protéger LILO par un mot de passe

LILO supporte deux méthodes pour manipuler les mots de passe : globale et par image. Les deux contiennent des mots de passe en clair.

Le mot de passe global se place en haut du fichier de configuration et s'applique à toutes les images de démarrage :

password=changez_moi
restricted
delay=3

Le mot de passe par image est défini comme suit :

image=/boot/bzImage
      read-only
      password=changez_moi
      restricted

Si l'option restricted n'est pas spécifiée, l'ordinateur vous demandera un mot de passe à chaque fois.

Vous devez exécuter /sbin/lilo pour enregistrer les informations que vous avez entrées dans votre fichier lilo.conf.

2.d. Restrictions concernant l'utilisation de la console

Le fichier /etc/securetty vous permet de spécifier quels sont les périphériques tty (terminaux) utilisables par root pour se connecter.

Nous vous conseillons de commenter toutes les lignes à part vc/1 si vous utilisez devfs ou toutes les lignes sauf tty1 si vous utilisez udev. Cela vous permettra d'être sûr que root n'a le droit de se connecter qu'une seule fois et sur un seul terminal.

(Avec devfs)
vc/1

(Avec udev)
tty1

3. Journalisation

3.a. Introduction

Vous devriez augmenter le niveau de journalisation des événements pour obtenir plus d'avertissements ou de messages d'erreurs pouvant indiquer une attaque en cours ou ayant déjà porté ses fruits. Les attaquants scannent ou sondent généralement avant de commencer une attaque.

Il est également vital que les fichiers des journaux soient lisibles et facilement exploitables. Gentoo Linux vous permet de choisir entre 3 types de systèmes de journalisation au moment de l'installation.

3.b. Syslogd

Syslogd est le système de journalisation le plus répandu sous Linux et UNIX en général. Il inclut un système de rotation de base pour les journaux, mais utiliser /usr/sbin/logrotate dans des tâches de cron est souvent recommandé, car il est plus puissant. Logrotate est configuré dans /etc/logrotate.conf. La fréquence de rotation des journaux que vous devriez paramétrer dépend de la charge de votre système.

Ci-dessous, vous trouverez le syslog.conf standard avec quelques fonctionnalités supplémentaires. Nous avons décommenté les lignes cron et tty et ajouté un serveur de journalisation distant. Pour encore plus de sécurité, vous pouvez ajouter les journaux dans deux emplacements.

#  /etc/syslog.conf     Fichier de configuration pour syslogd.
#
#                       Pour plus d'informations, voir la page man syslog.conf(5).
#                       Cela provient de Debian, nous l'utilisons actuellement.
#                       Daniel Robbins, 5/15/99

#
# Tout d'abord quelques fichiers de journaux standards. Journal par fonction.
#

auth,authpriv.*                 /var/log/auth.log
*.*;auth,authpriv.none          -/var/log/syslog
cron.*                         /var/log/cron.log
daemon.*                        -/var/log/daemon.log
kern.*                          -/var/log/kern.log
lpr.*                           -/var/log/lpr.log
mail.*                          /var/log/mail.log
user.*                          -/var/log/user.log
uucp.*                          -/var/log/uucp.log
local6.debug                    /var/log/imapd.log

#
# Journaux pour le système de courrier. Séparez-le afin
# qu'il soit facile d'écrire des scripts pour analyser ces fichiers.
#
mail.info                       -/var/log/mail.info
mail.warn                       -/var/log/mail.warn
mail.err                        /var/log/mail.err

# Journaux pour le système de « news » INN.
#
news.crit                       /var/log/news/news.crit
news.err                        /var/log/news/news.err
news.notice                     -/var/log/news/news.notice

#
# Quelques fichiers de journaux « attrape-tout ».
#
*.=debug;\
        auth,authpriv.none;\
        news.none;mail.none     -/var/log/debug
*.=info;*.=notice;*.=warn;\
        auth,authpriv.none;\
        cron,daemon.none;\
        mail,news.none          -/var/log/messages

#
# Les urgences et alertes sont envoyées à toutes les personnes connectées.
#
*.emerg                         *
*.=alert                        *

#
# J'aime avoir des messages affichés sur la console, mais seulement
# sur une console virtuelle que je n'utilise pas.
#
daemon,mail.*;\
       news.=crit;news.=err;news.=notice;\
       *.=debug;*.=info;\
       *.=notice;*.=warn       /dev/tty8

# Installation d'un serveur de journaux distant.
*.*                        @logserver

# Le tube nommé /dev/xconsole est pour l'utilitaire `xconsole'.  Pour l'utiliser,
# vous devez invoquer `xconsole' avec l'option `-file' :
#
#    $ xconsole -file /dev/xconsole [...]
#
# NOTE : ajustez la liste ci-dessous ou vous allez devenir fou si vous avez
#        un site plutôt actif...
#
#daemon.*,mail.*;\
#       news.crit;news.err;news.notice;\
#       *.=debug;*.=info;\
#       *.=notice;*.=warn       |/dev/xconsole

local2.*                --/var/log/ppp.log

L'attaquant essaiera généralement d'effacer ses traces en éditant ou en effaçant les fichiers de journaux. Vous pouvez rendre sa tâche plus complexe en envoyant les journaux sur un ou plusieurs serveurs de journalisation situés sur des machines distantes. Vous trouverez plus d'informations sur syslogd en consultant sa page man (man syslog).

3.c. Metalog

Metalog, écrit par Frank Dennis, n'est pour sa part pas capable de journaliser sur des serveurs à distance, mais il a bien d'autres avantages concernant les performances et la flexibilité de journalisation. Il peut journaliser par nom de programme, importance ou fonction (comme syslogd) et permet aussi l'analyse des journaux avec des expressions rationnelles permettant de déclencher l'exécution de commandes. Cela s'avère très pratique dans les situations qui demandent une réaction.

La configuration de base est généralement suffisante. Si vous voulez être averti par courrier quand une erreur de mot de passe est commise, utilisez l'un des scripts suivants.

Pour postfix :

#! /bin/sh
echo "$3" | mail -s "Attention (programme : $2)" root

Pour netqmail :

#!/bin/sh
echo "To: root
Subject:Echec (Attention: $2)
$3
" | /var/qmail/bin/qmail-inject -f root

N'oubliez pas de rendre ces scripts exécutables en faisant /bin/chmod +x /usr/local/sbin/mail_pwd_failures.sh

Ensuite, décommentez les lignes de commande sous « Password failures » dans /etc/metalog/metalog.conf comme ceci :

command  = "/usr/local/sbin/mail_pwd_failures.sh"

3.d. Syslog-ng

Syslog-ng propose les mêmes fonctionnalités que syslog et metalog avec quelques petites différences. Il peut notamment filtrer les messages en se basant sur un niveau d'exécution et un contenu (tout comme metalog), gérer des journaux distants comme syslogd, exploiter des journaux venant de syslogd (même de flux venant de Solaris), écrire sur une console TTY, exécuter des programmes et être paramétré comme serveur de journaux. Il représente actuellement le meilleur système, combinant les qualités des deux autres programmes cités ci-dessus en ajoutant des options de configuration avancées.

Voici un fichier de configuration classique légèrement modifié :

options {
        chain_hostnames(no);

        # L'action par défaut de  syslog-ng est d'écrire une ligne STATS
        # dans le fichier toutes les 10 minutes.  Après quelque temps c'est plutôt affreux.
        # Passez le à toutes les 12 heures et vous aurez une mise à jour journalière sur 
        # le nombre de messages que syslog-ng a manqué (0).
        stats_freq(43200);
};

source src {
    unix-stream("/dev/log" max-connections(256));
    internal();
};

source kernsrc { file("/proc/kmsg"); };

# Définir les destinations
destination authlog { file("/var/log/auth.log"); };
destination syslog { file("/var/log/syslog"); };
destination cron { file("/var/log/cron.log"); };
destination daemon { file("/var/log/daemon.log"); };
destination kern { file("/var/log/kern.log"); };
destination lpr { file("/var/log/lpr.log"); };
destination user { file("/var/log/user.log"); };
destination mail { file("/var/log/mail.log"); };

destination mailinfo { file("/var/log/mail.info"); };
destination mailwarn { file("/var/log/mail.warn"); };
destination mailerr { file("/var/log/mail.err"); };

destination newscrit { file("/var/log/news/news.crit"); };
destination newserr { file("/var/log/news/news.err"); };
destination newsnotice { file("/var/log/news/news.notice"); };

destination debug { file("/var/log/debug"); };
destination messages { file("/var/log/messages"); };
destination console { usertty("root"); };

# Par défaut, les messages sont écrits sur tty12...
destination console_all { file("/dev/tty12"); };

# ...si vous voulez utiliser /dev/console pour des programmes tels que xconsole
# vous pouvez mettre en commentaire la ligne destination au dessus de ces réferences /dev/tty12
# et décommenter la ligne en dessous.
#destination console_all { file("/dev/console"); };

# Créer les filtres
filter f_authpriv { facility(auth, authpriv); };
filter f_syslog { not facility(authpriv, mail); };
filter f_cron { facility(cron); };
filter f_daemon { facility(daemon); };
filter f_kern { facility(kern); };
filter f_lpr { facility(lpr); };
filter f_mail { facility(mail); };
filter f_user { facility(user); };
filter f_debug { not facility(auth, authpriv, news, mail); };
filter f_messages { level(info..warn)
        and not facility(auth, authpriv, mail, news); };
filter f_emergency { level(emerg); };

filter f_info { level(info); };
filter f_notice { level(notice); };
filter f_warn { level(warn); };
filter f_crit { level(crit); };
filter f_err { level(err); };
filter f_failed { message("failed"); };
filter f_denied { message("denied"); };

# Connecter le filter à la destination
log { source(src); filter(f_authpriv); destination(authlog); };
log { source(src); filter(f_syslog); destination(syslog); };
log { source(src); filter(f_cron); destination(cron); };
log { source(src); filter(f_daemon); destination(daemon); };
log { source(kernsrc); filter(f_kern); destination(kern); };
log { source(src); filter(f_lpr); destination(lpr); };
log { source(src); filter(f_mail); destination(mail); };
log { source(src); filter(f_user); destination(user); };
log { source(src); filter(f_mail); filter(f_info); destination(mailinfo); };
log { source(src); filter(f_mail); filter(f_warn); destination(mailwarn); };
log { source(src); filter(f_mail); filter(f_err); destination(mailerr); };

log { source(src); filter(f_debug); destination(debug); };
log { source(src); filter(f_messages); destination(messages); };
log { source(src); filter(f_emergency); destination(console); };

#Journal par défaut
log { source(src); destination(console_all); }

Syslog-ng est très simple à configurer, mais il est aussi très facile d'oublier quelque chose dans le fichier de configuration tellement il est volumineux. L'auteur nous promet d'autres améliorations comme le cryptage, l'authentification, la compression et le contrôle par adresse MAC (Mandatory Access Control). Avec ces options, il deviendra un système de journalisation réseau parfait étant donné que l'attaquant ne pourra plus espionner le journal.

Syslog-ng a un autre avantage : il n'a pas besoin d'être exécuté en tant que root !

3.e. Analyse des journaux avec Logcheck

Bien sûr, journaliser les événements n'est que la moitié de la bataille. Une application telle que Logcheck peut faciliter grandement l'analyse régulière des journaux. Logcheck est un script accompagné d'un programme binaire nommé logtail, qui est exécuté à partir du démon cron et qui compare vos journaux à un ensemble de règles pour repérer une éventuelle activité suspecte. Il envoie ensuite le résultat par courrier à l'utilisateur root.

Logcheck et logtail font partie du paquet app-admin/logsentry.

Logcheck utilise quatre fichiers pour filtrer les journaux et départager les entrées importantes de celles qui ne le sont pas. Ces fichiers sont logcheck.hacking, qui contient des messages connus relatifs au « hacking », logcheck.violations, qui contient des motifs relatifs aux violations de sécurité, logcheck.violations.ignore, qui contient des mots-clés sensibles d'être présents dans le fichier des violations, ce qui permet d'ignorer les entrées ordinaires, et logcheck.ignore, qui correspond aux entrées à ignorer.

4. Montage des partitions

4.a. Montage des partitions

Lorsque vous montez des partitions ext2, ext3 ou reiserfs, vous pouvez appliquer plusieurs options au fichier /etc/fstab. Voici leurs descriptions :

• nosuid - Ignore l'option SUID et considère chaque fichier comme un fichier ordinaire.
• noexec - Interdit l'exécution de tout fichier à partir de cette partition.
• nodev - Ne tient pas compte des « devices ».

Ces paramètres peuvent malheureusement être facilement contournés en utilisant un chemin indirect. Vous pourrez néanmoins, en activant l'option noexec pour /tmp, arrêter la plupart des « exploits » conçus pour être exécutés à partir de /tmp .

/dev/sda1 /boot ext2 noauto,noatime 1 1
/dev/sda2 none swap sw 0 0
/dev/sda3 / reiserfs notail,noatime 0 0
/dev/sda4 /tmp ext3 noatime,nodev,nosuid,noexec 0 0
/dev/sda5 /var ext3 noatime,nodev 0 0
/dev/sda6 /home ext3 noatime,nodev,nosuid 0 0
/dev/cdroms/cdrom0 /mnt/cdrom iso9660 noauto,ro 0 0
proc /proc proc defaults 0 0

5. Limitations pour les utilisateurs et les groupes

5.a. /etc/security/limits.conf

Contrôler l'utilisation des ressources peut se révéler très utile pour éviter une attaque de type déni de sevice local ou bien pour limiter le nombre total d'ouvertures de sessions pour un groupe ou un utilisateur. Toutefois, des limites trop strictes peuvent empêcher certains programmes de s'exécuter normalement.

*    soft core      0
*    hard core      0
*    hard nproc     15
*    hard rss       10000
*    -    maxlogins 2
@dev hard core      100000
@dev soft nproc     20
@dev hard nproc     35
@dev -    maxlogins 10

Si vous vous rendez compte que vous mettez nproc ou maxlogins à 0, il serait certainement plus simple de supprimer l'utilisateur. L'exemple ci-dessus paramètre le groupe dev pour le nombre de processus, les fichiers core et maxlogins. Le reste est laissé à la valeur par défaut.

5.b. /etc/limits

Le fichier /etc/limits est très similaire au fichier /etc/security/limits.conf. Les seules différences sont dans le format et dans le fait qu'il ne fonctionne qu'avec des utilisateurs ou des expressions rationnelles (et non pas avec des groupes). Regardons un exemple de configuration de plus près :

*   L2 C0 U15 R10000
kn L10 C100000 U35

Nous réglons ici les paramètres par défaut, mais également une valeur particulière pour l'utilisateur kn. Les limites font partie du paquet sys-apps/shadow. Il n'est pas nécessaire de mettre des limites dans ce fichier si vous avez activé pam dans votre /etc/make.conf.

5.c. Quotas

Placer des quotas sur un système de fichiers restreint l'utilisation du disque sur la base de l'identité de l'utilisateur et de son groupe. Les quotas sont activés dans le noyau et ajoutés par la suite à un point de montage dans /etc/fstab. L'option du noyau qui active ce paramètre se trouve dans la section File systems->Quota support. Appliquez l'option, recompilez votre noyau et redémarrez en utilisant votre nouveau noyau.

Commencez par installer les quotas avec emerge quota. Modifiez ensuite votre fichier /etc/fstab et ajoutez les paramètres usrquota et grpquota aux partitions sur lesquelles vous souhaitez restreindre l'utilisation du disque, comme le montre l'exemple ci-dessous.

/dev/sda1 /boot ext2 noauto,noatime 1 1
/dev/sda2 none swap sw 0 0
/dev/sda3 / reiserfs notail,noatime 0 0
/dev/sda4 /tmp ext3 noatime,nodev,nosuid,noexec,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv=1 0 0
/dev/sda5 /var ext3 noatime,nodev,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv1 0 0
/dev/sda6 /home ext3 noatime,nodev,nosuid,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv1 0 0
/dev/sda7 /usr reiserfs notail,noatime,nodev,ro 0 0
/dev/cdroms/cdrom0 /mnt/cdrom iso9660 noauto,ro 0 0
proc /proc proc defaults 0 0

Vous devez ensuite créer les fichiers de quotas (aquota.user et aquota.group) pour chaque partition sur lesquelles vous avez activé les quotas, puis placer ces fichiers à la racine de ces partitions.

# touch /tmp/aquota.user
# touch /tmp/aquota.group
# chmod 600 /tmp/aquota.user
# chmod 600 /tmp/aquota.group

Cette étape est nécessaire pour chaque partition où les quotas sont actifs. Après avoir ajouté et configuré les fichiers de quotas, vous devez ajouter le script quota aux scripts d'initialisation du niveau d'exécution de démarrage.

# rc-update add quota boot

Après avoir redémarré la machine, il est temps de configurer les quotas pour les utilisateurs et les groupes. La commande edquota -u kn démarrera l'éditeur défini dans $EDITOR (nano par défaut) qui vous permettra d'éditer les quotas de l'utilisateur kn. edquota -g vous permet de faire la même chose pour les groupes.

Quotas pour l'utilisateur kn :
/dev/sda4: blocks in use: 2594, limits (soft = 5000, hard = 6500)
         inodes in use: 356, limits (soft = 1000, hard = 1500)

Pour plus d'informations sur les quotas, consultez les pages man à l'aide de man edquota ou bien le mini-howto des quotas.

5.d. /etc/login.defs

Si votre politique de sécurité spécifie que les utilisateurs doivent changer leur mot de passe toutes les deux semaines, mettez la valeur de PASS_MAX_DAYS à 14 et celle de PASS_WARN_AGE à 7. Il est également conseillé d'utiliser l'ancienneté des mots de passe car les attaques par force brute peuvent trouver n'importe quel mot de passe ; ce n'est qu'une question de temps. Nous recommandons également de définir la variable LOG_OK_LOGINS à yes.

5.e. /etc/security/access.conf

Le fichier access.conf fait également partie du paquet sys-libs/pam, qui vous donne accès à une table de contrôle des ouvertures de sessions. Cette table est utilisée pour décider qui a le droit ou pas d'ouvrir une session en fonction du nom d'utilisateur, du nom de groupe ou du nom d'hôte. Par défaut, tous les utilisateurs du système ont le droit d'ouvrir une session. Le fichier n'est donc constitué que d'exemples et de commentaires. Que vous sécurisiez une station de travail ou un serveur, nous vous recommandons de configurer ce fichier de telle sorte que vous (l'administrateur) soyez le seul autorisé à accéder à la console.

-:ALL EXCEPT wheel sync:console
-:wheel:ALL EXCEPT LOCAL .gentoo.org

Cela paramétrera l'accès d'ouverture de session pour que les membres du groupe wheel puissent ouvrir une session localement ou depuis le domaine gentoo.org. Cela peut paraître paranoïaque, mais il vaut mieux être sécurisé que désolé.

6. Permissions de fichiers

6.a. Lecture pour tous

Les utilisateurs normaux ne devraient pas avoir accès aux fichiers de configuration ou de mots de passe. Un attaquant pourrait dérober les mots de passe d'une base de données ou d'un site Internet et les utiliser pour modifier, voire effacer des données. C'est pourquoi il est important que les permissions des fichiers soient correctes. Si vous êtes certain qu'un fichier n'est utilisé que par root, assignez-lui les permissions 0600 et assignez au fichier l'utilisateur approprié avec chown.

6.b. Écriture pour tous les utilisateurs et tous les groupes

# find / -type f \( -perm -2 -o -perm -20 \) \ -exec ls -lg {} \; 2>/dev/null >writable.txt
# find / -type d \( -perm -2 -o -perm -20 \) \ -exec ls -ldg {} \; 2>/dev/null >>writable.txt

Cela créera un long fichier contenant la liste des fichiers qui ont un droit d'écriture pour tout le monde ou pour le groupe. Vérifiez les permissions et éliminez les droits sur les fichiers qui sont accessibles en écriture par tout le monde en exécutant la commande /bin/chmod o-w sur ces fichiers.

6.c. Les fichiers SUID/SGID

Les fichiers dont le bit SUID ou SGID est activé sont exécutés avec les privilèges de l'utilisateur ou du groupe possédant ce fichier, et non avec ceux de l'utilisateur qui exécute le fichier. Normalement, ces bits sont utilisés sur des fichiers qui doivent fonctionner en tant que root pour accomplir leur travail. Ces fichiers peuvent mener à une exploitation locale de votre système avec les droits root s'ils contiennent des failles de sécurité. Ceci est dangereux, et les fichiers avec des bits SUID ou SGID doivent être évités à tout prix. Si vous n'utilisez pas ces fichiers, faites un chmod 0 dessus ou bien désinstallez les paquets qui ont généré ces fichiers. (Vérifiez à quel paquet ils appartiennent avec la commande equery. Si elle n'est pas déjà installée, faites emerge gentoolkit). Pour les fichiers que vous utilisez, modifiez juste le bit SUID en faisant chmod -s.

# find / -type f \( -perm -004000 -o -perm -002000 \) \ -exec ls -lg {} \; 2>/dev/null >suidfiles.txt

Cette commande crée un fichier contenant la liste de tous les fichiers SUID/SGID.

/bin/su
/bin/ping
/bin/mount
/bin/umount
/var/qmail/bin/qmail-queue
/usr/bin/chfn
/usr/bin/chsh
/usr/bin/crontab
/usr/bin/chage
/usr/bin/expiry
/usr/bin/sperl5.6.1
/usr/bin/newgrp
/usr/bin/passwd
/usr/bin/gpasswd
/usr/bin/procmail
/usr/bin/suidperl
/usr/lib/misc/pt_chown
/usr/sbin/unix_chkpwd
/usr/sbin/traceroute
/usr/sbin/pwdb_chkpwd

Gentoo Linux ne contient pas beaucoup de fichiers SUID par défaut (cela dépend de ce que vous avez installé). Vous pouvez néanmoins obtenir une liste similaire à celle ci-dessus. La plupart de ces commandes ne devraient pas être utilisées par des utilisateurs normaux et devraient donc être restreintes à root. Désactivez le mode suid sur ping, mount, umount, chfn, chsh, newgrp, suidperl, pt_chown et traceroute en faisant chmod -s sur chacun de ces fichiers. N'enlevez pas ce mode sur les fichiers su, qmail-queue ou unix_chkpwd. Cela vous empêcherait de pouvoir faire des su ou bien de recevoir des courriers. En modifiant ce bit (lorsque c'est sécuritaire), vous enlevez la possibilité à un utilisateur normal (ou à un attaquant) d'obtenir un accès root grâce à ces fichiers.

Les seuls fichiers en mode SUID que j'ai sur mon système sont su, passwd, gpasswd, qmail-queue, unix_chkpwd et pwdb_chkpwd. Mais, si vous utilisez X, vous en aurez sans doute davantage, puisque X requiet l'accès privilégié qui lui est conféré par SUID.

6.d. Binaires SUID/SGID et liens non symboliques

Un fichier n'est considéré comme effacé qu'une fois qu'il n'y a plus de liens pointant vers celui-ci. Cela peut sembler un peu étrange, mais regardez : un fichier comme /usr/bin/perl n'est en fait qu'un lien vers l'inode sur lequel les données sont sauvegardées. On peut créer le nombre de liens qu'on veut vers ce fichier, et tant que tous n'auront pas été supprimés, le fichier continuera d'exister.

Si vos utilisateurs ont accès à une partition qui n'est pas montée avec l'option nosuid ou noexec (par exemple, si /tmp, /home, ou /var/tmp ne sont pas des partitions séparées) vous devez faire attention à ce que vos utilisateurs ne créent pas de liens en dur vers des binaires SGID, pour qu'après une mise à jour avec Portage, ils puissent continuer à avoir accès aux anciennes versions.

Pour vérifier de combien de liens un fichier dispose, vous pouvez utiliser la commande stat.

$ stat /bin/su
  File: `/bin/su'
  Size: 29350           Blocks: 64         IO Block: 131072 regular file
Device: 900h/2304d      Inode: 2057419     Links: 1
Access: (4711/-rws--x--x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2005-02-07 01:59:35.000000000 +0000
Modify: 2004-11-04 01:46:17.000000000 +0000
Change: 2004-11-04 01:46:17.000000000 +0000

Pour trouver les fichiers SUID ou SGID disposant de plusieurs liens, vous pouvez utiliser find.

$ find / -type f \( -perm -004000 -o -perm -002000 \) -links +1 -ls

7. PAM

7.a. PAM

PAM est un ensemble de bibliothèques partagées qui proposent une méthode alternative pour effectuer des authentifications dans les programmes. L'option pam est activée par défaut dans la variable USE. Les paramètres de configuration de PAM dans Gentoo Linux sont relativement bons, mais on peut toujours faire mieux. Tout d'abord, installez cracklib.

# emerge cracklib

auth     required pam_unix.so shadow nullok
account  required pam_unix.so
password required pam_cracklib.so difok=3 retry=3 minlen=8 dcredit=-2 ocredit=-2
password required pam_unix.so md5 use_authtok
session  required pam_unix.so

Ceci ajoutera cracklib, qui contrôlera que les utilisateurs entrent un mot de passe d'un minimum de 8 caractères, qui contient au moins 2 chiffres, 2 symboles, et pour lequel au moins 3 caractères sont différents de ceux du dernier mot de passe. Cela force l'utilisateur à choisir un bon mot de passe. Consultez la documentation PAM pour de plus amples informations.

auth     required pam_unix.so nullok
auth     required pam_shells.so
auth     required pam_nologin.so
auth     required pam_env.so
account  required pam_unix.so
password required pam_cracklib.so difok=3 retry=3 minlen=8 dcredit=-2 ocredit=-2 use_authtok
password required pam_unix.so shadow md5
session  required pam_unix.so
session  required pam_limits.so

Tout service non configuré par un fichier PAM dans /etc/pam.d utilisera les règles contenues dans /etc/pam.d/other. Les valeurs par défaut sont mises à deny comme il se doit. Mais aimant avoir beaucoup de journaux, j'ai ajouté pam_warn.so. La dernière configuration est pam_limits qui est controlée par /etc/security/limits.conf. Consultez la section /etc/security/limits.conf pour plus d'informations sur ces paramètres.

auth     required pam_deny.so
auth     required pam_warn.so
account  required pam_deny.so
account  required pam_warn.so
password required pam_deny.so
password required pam_warn.so
session  required pam_deny.so
session  required pam_warn.so

8. Les « wrappers » TCP

8.a. Les « wrappers » TCP

Ils servent à contrôler l'accès aux services normalement démarrés par inetd (que Gentoo n'utilise pas) et peuvent aussi être utilisés par xinetd et d'autres services.

ALL:PARANOID

ALL: LOCAL @wheel
time: LOCAL, .gentoo.org

Comme vous pouvez le constater, ce format est similaire à celui de /etc/security/access.conf. Toutefois, tcpd supporte un service spécifique et ne recoupe donc pas les fonctionnalités de /etc/security/access.conf. Ces paramètres ne sont applicables qu'aux services qui utilisent les « wrappers » tcpd.

Il est également possible d'exécuter des commandes lorsqu'un service est sollicité (par exemple lorsque vous utilisez la possibilité de numérotation d'un modem pour les utilisateurs) bien que cela ne soit pas recommandé, car cela a tendance à créer plus de problèmes que cela n'en résoud. Un bon exemple est la création d'un script qui envoie un courriel à chaque fois que quelqu'un se voit refuser un accès à cause d'une règle d'interdiction. Une personne malveillante pourrait faire une attaque de type déni de service en provoquant continuellement l'exécution de ce script de notification. Cela génèrerait alors beaucoup d'entrées/sorties et de courriels. Ne le faites donc pas ! Lisez man 5 hosts_access pour plus d'informations.

9. Sécurité du noyau

9.a. Retirer des fonctionnalités

La règle de base lorsque vous configurez le noyau est de retirer tout ce dont vous n'avez pas besoin. Cela créera non seulement un noyau de petite taille mais retirera également toute vulnérabilité qui pourrait être contenue dans un pilote ou dans d'autres modules.

Vous pouvez également envisager de désactiver le support du chargement des modules. Même s'il est possible de charger des « root kits » sans cette option, cela compliquera l'installation d'un « root kit » par le biais des modules du noyau, du moins pour les attaquants conventionnels.

9.b. Le système de fichiers /proc

De nombreux paramètres peuvent être modifiés par le biais de /proc ou en utilisant sysctl.

Vous devez avoir défini CONFIG_SYSCTL dans votre noyau afin de pouvoir modifier des paramètres et variables du noyau dynamiquement. Le noyau 2.4 contient cette option par défaut.

# /bin/echo "0" > /proc/sys/net/ipv4/ip_forward

Assurez-vous d'avoir désactivé l'« IP forwarding ». Cela n'est utile que pour une machine avec plusieurs cartes réseau.

# /bin/echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_all

Cette commande indiquera au noyau d'ignorer les messages de ping (messages ICMP de type 0). La raison pour cela est qu'un paquet IP transportant un message ICMP peut contenir beaucoup plus d'informations que vous ne le pensez. Les administrateurs utilisent ping comme un outil de diagnostic et se plaindront souvent s'ils ne peuvent l'utiliser. Il n'y a aucune raison que quelqu'un de l'extérieur puisse faire un ping, mais quelquefois cela peut être pratique pour les utilisateurs locaux. Ce problème peut être résolu en désactivant les messages ICMP de type 0 sur le pare-feu.

# /bin/echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

Ceci désactive les réponses aux diffusions ICMP et préviendra des attaques « smurf ». Les attaques « smurf » fonctionnent en envoyant un message ICMP de type 0 (ping) à l'adresse de diffusion du réseau. Typiquement, l'attaquant utilisera une adresse source fausse. Tous les ordinateurs du réseau répondront alors au message ping et l'hôte qui possède vraiment l'adresse source utilisée sera surchargé de messages.

# /bin/echo "0" > /proc/sys/net/ipv4/conf/all/accept_source_route

N'acceptez pas les paquets apparemment d'origine interne. Un attaquant peut en effet générer du trafic vers votre réseau en prétendant faire partie du réseau interne. Accepter de tels paquets lui permettrait alors de compromettre votre réseau. Le routage de paquets d'origine interne est rarement utilisé à des fins légitimes ; désactivez-le donc.

# /bin/echo "0" > /proc/sys/net/ipv4/conf/all/accept_redirects

Désactivez l'autorisation des redirections ICMP. Elles sont souvent utilisées pour altérer vos tables de routage, parfois de façon malicieuse.

# /bin/echo "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses

Activez la protection contre les faux messages d'erreurs.

# for i in /proc/sys/net/ipv4/conf/*; do
        /bin/echo "1" > $i/rp_filter
done

Activez le filtrage de chemin inverse. Cela vous permet de vous assurer que les paquets utilisent des adresses sources légitimes en rejetant automatiquement les paquets entrants si l'entrée de leur adresse source dans la table de routage ne correspond pas à la carte réseau par laquelle ils entrent. Un des avantages est de pouvoir empêcher l'usurpation d'IP (« spoofing »). Cette option doit être activée sur toutes les interfaces net/ipv4/conf/* pour être efficace.

# /bin/echo "1" > /proc/sys/net/ipv4/conf/all/log_martians

Enregistre dans le journal les paquets falsifiés, les paquets routés par la source et ceux qui sont redirigés.

Tous ces paramètres seront effacés lors de votre prochain redémarrage. Je vous conseille donc de les ajouter au fichier de configuration /etc/sysctl.conf qui est utilisé par le script d'initialisation /etc/init.d/bootmisc.

La syntaxe à utiliser dans le fichier /etc/sysctl.conf est simple. Vous devez utiliser la même syntaxe que ci-dessus en enlevant la partie /proc/sys/ des chemins mentionnés ci-dessus et en remplaçant les / par des . :

(La commande manuelle) :
/bin/echo "0" > /proc/sys/net/ipv4/ip_forward

(Initialisation automatique via sysctl.conf) :
net.ipv4.ip_forward = 0

9.c. Grsecurity

Le correctif disponible sur Grsecurity est inclus dans les sources sys-kernel/hardened-sources, mais il est désactivé par défaut. Configurez votre noyau comme vous le faites normalement et configurez ensuite l'option Grsecurity (sélectionnez l'option « custom »). Des explications détaillées sont disponibles sur la page du projet Gentoo Hardened.

Les sources hardened-sources récentes contiennent la version 2.* de Grsecurity. Pour de plus amples informations, veuillez consulter la documentation disponible sur la page d'accueil de Grsecurity.

9.d. Kerneli

Kerneli est un correctif qui ajoute des fonctions de cryptage à votre noyau. En corrigeant votre noyau, vous obtiendrez de nouvelles options comme : le chiffrement cryptographique, des algorithmes de validation et des filtres de boucles cryptographiques.

9.e. Autres correctifs du noyau

• Le projet OpenWall
• Système de détection d'intrusion pour Linux
• Contrôle d'accès par règles
• Le noyau sécurisé de la NSA
• Wolk

Il en existe probablement beaucoup d'autres.

10. Sécurisation des services

10.a. Apache

Apache est livré avec un fichier de configuration relativement bon, mais, encore une fois, nous devons optimiser quelques petites choses, comme lier l'écoute d'Apache à une adresse et l'empêcher de donner trop d'information. Vous trouverez ci-dessous les options que vous devriez utiliser dans le fichier de configuration :

Si vous n'avez pas désactivé ssl dans /etc/make.conf avant d'installer Apache, vous devriez être en possession d'un serveur avec SSL activé. Vous trouverez dans /etc/apache2/vhosts.d des exemples de fichiers de configuration. Ces fichiers d'exemple sont mis en production, il convient donc de les vérifier ou de les désactiver.

Il est important de préciser dans votre configuration sur quelle adresse IP attendre les connexions, plutôt que d'écouter sur toutes les adresses IP disponibles sur votre système. Par exemple, pour le fichier 00_default_vhost.conf :

# Faites-le écouter sur votre adresse IP.
Listen 127.0.0.1

Nous vous recommandons également de désactiver l'affichage de toute information sur votre installation d'Apache. Par défaut, la configuration indique d'ajouter la version du serveur ainsi que le vhost aux pages générées par le serveur. Pour désactiver cela, mettez la variable ServerSignature à Off :

# Empêchera Apache de dévoiler sa version.
ServerSignature Off

Apache est compilé avec les options --enable-shared=max et --enable-module=all. Cela autorise tous les modules par défaut. Vous devez donc commenter les modules dont vous n'avez pas besoin dans la section LoadModule (LoadModule et AddModule) du fichier de configuration principal /etc/apache2/httpd.conf. Redémarrez ensuite le service en faisant : /etc/init.d/apache2 restart.

Pour plus d'informations, consultez http://www.apache.org.

10.b. Bind

Consultez la documentation en ligne sur Internet Software Consortium. Le manuel de référence de l'administrateur de BIND 9 se trouve aussi dans doc/arm.

Les ebuilds récents pour le logiciel BIND supportent le chroot sans effort de votre part. Après avoir exécuté emerge bind, suivez ces instructions :

# emerge --config bind
(Avant d'exécuter la commande précédente, vous souhaiterez peut-être
changer le répertoire du chroot dans /etc/conf.d/named. Par défaut,
/chroot/dns sera utilisé.)

10.c. Djbdns

Djbdns est une autres implémentation d'un serveur DNS. Son auteur est prêt à parier de l'argent pour prouver qu'il est sécurisé. Son mode de fonctionnement est très différent de celui de Bind v.9, mais il vaut la peine d'être testé. Vous trouverez plus d'informations sur http://www.djbdns.org/.

10.d. FTP

Utiliser FTP (File Transfer Protocol) est en général une mauvaise idée. Ce service n'utilise aucun cryptage pour les données (les mots de passe sont échangés sous forme de texte clair), écoute sur 2 ports (habituellement 20 et 21) et supporte des utilisateurs anonymes, cette dernière caractéristique étant très attrayante pour les attaquants (qui l'utilisent afin d'échanger des fichiers illégaux (« warez »)). Puisque le protocole FTP comporte de nombreux problèmes de sécurité, vous devriez plutôt utiliser sftp ou HTTP. Si vous devez utiliser FTP, sécurisez vos services du mieux que vous le pouvez, et préparez-vous...

10.e. Mysql

Si seules les applications locales ont besoin d'accéder à la base de données mysql, décommentez la ligne suivante dans /etc/mysql/my.cnf :

skip-networking

Nous désactivons ensuite l'utilisation de la commande LOAD DATA LOCAL INFILE. Cela sert à prévenir une lecture non autorisée à partir des fichiers locaux. Cela devient pertinent lorsque de nouvelles vulnérabilités d'injection SQL sont découvertes dans des applications PHP.

set-variable=local-infile=0

Ensuite, nous devons supprimer la base de donnée fournie comme exemple (test) ainsi que tous les comptes d'utilisateurs à l'exception du compte root local.

mysql> drop database test;
mysql> use mysql;
mysql> delete from db;
mysql> delete from user where not (host="localhost" and user="root");
mysql> flush privileges;

10.f. Proftpd

Proftpd est connu pour avoir eu de nombreux problèmes de sécurité, mais la plupart semblent avoir été réglés. Il est quand même important d'appliquer les améliorations suivantes :

ServerName "Mon démon FTP"
# Ne donnez pas l'identité du serveur.
ServerIdent on "Va voir ailleurs si j'y suis"

# Permet de créer des utilisateurs virtuels plus facilement.
RequireValidShell off

# Utilise des fichiers de groupes et de mots de passe alternatifs
# (passwd utilise un format crypté).
AuthUserFile "/etc/proftpd/passwd"
AuthGroupFile "/etc/proftpd/group"

# Permissions
Umask 077

# Délais maximum et limitations
MaxInstances 30
MaxClients 10 "Only 10 connections allowed"
MaxClientsPerHost 1 "You have already logged on once"
MaxClientsPerUser 1 "You have already logged on once"
TimeoutStalled 10
TimeoutNoTransfer 20
TimeoutLogin 20

# Tout le monde en chroot
DefaultRoot ~

# Ne pas démarrer le service en tant que root.
User  nobody
Group nogroup

# Consigner tout transfert.
TransferLog /var/log/transferlog

# Problèmes avec le « globbing »
DenyFilter \*.*/

Vous trouverez plus de documentation sur http://www.proftpd.org.

10.g. Pure-ftpd

Pure-ftpd est une branche provenant du projet trollftpd, modifié par Frank Dennis pour des raisons de sécurité et pour améliorer ses fonctionnalité.

Utilisez des utilisateurs virtuels (jamais de comptes système) en activant l'option AUTH. Donnez-lui la valeur -lpuredb:/etc/pureftpd.pdb et créez vos utilisateurs en utilisant /usr/bin/pure-pw.

## Interdire les téléchargements si la partition est plus remplie que la valeur
suivante. ##
DISK_FULL="-k 90%"

AUTH="-lpuredb:/etc/pureftpd.pdb"

## Autres options ##
MISC_OTHER="-A -E -X -U 177:077 -d -4 -L100:5 -I 15"

Configurez aussi votre paramètre MISC_OTHER pour ne pas autoriser les utilisateurs anonymes (-E), pour utiliser le chroot pour tout le monde (-A), pour que les utilisateurs ne puissent pas lire ou écrire des fichiers commençant par un . (point) (-X), pour imposer un temps maximum d'inactivité (-I), pour limiter la récursion (-L) et spécifier un umask raisonnable.

Pour en savoir plus, consultez http://www.pureftpd.org.

10.h. Vsftpd

Vsftpd (qui signifie : FTP très sécurisé (« very secure FTP »)) est un petit démon FTP qui tourne avec un fichier de configuration par défaut plutôt correct. Il est très simple et ne possède pas certaines fonctionnalités que d'autres serveurs tels que pureftp et proftp possèdent.

anonymous_enable=NO
local_enable=YES

# Lecture seulement
write_enable=NO

# Active la journalisation des transferts.
xferlog_std_format=YES

idle_session_timeout=20
data_connection_timeout=20
nopriv_user=nobody

chroot_list_enable=YES
chroot_list_file=/etc/vsftpd/chrootlist

ls_recurse_enable=NO

Comme vous pouvez le constater, ce service ne contient pas de permissions individuelles et pas d'action chroot de base. Mais en ce qui concerne la configuration pour les utilisateurs anonymes, il est plutôt bon. Il peut parfois être utile d'avoir un serveur FTP anonyme (afin de partager des sources par exemple) et vsftpd est vraiment parfait pour cela.

10.i. Netqmail

Le serveur de courrier Netqmail est fréquemment qualifié de très sécuritaire. Il a été écrit en misant sur la sécurité (et la paranoïa). Il n'autorise pas le relais des courriels par défaut et n'a eu aucun trou de sécurité depuis 1996. Faites tout simplement emerge netqmail et configurez-le !

10.j. Samba

Samba est un protocole qui permet de partager des fichiers avec des réseaux Microsoft/Novell et qui ne devrait pas être utilisé sur Internet. Il faut néanmoins le sécuriser.

[global]
  # Lier à une interface.
  interfaces = eth0 10.0.0.1/32

  # Asurez-vous d'utiliser des mots de passe cryptés.
  encrypt passwords = yes
  directory security mask = 0700

  # Autoriser le trafic de 10.0.0.*.
  hosts allow = 10.0.0.

  # Permet l'authentification d'utilisateur.
  #(N'utilisez pas le mode partagé.)
  security = user

  # Interdit les comptes privilégiés.
  invalid users = root @wheel

  # Définit la taille maximum, en kilo-octets, affichée pour un élément partagé
  # (ce n'est pas une limite).
  max disk size = 102400

  # Définit la politique de mots de passe.
  min password length = 8
  null passwords = no

  # Utilise PAM (si ce dernier est supporté).
  obey pam restrictions = yes
  pam password change = yes

Assurez-vous que les permissions sont placées correctement sur chaque partage et lisez la documentation.

Redémarrez à présent le serveur et ajoutez les utilisateurs qui devraient avoir accès à ce service. Vous pouvez le faire grâce à la commande /usr/bin/smbpasswd avec le paramètre -a.

10.k. ssh

La seule option de sécurité que vous devez activer sur OpenSSH concerne l'authentification basée sur le cryptage à clé publique. Beaucoup trop de sites (comme http://www.sourceforge.net, http://www.php.net et http://www.apache.org) ont souffert d'intrusions non autorisées sur leurs systèmes à cause de mauvais mots de passe ou de mots de passe divulgués par erreur.

# Autorise uniquement la version 2.
Protocol 2

# Pas d'accès en tant que root. (Les utilisateurs devront utiliser su.)
PermitRootLogin no

# Active l'authentification par clé publique.
PubkeyAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys

# Désactive les fichiers .rhosts et l'authentification normale.
HostbasedAuthentication no
PasswordAuthentication no
PermitEmptyPasswords no

# Seuls les membres des groupes wheel ou admin ont accès.
AllowGroups wheel admin

# Parmi les membres de ces groupes, seuls kn et bs ont accès.
# @<domainname> est facultatif, mais peut remplacer
# l'ancienne directive AllowHosts
AllowUsers kn@gentoo.org bs@gentoo.org

# Règle le niveau de journalisation.
SyslogFacility AUTH
LogLevel INFO

(Mettez votre adresse ici.)
ListenAddress 127.0.0.1

Veuillez vérifier que l'option UsePAM yes ne se trouve pas dans votre configuration, car cela empêche l'authentification par clé publique. Vous pouvez alternativement désactiver l'une des deux options PasswordAuthentication ou ChallengeResponseAuthentication. Vous trouverez plus d'informations à ce sujet dans les pages du manuel de sshd_config.

La seule chose que doivent maintenant faire vos utilisateurs est de créer une clé (sur la machine depuis laquelle ils veulent se connecter) avec la commande suivante :

# /usr/bin/ssh-keygen -t dsa

Entrez une phrase de passe.

Generating public/private dsa key pair.
Enter file in which to save the key (/home/kn/.ssh/id_dsa):[Tapez Entrée.]
Created directory '/home/kn/.ssh'.
Enter passphrase (empty for no passphrase): [Entrez votre phrase de passe.]
Enter same passphrase again: [Entrez votre phrase à nouveau.]
Your identification has been saved in /home/kn/.ssh/id_dsa.
Your public key has been saved in /home/kn/.ssh/id_dsa.pub.
The key fingerprint is:
07:24:a9:12:7f:83:7e:af:b8:1f:89:a3:48:29:e2:a4 kn@knielsen

Cela va ajouter deux fichiers dans votre répertoire ~/.ssh/, nommés id_dsa et id_dsa.pub. Le premier fichier, id_dsa, est votre clé privée et devrait être gardée précieusement pour vous-même et personne d'autre. L'autre fichier, id_dsa.pub, est à distribuer à tous les serveurs auxquels vous avez accès. Ajoutez la clé dans le répertoire personnel de l'utilisateur dans ~/.ssh/authorized_keys, puis l'utilisateur devrait être capable de se connecter :

$ scp id_dsa.pub autre_machine:/var/tmp/currenthostname.pub
$ ssh other-host
password:
$ cat /var/tmp/currenthostname.pub >> ~/.ssh/authorized_keys

Vos utilisateurs devraient conserver leur clé privée précieusement. Il est préconisé de la placer sur un support qu'ils ont toujours sur eux ou alors sur leur station de travail (inclure cette options dans le règlement sur les mots de passe).

Vous trouverez plus d'informations sur le site officiel OpenSSH.

10.l. Utiliser xinetd

xinetd remplace inetd (que Gentoo ne propose pas), le démon pour les services Internet. Il supporte les contrôles d'accès basés sur l'adresse de la machine distante et sur l'heure de l'accès. Il fournit également des fonctionnalités avancées de journalisation, incluant l'heure de démarrage du serveur, l'adresse de la machine distante, le nom de l'utilisateur distant, la durée de fonctionnement du serveur ainsi que les actions demandées.

Tout comme pour les autres services, il est important d'avoir une bonne configuration par défaut. Mais étant donné que xinetd fonctionne en tant que root et supporte des protocoles dont vous pourriez ignorer le fonctionnement, nous vous recommandons de ne pas l'utiliser. Mais, si vous désirez l'utiliser quand même, voici comment le sécuriser quelque peu :

# emerge xinetd tcpd

Puis, éditez le fichier de configuration :

defaults
{
 only_from      = localhost
 instances      = 10
 log_type       = SYSLOG authpriv info
 log_on_success = HOST PID
 log_on_failure = HOST
 cps            = 25 30
}

# Cela créera un pserver (cvs) via xinetd avec les paramètres suivants :
# Maximum de 10 instances (10 connexions simultanées).
# Limite le pserver en mode tcp uniquement.
# Utilise l'utilisateur cvs pour démarrer le service.
# Lie les interfaces à une seule IP.
# Autorise l'accès uniquement depuis 10.0.0.*.
# Limite l'accès des développeurs au serveur entre 8h et 17h.
# Utilise les « wrappers » tpcd (contrôlés par liste d'accès dans
# /etc/hosts.allow et /etc/hosts.deny).
# Le max_load sur la machine est de 1.0.
# L'option de désactivation est normalement inutilisée mais j'aime l'avoir
# si jamais elle doit être utilisée pour désactiver le service.
service cvspserver
{
 socket_type    = stream
 protocol       = tcp
 instances      = 10
 protocol       = tcp
 wait           = no
 user           = cvs
 bind           = 10.0.0.2
 only_from      = 10.0.0.0
 access_times   = 8:00-17:00
 server         = /usr/sbin/tcpd
 server_args    = /usr/bin/cvs --allow-root=/mnt/cvsdisk/cvsroot pserver
 max_load       = 1.0
 log_on_failure += RECORD
 disable        = no
}

Pour plus d'informations, consultez man 5 xinetd.conf.

10.m. X

Xorg est configuré par défaut pour agir comme un serveur X. Cela peut être dangeureux étant donné que X utilise des connexions tcp qui ne sont pas cryptées et reste à l'écoute de clients X.

Si vous utilisez votre station comme serveur X, utilisez la commande /usr/X11R6/bin/xhost avec précaution. Cette commande permet aux clients de se connecter depuis d'autres machines et d'utiliser votre affichage. Cela peut être utile si vous avez besoin de démarrer une application X depuis une autre machine et que la seule façon de le faire est depuis le réseau, mais cela peut aussi être exploité par un attaquant. La syntaxe de cette commande est /usr/X11R6/bin/xhost +hostname.

Une solution plus sécurisée est de désactiver cette fonctionnalité complètement en démarrant votre X avec l'option startx -- -nolisten tcp ou bien en désactivant complètement cette option dans le fichier de configuration :

defaultserverargs="-nolisten tcp"

Pour vous assurer que startx ne soit pas écrasé lorsque vous installez une nouvelle version de Xorg, vous devez le protéger. Ajoutez la ligne suivante au fichier /etc/make.conf :

CONFIG_PROTECT_MASK="/usr/X11R6/bin/startx"

Si vous utilisez une invite de connexion graphique, vous devez utiliser une approche différente.

Pour gdm (GNOME Display Manager) :

[server-Standard]
command=/usr/X11R6/bin/X -nolisten tcp

Pour xdm (X Display Manager) et kdm (KDE Display Manager) :

:0 local /usr/bin/X11/X -nolisten tcp

11. Les environnements chroot et les serveurs virtuels

11.a. Utiliser un environnement chroot

« Chrooter » un service (ou un utilisateur) est une façon de limiter son environnement afin qu'il n'accède qu'à l'essentiel sans pouvoir obtenir un accès (ou des informations) qui pourraient mener aux privilèges root. En démarrant un service par le biais d'un autre utilisateur que root (nobody, apache, named), un attaquant ne peut accéder aux fichiers qu'avec les permissions de cet utilisateur. Cela veut dire qu'un attaquant ne peut obtenir un accès root même si les services ont une faille de sécurité.

Certains services comme pure-ftpd et bind ont des fonctionnalités permettant d'utiliser chroot, mais pas tous. Si le service le supporte, profitez-en. Sinon, il vous faudra trouver un moyen de créer le vôtre. Voyons à présent comment créer un environnement chroot. Pour comprendre les bases, nous allons expérimenter avec bash. (Ce qui est une façon aisée d'apprendre à utiliser chroot.)

Créez le répertoire /chroot (mkdir /chroot) et cherchez quelles sont les bibliothèques dynamiques avec lesquelles bash est compilé (si la compilation a été faite avec le mode -static, ce n'est pas nécessaire) :

La commande suivante va créer une liste des bibliothèques utilisées par bash.

# ldd /bin/bash
  libncurses.so.5 => /lib/libncurses.so.5 (0x4001b000)
  libdl.so.2 => /lib/libdl.so.2 (0x40060000)
  libc.so.6 => /lib/libc.so.6 (0x40063000)
  /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

Créons à présent un environnement pour bash.

# mkdir /chroot/bash
# mkdir /chroot/bash/bin
# mkdir /chroot/bash/lib

Copiez ensuite les fichiers utilisés par bash (/lib) dans le répertoire lib de l'environnement chroot et copiez la commande bash dans le répertoire bin du chroot. Cela devrait suffire pour recréer l'environnement, mais avec moins de fonctionnalités. Il ne vous reste qu'à l'essayer : chroot /chroot/bash /bin/bash. Si vous obtenez une invite vous donnant /, c'est gagné ! Dans le cas contraire, il devrait vous dire quel est le fichier manquant. Il se peut également que certaines bibliothèques partagées dépendent d'autres bibliothèques.

Vous remarquerez assez vite que, dans le chroot, rien ne marche à part echo. C'est parce que nous n'avons aucune autre commande dans notre environnement que bash et qu'echo est une fonction intégrée.

La méthode est la même pour créer un service en chroot. La seule différence est que les services se basent parfois sur des périphériques (« devices ») et des fichiers de configuration dans /etc. Copiez-les tout simplement (des périphériques peuvent être copiés avec cp -a) vers l'environnement chroot, éditez le script d'initialisation (init) pour qu'il utilise chroot avant de s'exécuter. Il peut être difficile de trouver quels périphériques et fichiers de configuration sont nécessaires. C'est ici que la commande strace devient utile. Démarrez le service avec /usr/bin/strace et notez les fonctions suivantes : open, read, stat et peut-être connect. Cela devrait vous donner une bonne idée des fichiers à copier. Dans la plupart des cas, copiez juste le fichier passwd (retirez tous les utilisateurs qui n'ont aucun rapport avec le service), /dev/zero, /dev/log et /dev/random.

11.b. Le mode utilisateur Linux (« User Mode Linux »)

Une autre façon de créer un environnement plus sécurisé est de faire fonctionner une machine virtuelle. Une telle machine est, comme son nom l'indique, un processus exécuté par votre véritable système d'exploitation, et qui fournit un environnement matériel et un système d'exploitation qui donnent l'impression d'être une machine en soit. Le bénéfice, en ce qui a trait à la sécurité, est que si le serveur exécuté par la machine virtuelle est compromis, seul le serveur virtuel est affecté, et non pas l'installation mère.

Pour plus d'informations au sujet de l'installation du mode utilisateur Linux, consultez le User Mode Linux Guide.

12. Pare-feu

12.a. Un pare-feu

La plupart des gens pensent qu'un pare-feu est la réponse ultime aux problèmes de sécurité. Ils ont tort. Dans la majorité des cas, avoir un pare-feu mal configuré présente plus de dangers de sécurité que de ne pas en avoir du tout. Un pare-feu est un logiciel et doit donc être traité comme tout autre service, tout simplement car il est susceptible d'avoir des bogues, au même titre que les autres programmes.

Réfléchissez donc bien avant de mettre en placce un pare-feu ! En avez-vous vraiment besoin ? Si vous le pensez, écrivez une politique sur son utilité, son type et qui doit s'en occuper. Mais tout d'abord, lisez ce guide.

Les pare-feu sont utilisés dans deux situations :

• Pour garder des utilisateurs (vers/attaquants) à l'extérieur.
• Pour garder des utilisateurs (employés/enfants) à l'intérieur.

Il existe globalement 3 types de pare-feu :

• Filtrage de paquets
• Relais de circuit
• Passerelle d'application

Un pare-feu devrait être une machine dédiée sans aucun service (ou uniquement sshd) et sécurisée de la façon qui est recommandée dans ce guide.

12.b. Filtrage de paquets

Tout le trafic réseau se fait sous forme de paquets. Une grande partie du trafic est découpée en petits paquets pour une gestion plus simple. Ils sont ensuite réassemblés une fois arrivés à leur destination. L'en-tête de chaque paquet contient des informations sur comment et où il devrait être délivré. Ces informations sont très exactement ce qu'un pare-feu filtrant les paquets utilise. Le filtrage se base sur :

• Autorisation ou interdiction des paquets en se basant sur l'adresse IP source/destination.
• Autorisation ou interdiction des paquets en se basant sur un port source/destination.
• Autorisation ou interdiction des paquets selon le protocole.
• Autorisation ou interdiction des paquets selon les options établies à l'intérieur d'un protocole.

En d'autres mots, le filtrage se fait sur les données contenues dans l'en-tête d'un paquet et non pas sur son contenu.

Faiblesses :

• L'adresse IP d'un paquet peut être contrefaite ou, comme le veut le terme dédié, spoofée par son envoyeur.
• Les données ou requêtes contenues dans le paquet peuvent contenir des données indésirables que l'attaquant peut utiliser pour exploiter des bogues connus dans les services qui sont sur ou derrière le pare-feu.
• Est généralement un point faible pouvant causer une panne globale.

Avantages :

• Simple et facile à implémenter.
• Peut donner des avertissements sur une attaque possible avant qu'elle n'arrive (en détectant les scanneurs de ports).
• Bonne méthode pour arrêter les attaques de type SYN.

Voici quelques exemples de filtreurs de paquets gratuits sous Linux :

• Iptables.
• Ipchains.
• SmoothWall.

12.c. Relais de circuit

Aussi appelé passerelle de niveau circuit, ce type de pare-feu valide les connexions avant d'autoriser l'échange de données. Cela signifie qu'il n'autorise et ne refuse pas les paquets en fonction de leur en-tête mais détermine plutôt si une connexion entre les deux parties est valide, en consultant un ensemble de règles configurables, avant d'autoriser l'ouverture d'une session de transfert de données. Le filtrage est basé sur :

• Adresse de destination/source
• Port de destination/source
• Un certain laps de temps
• Protocole
• Utilisateur
• Mot de passe

Tout le trafic est validé et surveillé, et peut être bloqué lorsqu'il ne correspond pas aux règles.

Faiblesse :

• Opère sur la couche de transport et peut nécessiter des modifications substantielles des programmes fournissant habituellement les fonctions de transport.

12.d. Passerelle d'applications

La passerelle de niveau application est un mandataire pour les applications, échangeant des données avec un système distant selon les demandes de ses clients. Elle est gardée à l'abri du public, en sécurité derrière une DMZ (zone démilitarisée, la portion de réseau privé visible à travers le pare-feu) ou un pare-feu sans connexion vers l'extérieur. Le filtrage est basé sur :

• L'autorisation ou l'interdiction selon les adresses IP source/destination.
• Le contenu des paquets.
• Limitation de l'accès aux fichiers en fonction du type ou de l'extension.

Avantages :

• Peut mettre des fichiers en cache, améliorant ainsi les performances réseau.
• Journal complet et détaillé de toutes les connexions.
• S'adapte bien aux changements d'échelle (certains serveurs mandataires peuvent « partager » les données en cache).
• Aucun accès direct depuis l'extérieur.
• Peut même modifier le contenu des paquets en temps réel.

Faiblesses :

• Sa configuration est compliquée.

Les passerelles d'applications sont considérées comme les solutions les plus sécurisées étant donné qu'elles ne doivent pas fonctionner sous root et que leurs hôtes ne sont pas accessibles depuis Internet.

Un exemple de passerelle d'applications est Squid.

12.e. Iptables

Vous devez activer iptables dans le noyau pour pouvoir l'utiliser. Je l'ai ajouté en tant que modules (la commande iptables les chargera lorsqu'elle en a besoin), puis j'ai recompilé mon noyau. (Toutefois, si vous souhaitez désactiver l'option Loadable Kernel Modules tel que discuté plus tôt, vous devrez ajouter iptables directement dans le noyau.) Pour plus d'informations sur la configuration du noyau pour iptables, consultez le Iptables Tutorial Chapter 5: Preparations. Après la compilation de votre nouveau noyau (ou pendant sa compilation), vous devez installer la commande iptables. Il suffit d'exécuter emerge iptables, et cela devrait fonctionner.

Testez à présent si tout fonctionne avec la commande iptables -L. Si cette dernière échoue, c'est que quelque chose ne va pas ; vérifiez à nouveau votre configuration.

Iptables est le nouveau filtreur de paquets du noyau Linux 2.4.x. Il a été considérablement amélioré par rapport à son prédécesseur, ipchains, le filtreur de paquets du noyau Linux 2.2.x. Une des principales améliorations est le filtrage de paquets par état. Grâce à cette fonction, il est possible de garder une trace de chaque connexion TCP établie.

Une connexion TCP est composée d'une série de paquets contenant des informations sur les adresses IP et les ports de la source et du destinataire, ainsi qu'une séquence permettant de réassembler les paquets par la suite, sans perte de données. TCP est un protocole qui établit une connexion, contrairement à UDP.

En examinant les en-têtes des paquets, un filtre de paquets par état peut déterminer si un paquet TCP reçu fait partie d'une connexion établie ou non, et ainsi accepter ou rejeter le paquet.

Avec un filtre de paquets sans état, il est possible de leurrer le filtre en lui faisant accepter des paquets qui devraient être rejetés. Cela se fait en manipulant les en-têtes des paquets TCP. En modifiant le drapeau SYN (ou d'autres drapeaux) de l'en-tête TCP, on peut déguiser un paquet mal intentionné pour qu'il semble faire partie d'une connexion déjà établie (car le filtre de paquets ne garde pas de trace des connexions). Avec un filtrage par état, il est possible de rejeter de tels paquets, étant donné qu'ils ne font pas partie d'une connexion déja établie. Cela empêchera aussi les « scans invisibles », un type de scanneur de ports qui envoie des paquets dont les drapeaux sont moins susceptibles d'être consignés par un pare-feu que ceux des paquets SYN standards.

Iptables propose beaucoup d'autres fonctionnalités comme le NAT (Network Address Translation - traduction d'adresses réseau) et la limitation de flux. La limitation de flux est très utile quand on essaie de prévenir certaines attaques de type déni de service (DoS) comme les « SYN floods ».

Une connexion TCP est établie en trois temps (N.D.T. : « three-way handshake » en anglais). Quand on établit une connexion TCP, le client envoie un paquet au serveur avec le drapeau SYN levé. Quand le serveur reçoit le paquet SYN, il répond en envoyant un paquet SYN+ACK au client. Quand le paquet SYN+ACK est reçu par le client, il répond avec un troisième paquet ACK qui a pour effet d'établir la connexion.

Un attaque « SYN floods » est effectuée en envoyant le paquet SYN mais en ne répondant pas au paquet SYN+ACK. Le client peut créer un paquet avec une adresse IP source falsifiée car il n'a pas besoin de réponse. Le serveur ajoute une entrée dans la queue de connexions semi-ouvertes quand il reçoit le paquet SYN et attend ensuite le paquet ACK final avant de supprimer cette entrée de la queue. La queue a un nombre de places limité et, si toutes les places sont occupées, le serveur ne peut plus ouvrir de connexions. Si le paquet ACK n'est pas reçu avant un délai spécifié, l'entrée va être automatiquement supprimée de la queue. Le délai varie, mais se situe typiquement entre 30 et 60 secondes, voire plus. Le client initie l'attaque en créant une énorme quantité de paquets SYN avec des adresses IP sources différentes et les envoie vers l'IP cible avec le plus haut débit possible. Cela a pour effet de remplir la queue des connexions semi-ouvertes et empêche les autres clients d'établir des connexions légitimes avec le serveur.

C'est là que la limitation de flux devient utile. Il est possible de limiter le flux de paquets SYN acceptés en utilisant -m limit --limit 1/s. Cela limitera le nombre de paquets SYN acceptés à un par seconde et réduira donc l'efficacité du « SYN floods ».

Maintenant un peu de pratique !

Lorsque iptables est chargé dans le noyau, il contient 5 sections dans lesquelles vous pouvez placer vos règles : INPUT, OUTPUT, FORWARD, PREROUTING et POSTROUTING. Ces sections sont appelées chaînes car elles consistent en une liste de règles. Chaque règle indique ce qu'il faut faire en fonction de l'en-tête du paquet. Si une règle ne correspond pas à un paquet, la règle suivante est consultée.

Vous pouvez ajouter des règles directement dans une des 5 chaînes ou créer des chaînes de règles et les ajouter aux chaînes existantes. Iptables supporte les options suivantes :

Nous allons d'abord essayer de bloquer tous les paquets ICMP sur notre machine, juste dans le but de se familiariser avec les commandes.

# iptables -A INPUT -p icmp -j DROP

On spécifie tout d'abord la chaîne à laquelle notre règle devrait appartenir, ensuite le protocole des paquets qui nous intéressent, et, enfin, la cible. La cible peut être le nom d'une chaîne spécifiée par l'utilisateur ou une des cibles spéciales ACCEPT, DROP, REJECT, LOG, QUEUE, MASQUERADE. Dans cet exemple, nous utilisons DROP, qui va ignorer le paquet sans répondre au client.

Essayez à présent de faire ping localhost. Vous n'obtiendrez aucune réponse car iptables ignorera tous les messages ICMP entrants. Vous ne pourrez pas non plus utiliser ping vers d'autres machines, car les paquets de réponse ICMP seront également ignorés. Maintenant, vidons la chaîne pour donner à nouveau libre cours au trafic ICMP.

# iptables -F

Regardons maintenant le filtrage par état dans iptables. Si nous désirons activer l'inspection des paquets entrants sur eth0, la commande à utiliser est la suivante :

# iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

Cela acceptera tous les paquets provenant d'une connexion déjà établie ou ayant un rapport avec la chaîne INPUT. Vous pourriez ignorer tous les paquets qui ne sont pas dans la table des états en faisant iptables -A INPUT -i eth0 -m state --state INVALID -j DROP juste avant la commande précédente. Cela active le filtrage par état dans iptables en chargeant l'extension nommée « state ». Si vous voulez qu'une machine de l'extérieur puisse se connecter à votre machine, vous pouvez utiliser --state NEW. Iptables contient des modules correspondant à différentes fonctions. En voici quelques-uns :

Essayons à présent de créer une chaîne définie par l'utilisateur et de l'appliquer sur une chaîne existante :

(Crée une nouvelle chaîne avec une seule règle.)
# iptables -X machaine
# iptables -N machaine
# iptables -A machaine -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
(La politique par défaut est d'accepter tout le trafic sortant. Tout le
trafic entrant est ignoré.)
# iptables -P OUTPUT ACCEPT
# iptables -P INPUT DROP
(Et on ajoute cela à la chaîne INPUT.)
# iptables -A INPUT -j machaine

En ajoutant cette règle, tout paquet sortant est autorisé et le trafic entrant est ignoré.

Pour plus d'informations, consultez la documentation sur iptables.

Voyons à présent un exemple complet. Dans ce cas précis, il s'agit de mes règles de pare-feu/passerelle :

• Connexions au pare-feu uniquement autorisées via SSH (port 22).
• Le réseau local doit avoir accès à HTTP, HTTPS et SSH (DNS est également autorisé).
• Le trafic ICMP peut être nocif et devrait être interdit. Évidemment, nous devons autoriser un peu de trafic ICMP.
• Les scanneurs de ports doivent être détectés et leur actions consignées.
• Les attaques SYN doivent être évitées.
• Tout autre trafic doit être ignoré et consigné.

#!/sbin/runscript
IPTABLES=/sbin/iptables
IPTABLESSAVE=/sbin/iptables-save
IPTABLESRESTORE=/sbin/iptables-restore
FIREWALL=/etc/firewall.rules
DNS1=212.242.40.3
DNS2=212.242.40.51
#interne
IIP=10.0.0.2
IINTERFACE=eth0
LOCAL_NETWORK=10.0.0.0/24
#externe
OIP=217.157.156.144
OINTERFACE=eth1

opts="${opts} showstatus panic save restore showoptions rules"

depend() {
  need net
}

rules() {
  stop
  ebegin "Paramétrer les règles internes"

  einfo "On ignore tout par défaut"
  $IPTABLES -P FORWARD DROP
  $IPTABLES -P INPUT   DROP
  $IPTABLES -P OUTPUT  DROP

  # Règles par default
  einfo "Créer les chaînes d'état"
  $IPTABLES -N allowed-connection
  $IPTABLES -F allowed-connection
  $IPTABLES -A allowed-connection -m state --state ESTABLISHED,RELATED -j ACCEPT
  $IPTABLES -A allowed-connection -i $IINTERFACE -m limit -j LOG --log-prefix \
      "Bad packet from ${IINTERFACE}:"
  $IPTABLES -A allowed-connection -j DROP

  # Trafic ICMP
  einfo "Créer la chaîne icmp"
  $IPTABLES -N icmp_allowed
  $IPTABLES -F icmp_allowed
  $IPTABLES -A icmp_allowed -m state --state NEW -p icmp --icmp-type \
      time-exceeded -j ACCEPT
  $IPTABLES -A icmp_allowed -m state --state NEW -p icmp --icmp-type \
      destination-unreachable -j ACCEPT
  $IPTABLES -A icmp_allowed -p icmp -j LOG --log-prefix "Bad ICMP traffic:"
  $IPTABLES -A icmp_allowed -p icmp -j DROP

  # Trafic entrant
  einfo "Créer la chaîne de trafic ssh entrant"
  $IPTABLES -N allow-ssh-traffic-in
  $IPTABLES -F allow-ssh-traffic-in
  # Protection anti Flood
  $IPTABLES -A allow-ssh-traffic-in -m limit --limit 1/second -p tcp --tcp-flags \
      ALL RST --dport ssh -j ACCEPT
  $IPTABLES -A allow-ssh-traffic-in -m limit --limit 1/second -p tcp --tcp-flags \
      ALL FIN --dport ssh -j ACCEPT
  $IPTABLES -A allow-ssh-traffic-in -m limit --limit 1/second -p tcp --tcp-flags \
      ALL SYN --dport ssh -j ACCEPT
  $IPTABLES -A allow-ssh-traffic-in -p tcp --dport ssh -j ACCEPT

  # Trafic sortant
  einfo "Créer la chaîne de trafic SSH sortant"
  $IPTABLES -N allow-ssh-traffic-out
  $IPTABLES -F allow-ssh-traffic-out
  $IPTABLES -A allow-ssh-traffic-out -p tcp --dport ssh -j ACCEPT

  einfo "Créer la chaîne de trafic DNS sortant"
  $IPTABLES -N allow-dns-traffic-out
  $IPTABLES -F allow-dns-traffic-out
  $IPTABLES -A allow-dns-traffic-out -p udp -d $DNS1 --dport domain \
      -j ACCEPT
  $IPTABLES -A allow-dns-traffic-out -p udp -d $DNS2 --dport domain \
     -j ACCEPT

  einfo "Créer la chaîne de trafic HTTP/HTTPS sortant"
  $IPTABLES -N allow-www-traffic-out
  $IPTABLES -F allow-www-traffic-out
  $IPTABLES -A allow-www-traffic-out -p tcp --dport www -j ACCEPT
  $IPTABLES -A allow-www-traffic-out -p tcp --dport https -j ACCEPT

  # Détecter les scanneurs de ports.
  einfo "Créer la chaîne de détection de portscan"
  $IPTABLES -N check-flags
  $IPTABLES -F check-flags
  $IPTABLES -A check-flags -p tcp --tcp-flags ALL FIN,URG,PSH -m limit \
      --limit 5/minute -j LOG --log-level alert --log-prefix "NMAP-XMAS:"
  $IPTABLES -A check-flags -p tcp --tcp-flags ALL FIN,URG,PSH -j DROP
  $IPTABLES -A check-flags -p tcp --tcp-flags ALL ALL -m limit --limit \
      5/minute -j LOG --log-level 1 --log-prefix "XMAS:"
  $IPTABLES -A check-flags -p tcp --tcp-flags ALL ALL -j DROP
  $IPTABLES -A check-flags -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG \
      -m limit --limit 5/minute -j LOG --log-level 1 --log-prefix "XMAS-PSH:"
  $IPTABLES -A check-flags -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP
  $IPTABLES -A check-flags -p tcp --tcp-flags ALL NONE -m limit \
      --limit 5/minute -j LOG --log-level 1 --log-prefix "NULL_SCAN:"
  $IPTABLES -A check-flags -p tcp --tcp-flags ALL NONE -j DROP
  $IPTABLES -A check-flags -p tcp --tcp-flags SYN,RST SYN,RST -m limit \
      --limit 5/minute -j LOG --log-level 5 --log-prefix "SYN/RST:"
  $IPTABLES -A check-flags -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
  $IPTABLES -A check-flags -p tcp --tcp-flags SYN,FIN SYN,FIN -m limit \
      --limit 5/minute -j LOG --log-level 5 --log-prefix "SYN/FIN:"
  $IPTABLES -A check-flags -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP

  # Applique et ajoute les chaînes invalides.
  einfo "Appliquer les chaînes a INPUT"
  $IPTABLES -A INPUT -m state --state INVALID -j DROP
  $IPTABLES -A INPUT -p icmp -j icmp_allowed
  $IPTABLES -A INPUT -j check-flags
  $IPTABLES -A INPUT -i lo -j ACCEPT
  $IPTABLES -A INPUT -j allow-ssh-traffic-in
  $IPTABLES -A INPUT -j allowed-connection

  einfo "Appliquer les chaînes au FORWARD"
  $IPTABLES -A FORWARD -m state --state INVALID -j DROP
  $IPTABLES -A FORWARD -p icmp -j icmp_allowed
  $IPTABLES -A FORWARD -j check-flags
  $IPTABLES -A FORWARD -o lo -j ACCEPT
  $IPTABLES -A FORWARD -j allow-ssh-traffic-in
  $IPTABLES -A FORWARD -j allow-www-traffic-out
  $IPTABLES -A FORWARD -j allowed-connection

  einfo "Appliquer les chaînes à l'OUTPUT"
  $IPTABLES -A OUTPUT -m state --state INVALID -j DROP
  $IPTABLES -A OUTPUT -p icmp -j icmp_allowed
  $IPTABLES -A OUTPUT -j check-flags
  $IPTABLES -A OUTPUT -o lo -j ACCEPT
  $IPTABLES -A OUTPUT -j allow-ssh-traffic-out
  $IPTABLES -A OUTPUT -j allow-dns-traffic-out
  $IPTABLES -A OUTPUT -j allow-www-traffic-out
  $IPTABLES -A OUTPUT -j allowed-connection

  # Autoriser les clients à router via le NAT (« Network Address Translation »).
  $IPTABLES -t nat -A POSTROUTING -o $OINTERFACE -j MASQUERADE
  eend $?
}

start() {
  ebegin "Démarrage du pare-feu"
  if [ -e "${FIREWALL}" ]; then
    restore
  else
    einfo "${FIREWALL} n'existe pas. Utilisation des règles par defaut."
    rules
  fi
  eend $?
}

stop() {
  ebegin "Arrêt du pare-feu"
  $IPTABLES -F
  $IPTABLES -t nat -F
  $IPTABLES -X
  $IPTABLES -P FORWARD ACCEPT
  $IPTABLES -P INPUT   ACCEPT
  $IPTABLES -P OUTPUT  ACCEPT
  eend $?
}

showstatus() {
  ebegin "Statut"
  $IPTABLES -L -n -v --line-numbers
  einfo "Statut NAT"
  $IPTABLES -L -n -v --line-numbers -t nat
  eend $?
}

panic() {
  ebegin "Mise en place des règles de panique"
  $IPTABLES -F
  $IPTABLES -X
  $IPTABLES -t nat -F
  $IPTABLES -P FORWARD DROP
  $IPTABLES -P INPUT   DROP
  $IPTABLES -P OUTPUT  DROP
  $IPTABLES -A INPUT -i lo -j ACCEPT
  $IPTABLES -A OUTPUT -o lo -j ACCEPT
  eend $?
}

save() {
  ebegin "Enregistrement des règles de pare-feu"
  $IPTABLESSAVE > $FIREWALL
  eend $?
}

restore() {
  ebegin "Rétablissement des règles précédentes"
  $IPTABLESRESTORE < $FIREWALL
  eend $?
}

restart() {
  svc_stop; svc_start
}

showoptions() {
  echo "Usage: $0 {start|save|restore|panic|stop|restart|showstatus}"
  echo "start)      Restaure les paramètres s'ils existent, sinon force les règles."
  echo "stop)       Efface toutes les règles et autorise tout accès."
  echo "rules)      Force les paramètres des nouvelles règles."
  echo "save)       Sauve les paramètres dans ${FIREWALL}."
  echo "restore)    Récupère les paramètres depuis ${FIREWALL}."
  echo "showstatus) Affiche le statut."
}

Quelques conseils pour la création d'un pare-feu :

1. Créez la politique de votre pare-feu avant de l'implémenter.
2. Faites quelque chose de simple.
3. Connaissez le fonctionnement de chaque protocole. (Lisez le RFC (Request For Comments) approprié.)
4. Gardez en tête que votre pare-feu n'est qu'un logiciel qui fonctionne sous root.
5. Testez votre pare-feu.

Si vous pensez que iptables est difficile à comprendre ou vous prendra trop de temps à configurer, vous pouvez utiliser Shorewall. Il utilise iptables pour générer des règles de pare-feu, mais se concentre sur les règles et pas les protocoles spécifiques.

12.f. Squid

Squid est un serveur mandataire très puissant. Il peut filtrer le trafic en fonction de l'heure, d'une expression rationnelle sur le chemin/URI, d'une adresse IP source/destination, du domaine, du navigateur, de l'utilisateur, d'un type MIME ou bien d'un numéro de port (protocole). J'en ai sans doute oublié d'autres, mais il serait difficile de les énoncer dans leur ensemble ici.

Dans l'exemple suivant, j'ai ajouté un filtre de bannières plutôt qu'un filtre basé sur du contenu pornographique. La raison pour cela est que Gentoo.org ne devrait pas être listé comme site à caractère pornographique, et je ne veux pas perdre mon temps à essayer de vous trouver de bonnes adresses de sites.

Dans cet exemple précis, mes règles sont les suivantes :

• Le surf (HTTP/HTTPS) est autorisé pendant les heures de bureau (du lundi au vendredi de 8 à 17 heures, et le samedi de 8 à 13 heures), mais si les employés restent plus tard, c'est pour travailler et pas pour surfer.
• Le téléchargement de fichiers est interdit (.exe, .com, .arj, .zip, .asf, .avi, .mpg, .mpeg, etc.).
• N'aimant pas les bannières publicitaires, nous les filtrons et les remplaçons par un gif transparent. (C'est ici que vous devenez créatif !)
• Toute autre connexion venant d'Internet ou vers Internet est interdite.

Cela se fait en 4 étapes simples :

# Liaison à une adresse IP et un port
http_port 10.0.2.1:3128

# Configuration standard
hierarchy_stoplist cgi-bin ?
acl QUERY urlpath_regex cgi-bin \?
no_cache deny QUERY

# Contrôle d'accès standard
acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255

# Machines autorisées à accéder à ce serveur
acl localnet src 10.0.0.0/255.255.0.0

# Et les ports
acl SSL_ports port 443
acl Safe_ports port 80
acl Safe_ports port 443
acl purge method PURGE

# Liste d'accès basée sur les expressions rationnelles
acl archives urlpath_regex "/etc/squid/files.acl"
acl url_ads url_regex "/etc/squid/banner-ads.acl"

# Liste d'accès basée sur les horaires
acl restricted_weekdays time MTWHF 8:00-17:00
acl restricted_weekends time A 8:00-13:00

acl CONNECT method CONNECT

# Autorise l'administrateur à se connecter depuis la machine locale.
http_access allow manager localhost
http_access deny manager

# Nettoyage de cache autorisé uniquement localement.
http_access allow purge localhost
http_access deny purge

# Refuse les requêtes vers des ports inconnus.
http_access deny !Safe_ports

# Refuse les connexions en dehors du port SSL.
http_access deny CONNECT !SSL_ports

# Mes règles

# Affiche une page quand un bandeau est supprimé.
deny_info NOTE_ADS_FILTERED url_ads

# Puis les refuse.
http_access deny url_ads

# Refuse toutes les archives.
http_access deny archives

# Restreint l'accès aux heures de bureau.
http_access allow localnet restricted_weekdays
http_access allow localnet restricted_weekends

# Refuse le reste.
http_access deny all

Indiquez ensuite les fichiers dont vous ne voulez pas autoriser le téléchargement. J'ai ajouté : zip, viv, exe, mp3, rar, ace, avi, mov, mpg, mpeg, au, ra, arj, tar, gz et z.

\.[Zz][Ii][pP]$
\.[Vv][Ii][Vv].*
\.[Ee][Xx][Ee]$
\.[Mm][Pp]3$
\.[Rr][Aa][Rr]$
\.[Aa][Cc][Ee]$
\.[Aa][Ss][Ff]$
\.[Aa][Vv][Ii]$
\.[Mm][Oo][Vv]$
\.[Mm][Pp][Gg]$
\.[Mm][Pp][Ee][Gg]$
\.[Aa][Uu]$
\.[Rr][Aa]$
\.[Aa][Rr][Jj]$
\.[Tt][Aa][Rr]$
\.[Gg][Zz]$
\.[Zz]$

On ajoute ensuite les expressions rationnelles pour identifier les bannières. Vous serez sans doute plus créatif que moi :

/adv/.*\.gif$
/[Aa]ds/.*\.gif$
/[Aa]d[Pp]ix/
/[Aa]d[Ss]erver
/[Aa][Dd]/.*\.[GgJj][IiPp][FfGg]$
/[Bb]annerads/
/adbanner.*\.[GgJj][IiPp][FfGg]$
/images/ad/
/reklame/
/RealMedia/ads/.*
^http://www\.submit-it.*
^http://www\.eads.*
^http://ads\.
^http://ad\.
^http://ads02\.
^http://adaver.*\.
^http://adforce\.
adbot\.com
/ads/.*\.gif.*
_ad\..*cgi
/Banners/
/SmartBanner/
/Ads/Media/Images/
^http://static\.wired\.com/advertising/
^http://*\.dejanews\.com/ads/
^http://adfu\.blockstackers\.com/
^http://ads2\.zdnet\.com/adverts
^http://www2\.burstnet\.com/gifs/
^http://www.\.valueclick\.com/cgi-bin/cycle
^http://www\.altavista\.com/av/gifs/ie_horiz\.gif

Et, enfin, on veut afficher un fichier lorsque l'on retire une bannière. Il s'agit ici d'un fichier html partiel contenant une image gif transparente de taille 4x4.

<HTML>
<HEAD>
<META HTTP-EQUIV="REFRESH" CONTENT="0; URL=http://localhost/images/4x4.gif">
<TITLE>Erreur, l'URL que vous avez demandée est indisponible</TITLE>
</HEAD>
<BODY>
<H1>Publicité filtrée !</H1>

Comme vous pouvez le constater, Squid a beaucoup de possibilités et est très efficace dans le filtrage de contenu ainsi qu'en tant que mandataire. Vous pouvez même utiliser plusieurs serveurs Squid dans des configurations réseau de grande taille. Le type de configuration que j'ai listé ici devrait convenir à un réseau de petite taille (entre 1 et 20 utilisateurs).

Cependant, combiner le filtrage de paquets (iptables) et un serveur d'applications (Squid) est probablement la meilleure solution, même si Squid est situé dans un endroit sécurisé non accessible de l'extérieur. Gardez en tête que les attaques peuvent aussi venir de l'intérieur.

Vous devez maintenant configurer les navigateurs de vos clients pour qu'ils utilisent le serveur mandataire. La passerelle empêchera les utilisateurs d'avoir un contact avec l'extérieur, à moins qu'ils n'utilisent le mandataire.

Vous pouvez aussi le faire de façon transparente en utilisant iptables pour renvoyer tout le trafic vers le mandataire Squid. Il suffit pour cela d'ajouter des règles de pré-routage/« forward » sur la passerelle :

# iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to proxyhost:3128
# iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to proxyhost:3128

12.g. Conclusion de cette leçon

Nous avons appris ce qui suit :

1. Qu'un pare-feu peut représenter un risque s'il est mal configuré et qu'il vaut mieux, dans ce cas, n'en avoir aucun.
2. Comment paramétrer un serveur mandataire transparent et une passerelle de base.
3. Que la clé d'un bon pare-feu est de connaître le protocole que vous voulez autoriser.
4. Que le trafic IP ne contient pas que des données anodines. Des paquets ICMP peuvent révéler des informations importantes sur le réseau.
5. Comment éviter des attaques SYN.
6. Comment filtrer le trafic HTTP en retirant le chargement d'images ou de virus.
7. Que la combinaison pare-feu/serveur mandataire donne le meilleur contrôle.

Si vous en avez vraiment besoin, vous pouvez à présent créer un pare-feu qui répondra à vos besoins.

13. Détection d'intrusion

13.a. AIDE (Advanced Intrusion Detection Environment)

AIDE est un système de détection d'intrusion (« Host-Based Intrusion Detection System » (HIDS)) qui s'installe sur la machine à protéger. C'est une alternative gratuite à Tripwire. (Si vous connaissez déjà Tripwire, vous n'aurez aucune difficulté à configurer AIDE.) Les HIDS sont utilisés pour détecter des changements dans les fichiers importants du système (programmes binaires et fichiers de configuration), habituellement par calcul d'une somme de vérification cryptographique unique pour chaque fichier. Les sommes de vérification sont conservées dans un endroit sûr. Sur une base réguilière (par exemple une fois par jour), les sommes que l'on considère fiables sont comparées à celles générés à partir des fichiers présents à ce moment sur le système. On peut alors déterminer si des fichiers ont été modifiés. Les HIDS sont une excellente méthode de détection des changements non autorisés qui peuvent avoir lieu sur votre système. Leur mise en œuvre et leur utilisation nécessite toutefois quelques efforts.

Le fichier de configuration est basé sur des expressions rationnelles, des macros et des règles concernant les fichiers et répertoires. Nous avons les macros suivantes :

Ces macros deviennent très pratiques si vous avez plus d'une machine Gentoo et désirez utiliser AIDE sur chacune d'entre elles, bien que toutes les machines n'aient pas les mêmes utilisateurs ou services.

Nous devons ensuite vérifier les indicateurs sur les fichiers ou les répertoires. Ils sont formés d'une combinaison de permissions, de propriétés de fichiers et de sommes de vérification.

Et, si AIDE est compilé avec le support mhash, vous disposerez également de :

Vous pouvez à présent créer vos propres règles en combinant les indicateurs de cette façon :

All=R+a+sha1+rmd160
Norm=s+n+b+md5+sha1+rmd160

La dernière chose dont nous avons besoin pour créer notre propre fichier de configuration est de comprendre comment ajouter une règle à un fichiers ou un répertoire. Pour ce faire, combinez le nom du fichier ou du répertoire et celui de la règle. AIDE ajoutera les fichiers récursivement à moins que vous ne précisiez une règle différente.

Regardons à présent l'exemple complet :

@@ifndef TOP DIR
@@define TOPDIR /
@@endif

@@ifndef AIDEDIR
@@define AIDEDIR /etc/aide
@@endif

@@ifhost smbserv
@@define smbactive
@@endif

# L'endroit où lire la base de données.
database=file:@@{AIDEDIR}/aide.db

# L'endroit où inscrire la base de données.
database_out=file:aide.db.new

verbose=20
report_url=stdout

# Définition des règles
All=R+a+sha1+rmd160
Norm=s+n+b+md5+sha1+rmd160

@@{TOPDIR} Norm
!@@{TOPDIR}etc/aide
!@@{TOPDIR}dev
!@@{TOPDIR}media
!@@{TOPDIR}mnt
!@@{TOPDIR}proc
!@@{TOPDIR}root
!@@{TOPDIR}sys
!@@{TOPDIR}tmp
!@@{TOPDIR}var/log
!@@{TOPDIR}var/run
!@@{TOPDIR}usr/portage
@@ifdef smbactive
!@@{TOPDIR}etc/smb/private/secrets.tdb
@@endif
=@@{TOPDIR}home Norm

Dans l'exemple ci-dessus, nous spécifions avec quelques macros l'emplacement des répertoires racines et du répertoire de AIDE. AIDE consulte /etc/aide/aide.db lorsqu'il vérifie l'intégrité d'un fichier. Toutefois, lors de la mise à jour ou de la création d'un fichier, l'information est conservée dans /etc/aide/aide.db.new. Cela permet d'éviter d'écraser automatiquement le fichier de la base de données précédente. L'option report_URL n'est pas encore implémentée, mais l'intention de l'auteur était de permettre l'envoi d'un courriel ou l'exécution de scripts.

L'ebuild de AIDE contient une configuration par défaut, un script d'aide à la configuration et un script crontab. Le script d'aide à la configuration contient une interface plus facile à utiliser. Pour afficher les options, exécutez aide --help. Pour démarrer, il suffit de lancer aide -i et le script crontab devrait détecter la base de données et envoyer des courriels chaque jour. Il est recommandé de vérifier le contenu du fichier /etc/aide/aide.conf pour vous assurer qu'il correspond à votre système.

Il existe des risques inhérents à l'utilisation d'une base de données locale. Si un attaquant sait qu'AIDE est installé, il essaiera de corrompre la base ou de modifier /usr/bin/aide. Vous devriez donc utiliser un CD (ou un autre média) pour y copier le fichier .db ainsi que les fichiers binaires d'AIDE.

Pour plus d'informations, consultez la page du projet AIDE.

13.b. Snort

Snort est un système de détection d'intrusion sur le réseau. Pour l'installer et le configurer, utilisez les exemples suivants.

PID FILE=/var/run/snort_eth0.pid
MODE="full"
NETWORK="10.0.0.0/24"
LOG DIR="/var/log/snort"
CO NF=/etc/snort/snort.Cong
SNORT_OPTS="-D -s -u snort -dev -l $LOGDIR -h $NETWORK -c $CONF"

(Étape 1)
var HOME_NET 10.0.0.0/24
var EXTERNAL_NET any
var SMTP $HOME_NET
var HTTP_SERVERS $HOME_NET
var SQL_SERVERS $HOME_NET
var DNS_SERVERS [10.0.0.2/32,212.242.40.51/32]
var RULE_PATH ./

(Étape 2)
preprocessor frag2
preprocessor stream4: detect_scans detect_state_problems detect_scans disable_evasion_alerts
preprocessor stream4_reassemble: ports all
preprocessor http_decode: 80 8080 unicode iis_alt_unicode double_encode iis_flip_slash full_whitespace
preprocessor rpc_decode: 111 32771
preprocessor bo: -nobrute
preprocessor telnet_decode

(Étape 3)
include classification.config

(Étape 4)
include $RULE_PATH/bad-traffic.rules
include $RULE_PATH/exploit.rules
include $RULE_PATH/scan.rules
include $RULE_PATH/finger.rules
include $RULE_PATH/ftp.rules
include $RULE_PATH/telnet.rules
include $RULE_PATH/smtp.rules
include $RULE_PATH/rpc.rules
include $RULE_PATH/rservices.rules
include $RULE_PATH/dos.rules
include $RULE_PATH/ddos.rules
include $RULE_PATH/dns.rules
include $RULE_PATH/tftp.rules
include $RULE_PATH/web-cgi.rules
include $RULE_PATH/web-coldfusion.rules
include $RULE_PATH/web-iis.rules
include $RULE_PATH/web-frontpage.rules
include $RULE_PATH/web-misc.rules
include $RULE_PATH/web-attacks.rules
include $RULE_PATH/sql.rules
include $RULE_PATH/x11.rules
include $RULE_PATH/icmp.rules
include $RULE_PATH/netbios.rules
include $RULE_PATH/misc.rules
include $RULE_PATH/attack-responses.rules
include $RULE_PATH/backdoor.rules
include $RULE_PATH/shellcode.rules
include $RULE_PATH/policy.rules
include $RULE_PATH/porn.rules
include $RULE_PATH/info.rules
include $RULE_PATH/icmp-info.rules
include $RULE_PATH/virus.rules
# include $RULE_PATH/experimental.rules
include $RULE_PATH/local.rules

config classification: not-suspicious,Not Suspicious Traffic,3
config classification: unknown,Unknown Traffic,3
config classification: bad-unknown,Potentially Bad Traffic, 2
config classification: attempted-recon,Attempted Information Leak,2
config classification: successful-recon-limited,Information Leak,2
config classification: successful-recon-largescale,Large Scale Information Leak,2
config classification: attempted-dos,Attempted Denial of Service,2
config classification: successful-dos,Denial of Service,2
config classification: attempted-user,Attempted User Privilege Gain,1
config classification: unsuccessful-user,Unsuccessful User Privilege Gain,1
config classification: successful-user,Successful User Privilege Gain,1
config classification: attempted-admin,Attempted Administrator Privilege Gain,1
config classification: successful-admin,Successful Administrator Privilege Gain,1

# NOUVELLES CLASSIFICATIONS
config classification: rpc-portmap-decode,Decode of an RPC Query,2
config classification: shellcode-detect,Executable code was detected,1
config classification: string-detect,A suspicious string was detected,3
config classification: suspicious-filename-detect,A suspicious filename was detected,2
config classification: suspicious-login,An attempted login using a suspicious username was detected,2
config classification: system-call-detect,A system call was detected,2
config classification: tcp-connection,A TCP connection was detected,4
config classification: trojan-activity,A Network Trojan was detected, 1
config classification: unusual-client-port-connection,A client was using an unusual port,2
config classification: network-scan,Detection of a Network Scan,3
config classification: denial-of-service,Detection of a Denial of Service Attack,2
config classification: non-standard-protocol,Detection of a non-standard protocol or event,2
config classification: protocol-command-decode,Generic Protocol Command Decode,3
config classification: web-application-activity,access to a potentially vulnerable web application,2
config classification: web-application-attack,Web Application Attack,1
config classification: misc-activity,Misc activity,3
config classification: misc-attack,Misc Attack,2
config classification: icmp-event,Generic ICMP event,3
config classification: kickass-porn,SCORE! Get the lotion!,1

Pour plus d'informations, consultez le site de Snort.

13.c. Détecter les logiciels malfaisants avec chkrootkit

Les HIDS tels que AIDE sont d'excellents outils pour détecter les changements apportés à votre système, mais disposer d'une ligne de défense supplémentaire ne peut pas vous nuire. chkrootkit est un utilitaire servant à scanner les fichiers système classiques pour y repérer des « rootkits » (des logiciels conçus pour dissimuler les actions d'un intrus et lui permettre de conserver son accès). chkrootkit scanne aussi votre système pour y repérer des logiciels malfaisants, par exemple des programmes servant à espionner vos entrées clavier. Bien que chkrootkit et ses alternatives (tel que rkhunter) soient des outils précieux à la fois pour la maintenance d'un système et pour le repérage des intrus après une attaque, ils ne peuvent garantir la sécurité de votre système.

La meilleure façon d'utiliser chkrootkit pour détecter une intrusion est de l'exécuter régulièrement à partir de cron. Tout d'abord, exécutez app-forensics/chkrootkit. chkrootkit peut être exécuté en tapant la commande du même nom, ou à partir de cron grâce à une entrée comme celle qui suit :

0 3 * * * /usr/sbin/chkrootkit

14. Rester à jour

14.a. Rester à jour

Une fois votre système installé, configuré et protégé, votre tâche est loin d'être terminée. Sécuriser un système est un travail constant ; la vaste majorité des intrusions résultent de l'exploitation de failles connues présentes dans des systèmes où les correctifs appropriés n'ont pas été appliqués. Garder votre système à jour est ce qu'il y a de plus important pour assurer un niveau de sécurité élevé.

Avec une version récente de Portage, vous pouvez synchroniser votre arbre Portage avec la commande emerge --sync et ensuite lancer glsa-check --list pour vérifier si votre système est à jour en ce qui concerne la sécurité. L'outil glsa-check fait partie du paquet app-portage/gentoolkit.

# glsa-check -l
WARNING: This tool is completely new and not very tested, so it should not be
used on production systems. It's mainly a test tool for the new GLSA release
and distribution system, it's functionality will later be merged into emerge
and equery.
Please read http://www.gentoo.org/proj/en/portage/glsa-integration.xml
before using this tool AND before reporting a bug.

[A] means this GLSA was already applied,
[U] means the system is not affected and
[N] indicates that the system might be affected.

200406-03 [N] sitecopy: Multiple vulnerabilities in included libneon ( net-misc/sitecopy )
200406-04 [U] Mailman: Member password disclosure vulnerability ( net-mail/mailman )
.......

Les lignes qui commencent par [A] ou [U] peuvent être ignorées sans risque, car le système n'est pas concerné par ces failles.

(Pour vérifier si votre système est affecté par des GLSA :)
# glsa-check -t all
WARNING: This tool is completely new and not very tested, so it should not be
used on production systems. It's mainly a test tool for the new GLSA release
and distribution system, it's functionality will later be merged into emerge
and equery.
Please read http://www.gentoo.org/proj/en/portage/glsa-integration.xml
before using this tool AND before reporting a bug.

This system is affected by the following GLSA:
200504-06
200510-08
200506-14
200501-35
200508-12
200507-16

(Voir quels paquets vont être installés :)
# glsa-check -p $(glsa-check -t all)
     (partial output)
Checking GLSA 200504-06
The following updates will be performed for this GLSA:
     app-arch/sharutils-4.2.1-r11 (4.2.1-r10)

     **********************************************************************

     Checking GLSA 200510-08
     The following updates will be performed for this GLSA:
          media-libs/xine-lib-1.1.0-r5 (1.1.0-r4)

(Appliquer les correctifs :)
# glsa-check -f $(glsa-check -t all)

Si vous avez mis à jour un service en cours d'utilisation, n'oubliez pas de le redémarrer.

Maintenir votre noyau à jour est également recommandé.

Si vous désirez recevoir un courriel à chaque annonce GLSA, inscrivez-vous à la liste de diffusion gentoo-announce. Les instructions pour vous y inscrire se trouvent sur notre page des listes de diffusion (en anglais). Vous y trouverez aussi d'autres listes très intéressantes.

Une autre source d'informations précieuses sur la sécurité est la liste de diffusion Bugtraq (en anglais).

Ce document est protégé par la licence Creative Commons : Paternité - Partage des Conditions Initiales à l'Identique 2.5.