10.7. Sécurité du noyau

10.7.1. Options de compilation du noyau

Lorsque ce document a été écrit, le noyau 2.2 était le nec plus ultra. Encore aujourd'hui, la plupart des pare-feu l'utilise encore. Toutefois, avec le noyau 2.4, beaucoup de choses ont changé. La plupart des options de compilation contenues dans ce chapitre sont encore valides, mais le masquage et le transfert de port ont été remplacés par les tables IP. Vous obtiendrez de plus amples renseignements en visitant le Linux iptables HOWTO.

Pour les noyaux 2.2.x, les options suivantes s'appliquent. Vous devriez voir ces options pendant le processus de configuration du noyau. La plupart des commentaires sont issus depuis /usr/src/linux/Documentation/Configure.help, soit le même document utilisé dans l'aide en ligne pendant l'étape make config de la compilation du noyau. Consultez le chapitre Compilation et mise en place de nouveaux noyaux du Manuel de référence pour obtenir une description du processus de compilation d'un nouveau noyau.

• Pare-feu réseau (CONFIG_FIREWALL)

  Cette option devrait être activée si vous envisagez de faire du pare-feu (firewalling) ou du masquage IP (masquerading) sur votre machine GNU/Linux. Si vous ne configurez qu'une simple machine cliente, il est plus sûr de répondre non.

• IP: reroutage/passerelle (CONFIG_IP_FORWARD)

  Si vous activez le reroutage IP (IP forwarding); votre machine devient essentiellement un routeur. Si votre machine est sur un réseau, vous pourriez réexpédier des données d'un réseau à un autre, et même subvertir un pare-feu qui était la justement pour empêcher cela. Les utilisateurs normaux en connexion par modem devraient désactiver cette option, et les autres se focaliser sur les implications au niveau de la sécurité d'une telle décision. Les machines pare-feu devront activer cela, en conjonction avec un logiciel de pare-feu.

  Vous pouvez activer le reroutage IP en utilisant la commande :

  root# echo 1 > /proc/sys/net/ipv4/ip_forward

  et le désactiver avec la commande :

  root# echo 0 > /proc/sys/net/ipv4/ip_forward

• IP: cookies syn (CONFIG_SYN_COOKIES)

  Une « attaque SYN  » est une attaque du type dénis de service (DoS) qui consomme toutes les ressources de votre machine, vous forçant au redémarrage. Nous ne voyons pas de raisons pour ne pas activer cela. Pour activer cela, vous devez faire :

  root# echo 1 > /proc/sys/net/ipv4/tcp_syncookies <P>

• IP: Pare-feu (CONFIG_IP_FIREWALL)

  Cette option est nécessaire si vous envisagez de configurer votre machine comme pare-feu, faire du reroutage IP, ou souhaitez protéger votre station en connexion par modem de quelqu'un qui souhaiterais y pénétrer.

• IP: noter les paquets pare-feu (CONFIG_IP_FIREWALL_VERBOSE)

  Cette option vous donne des informations sur les paquets que votre pare-feu a reçu comme l'expéditeur, le destinataire, le port, etc.

• IP: Refuser les structures routées à la source (CONFIG_IP_NOSR)

  Ceci devrait être activé. Les structures routées à la source contiennent le chemin complet vers leur destination à l'intérieur du paquet. Cela signifie que les routeurs n'ont pas besoin de les vérifier et ne font que les réexpédier. Cela pourrait conduire à laisser entrer des données sur votre système qui pourraient représenter une possible violation.

• IP: masquage (CONFIG_IP_MASQUERADE)

  Si l'un des ordinateurs de votre réseau local, pour lequel votre machine GNU/Linux agit comme pare-feu, veut envoyer quelque chose à l'extérieur, votre machine peut « masquer  » cet hôte, i.e., elle réexpédie le trafic vers la destination mais le fait comme si il venait de lui-même. Consultez http://www.indyramp.com/masq et le chapitre Configurer des clients en mascarade pour plus d'information.

• IP: masquage ICMP (CONFIG_IP_MASQUERADE_ICMP)

  Cette option ajoute le masquage ICMP à l'option précédente qui ne masque que le trafic TCP ou UDP.

• IP: support de mandataire (proxy) transparent (CONFIG_IP_TRANSPARENT_PROXY)

  Cela autorise votre pare-feu GNU/Linux à rediriger de manière transparente tout le trafic réseau provenant du réseau local destiné à un hôte distant depuis un serveur local, appelé « serveur proxy transparent  ». Cela fait croire aux ordinateurs locaux qu'ils communiquent avec l'hôte distant, alors qu'ils sont connectés au proxy local. Consultez le chapitre HOWTO IP-Masquerading et le site Web de Indyramp pour plus de renseignements.

• IP: défragmenter toujours (CONFIG_IP_ALWAYS_DEFRAG)

  Cette option est normalement désactivée, mais si vous construisez un pare-feu, ou un hôte de masquage, vous devrez l'activer. Lorsque des données sont envoyées d'un hôte à un autre, elles ne sont pas toujours envoyées comme un seul paquet de données, mais plutôt fragmentées en plusieurs morceaux. Le problème de cela est que les numéros de ports ne sont connus que du seul premier fragment. Cela signifie que quelqu'un pourrait insérer dans les paquets suivants, des informations erronées. Cela est aussi susceptible d'empêcher une attaque de type «  teardrop   » contre un serveur interne qui ne serait lui même pas immunisé contre cela.

• Signatures de paquets (CONFIG_NCPFS_PACKET_SIGNING)

  Cela est une option qui va signer les paquets NCP pour une sécurité accrue. Vous pouvez normalement la laisser désactivée, mais elle est là si vous en avez besoin.

• IP: Périphérique pare-feu de paquets netlink (CONFIG_IP_FIREWALL_NETLINK)

  Voilà une option bien pensée qui vous permets d'analyser les 128 premier octets des paquets dans un programme utilisateur, pour déterminer si vous souhaiter accepter ou refuser le paquet, selon sa validité.

• Filtrage de Socket (CONFIG_FILTER)

  Pour le plus grand nombre, il est bon de répondre non à cette option. Celle-ci vous permet de connecter un filtre utilisateur à n'importe quel Socket et choisir les paquets à accepter ou refuser. À moins que vous n'ayez un besoin très spécifique et que vous soyez capable de programmer un tel filtre, vous devriez dire non. Notez aussi que à l'heure d'écrire cette section, tous les protocoles sont supportés, sauf TCP.

• Redirection de port

  La redirection de port (Port Forwarding) est une extension du masquage IP qui autorise la redirection de paquets depuis l'intérieur d'un pare-feu sur des ports spécifiques. Cela peut être utile si, par exemple, vous voulez utiliser un serveur Web derrière le pare-feu ou hôte de masquage et ce serveur Web doit être accessible du monde externe. Un client externe envoie une requête au port 80 du pare-feu, le pare-feu fait suivre la requête au serveur Web, le serveur Web traite la requête et les résultats sont envoyés par le réseau au client original. Le client croit que c'est le pare-feu lui-même qui est le serveur Web. Cela peut aussi être utiliser pour répartir la charge si vous avez une « ferme  » de serveurs identiques en deçà du pare-feu. Toute l'information à propos de cette caractéristique est disponible à monmouth. Pour des informations générales, consulter compsoc

• Filtrage de ports Socket (CONFIG_FILTER)

  En utilisant cette option, un programme utilisateur peut affecter un filtre à chaque socket, et indiquer par là au noyau s'il peut accepter ou refuser à certains types de données de passer à travers le socket. Le filtrage de socket GNU/Linux marche sur tous les types de socket sauf les TCP pour l'instant. Consultez le fichier texte ./linux/Documentation/networking/filter.txt pour plus d'information.

• IP: Masquage

  Le masquage pour les noyaux 2.2 a été amélioré. Il propose des supports additionnels pour masquer des protocoles particuliers, etc. Assurez vous de lire le HOWTO ipchains pour plus d'information.

10.7.2. Périphériques noyau

Il y a plusieurs périphériques en mode bloc et caractère disponibles sous GNU/Linux qui vous aiderons aussi pour la sécurité.

Les deux fichiers /dev/random et /dev/urandom sont fournis par le noyau pour offrir des données aléatoires à tout instant.

Aussi bien /dev/random que /dev/urandom devraient être assez sûrs pour générer des clés PGP, des challenges ssh, et autres applications où des nombres aléatoires sont requis. Les attaquants devraient être incapable de prédire le nombre suivant, connaissant une séquence initiale de nombres provenant de ces sources. Beaucoup d'efforts ont étés consentis pour s'assurer que les nombres fournis par ces sources sont aléatoires, dans tous les sens du terme.

La seule différence entre ces deux périphériques, est que /dev/random s'épuise en octets aléatoires, et vous fait attendre jusqu'à ce que d'autres ce soient accumulés. Notez que sur certains systèmes, il peut se bloquer pendant un long moment, attendant que de la nouvelle entropie, générée par l'utilisateur entre dans le système. Vous devez donc faire attention avant d'utiliser /dev/random. (La meilleure chose à faire est sans doute de l'utiliser lorsque vous générez des informations de clés sensibles, et vous demandez à l'utilisateur d'utiliser le clavier intensément.)

/dev/random est de haute qualité entropique, généré en mesurant les temps inter-interruptions, etc. Il se bloquera jusqu'à ce que suffisamment de bits aléatoires aient été générés.

/dev/urandom est semblable, mais lorsque la réserve d'entropie baisse, il retournera un mélange cryptographiquement élevé de ce qu'il reste. Ce n'est pas aussi sûr, mais cela suffit pour la plupart des applications.

Vous pouvez lire depuis ces périphériques en utilisant quelque chose comme :

root# head -c 6 /dev/urandom | mimencode

Cela imprimera six caractères aléatoires à la console, convenables pour un mot de passe. Vous pourrez trouver mimencode dans le paquetage metamail.

Consultez /usr/src/linux/drivers/char/random.c pour une description de l'algorithme.