Dans le précédent chapitre, nous avons réussi à fermer tous les ports de notre machine, mais est-ce à cela que se résume la sécurité en informatique ? Même si ce point est très important, il reste insuffisant. Pourquoi ?
- Le ping : A aucun moment nous n'avons vu comment interdire à notre machine de répondre aux commandes de type "ping" ou "traceroute". En effet, ce n'est pas un serveur qui est responsable de répondre à ce type de sollicitation, mais le kernel lui-même via la couche IP. On peut donc à tout moment savoir que votre machine est allumée, ou effondrer son CPU sous une attaque DOS / DDOS.
- Ports fermés : Dans de rares cas, et bien que vos ports soient fermés, l'intrus peut soupçonner la présence de "quelque chose" derrière l'un de vos ports. J'en ai fait l'expérience il y a un bout de temps, lorsque j'ai voulu faire tester en ligne la sécurité de ma machine par le site http://www.pcflank.com/ . J'ignore comment ce serveur a fait, mais il a réussi à trouver pour l'un ou l'autre de mes serveurs une trace d'activité. Et donc il a indiqué qu'il y avait probablement "quelque chose" derrière ce port, ce en quoi il avait raison. Mais avec les informations que vous trouverez dans ce chapitre, c'est le genre de chose qui n'arrivera plus !
- L'IP spoofing : Dans les différents paramétrages que nous avons vu précédemment, nous avons configuré les serveurs pour qu'ils ne fassent confiance qu'à certaines adresses IP sources. Oui, mais que se passe t'il si l'intrus ment délibérément sur son adresse IP source, et envoie une demande de connexion semblant venir de votre propre réseau local ? C'est tout à fait faisable, et c'est ce que l'on appelle l'IP spoofing... Cette technique a un inconvénient, c'est que l'intrus ne pourra pas recevoir les réponses de la machine cible (car celle-ci renverra l'information là où elle semble venir, c'est à dire sur le réseau local). Mais il n'empêche que cela peut suffit au pirate à envoyer des paquets d'informations qui peuvent corrompre le serveur, via la technique du "buffer overflow" ("Dépassement de tampon" en français). Internet fourmille d'exemples réussis de ce type d'attaque, et seul une mise à jour régulière de ses logiciels serveur peut réussir à les stopper.
En fait, ce qui ne va pas avec le système de sécurité que nous avons vu jusqu'à présent, c'est que :
- Nous n'avons aucun contrôle sur l'origine précise des requêtes IP. Nos serveurs ne peuvent en général pas savoir si une trame IP arrive ou part d'une interface où d'une autre.
- Nous ne pouvons pas empêcher notre machine de répondre à certaines requêtes.
- Nous aimerions avoir une trace des activités réseaux suspectes de notre machine, et donner l'alerte le cas échéant.
Tous ces points trouvent leur solution avec un seul mot : Netfilter, le firewall du kernel Linux 2.4 et supérieur.
Netfilter est le nom d'une partie du kernel Linux qui est destinée à assurer la surveillance de tous les transferts de données réseaux. Sa tache est de faire du "Network Packet Filtering", c'est à dire du "Filtrage de Paquets Réseaux". Grosso modo, il se place entre la couche réseau du kernel Linux, et la couche applicative (c'est plus compliqué que cela en faite, mais pour les besoins de ce document, cette approximation n'est pas fausse  ). Netfilter supporte actuellement les protocoles IPv4, IPv6, DECnet, et ARP, et en partie IPX via des patchs expérimentaux. Nous ne nous intéresserons ici qu'à IPv4.
Comme Netfilter est un élément implanté profondément dans le kernel Linux (le "kernel space", ou "l'espace du coeur" en français), on ne peut pas le configurer aussi simplement qu'avec un jolie interface graphique doté de pleins de couleurs. On ne peut pas non plus le paramétrer directement via un fichier de configuration du "/etc/". Non, l'unique moyen que nous ayons de dialoguer avec lui est un programme appelé "iptables", que l'on lance dans le "user space" ("espace utilisateur" en français) avec les droits root. Nous verrons par la suite qu'il existe un certain nombre d'autres applications, graphiques ou non, qui servent d'interface à "iptables".
Enfin, et au risque de me répéter, Netfilter / Iptables ne sont que des éléments fonctionnant avec un kernel Linux 2.4 et supérieur. Si vous utilisez un kernel Linux de type 2.2 ou inférieur, vous devez utiliser une applications appelée "ipchains". Mais cela sort malheureusement du cadre de cette documentation. Linux évolue très vite, et ses outils aussi. Pour moi, le seul fait que les kernels 2.4 et supérieurs supportent le suivi de connexion justifient totalement leur utilisation.
Donc pour les utilisateurs du kernel 2.2 ou moins, mettez à jour votre kernel si vous voulez exploiter le contenu de ce chapitre. Mais la mise à jour du kernel Linux est une opération lourde. Je ne suis donc absolument pas responsable des conséquences qui pourraient en découdre !
|
