Savoir ce qui est installé.

La première règle est bien entendu de savoir exactement quels sont les services installés sur sa machine et de n'y laisser que ce qui est strictement nécessaire. Cette méthode, surtout dans le cas d'un réseau local connecté à l'Internet par une passerelle est toutefois assez pénalisante. On peut souhaiter disposer de quelques services sur l'hôte qui sert de passerelle.

Bien entendu, la solution la plus sûre consiste à installer une passerelle qui ne fera que son travail de passerelle et de firewall et d'installer par ailleurs sur le réseau privé un serveur pour les divers services souhaités. Ca augmente tout de même le nombre de machines et la facture EDF. Ca ne résoudra pas non plus certains problèmes pour les entreprises qui souhaitent accéder à certaines de leurs ressources depuis l'extérieur, mais le cas de figure dépasse largement le propos de cet exposé.

Construire une barrière.

Etat des lieux.

Une solution de protection consiste à interdire l'accès aux ports inutiles côté Internet. Sur Linux Mandrake 7.x (plus généralement avec un noyau 2.2.x bien compilé), ceci peut se faire avec IPChains. Les noyaux 2.4.x, bien que supportant IPChains, gagneront à exploiter plutôt IPTables, nettement plus évolué. IPChains reste tout de même plus répandu pour l'instant.

Pour fixer les esprits, donnons un exemple.

Soit une machine Linux servant de passerelle sur l'Internet. Comme on aime bien jouer avec les diverses applications fournies, on y a installé:

Et comme on ne veut pas s'embêter, la règle par défaut sur INPUT est ACCEPT.

Croyez-vous que ce soit prudent? Pas du tout bien entendu. Sur une machine exposée à l'Internet, moins on installe de serveurs, mieux ça vaut. Examinons ce que verrait un pirate qui ferait un "scan" de cette machine avec l'un des meilleurs outils dans le genre: nmap (inclus dans les distributions Mandrake ).

Démonstration:

Telnet, c'est intéressant:

Voilà, une Mandrake 7.1 avec un kernel 2.2.16-9 et la machine s'appelle gateway2.maison.mrs. Ca c'est intéressant. Allons faire un tour sur le DNS du monsieur...

Et hop! On sait tout du réseau de ce monsieur :-) (Même, si vous avez bien suivi, que ce monsieur dispose sans doute d'une seconde machine du même genre qui s'appelle gateway1)

Il faut dire que c'est quand même très mal, de laisser libre le transfert de zone sur un DNS. Mais j'ai trouvé cette gravissime lacune sur des sites très "officiels".

Reprenons le scénario, mais avec BIND correctement configuré. Ca donne ceci:

C'est déjà mieux, au moins le DNS ne répond plus  aux requêtes venant de l'Internet. Comment il faut faire? Dans /etc/named.conf, il faut utiliser les directives "allow-transfert", "allow-query" et même "listen-on" (cf. la doc. de BIND)

Cet exemple est juste donné pour bien montrer que la sécurité passe d'abord par une configuration correcte des serveurs installés...

Mais continuons l'investigation. Voyons le serveur FTP, un petit coup de telnet sur le port 21:

Oui, c'est bien un wu-ftp, version 2.6.0. Faudra voir ce qu'il y a comme "exploits" là dessus. On va s'arrêter là, mais il y a pas mal d'investigations à faire sur un serveur FTP

Allez, encore un telnet sur le port 25

C'est bien Postfix. (Là aussi, il y aurait encore beaucoup à faire).

Convaincu? en très peu de temps, le pirate accumule une quantité intéressante d'informations sur votre équipement, autant d'informations qu'il pourra exploiter pour essayer de "casser" votre matériel.

Comme l'objectif de cet exposé n'est pas de faire un cours sur l'intrusion (encore que ce soit le meilleur moyen pour apprendre à mettre en place des parades), on va s'arrêter là.

La situation exposée est d'autant plus absurde, qu'avec IPChains, on peut déjà compliquer passablement le travail du pirate.

Que les utilisateurs de Windows n'abandonnent pas la lecture de ce qui suit. La démonstration se fait avec IPChains, mais le principe reste vrai quel que soit l'OS. Nous verrons plus loin les solutions proposées aux utilisateurs de produits Microsoft.

Construction de barrières.

Nous allons exploiter un peu la chaîne INPUT

Traduit en français, ça veut dire que l'on jette sans avertissement (DENY)  les paquets qui viennent de n'importe où (0.0.0.0/0.0.0.0) pour aller n'importe où, s'ils ont le malheur de rentrer par eth0 sur les ports 21, 23, 25, 110, 111, 139, 143 et de 6000 à 6009 et refaisons un scan:

nmap ne s'y trompe pas, il constate qu'il y a des règles de filtrage sur cette machine et essaye de trouver les ports non filtrés. Il va en trouver beaucoup, mais ça ne veut pas dire qu'ils sont ouverts. Ceux qu'il trouve ouverts sont ceux que l'on n'a pas filtré.

Il est clair que l'on a déjà limité les problèmes. Mais on pourrait encore faire mieux en plaçant un DENY par défaut sur INPUT depuis eth0, puis en n'autorisant que les ports utiles pour la fonction de passerelle, mais cette méthode nécessite une mise au point minutieuse parce que l'on risque d'aboutir à tout moment à des disfonctionnements inattendus qu'il faudra alors régler au cas par cas.

Conclusion.

Ce type de protection passive offre déjà un bon niveau de sécurité, si l'on a convenablement analysé la configuration de sa machine et placé les bonnes règles. Il y aurait encore à faire sur cette machine, car si l'on a à peu près filtré les ports TCP, qui sont les plus dangereux parce qu'ils permettent un mode connecté, on n'a encore rien fait ni sur UDP, ni sur ICMP. Ces deux protocoles peuvent cependant créer des nuisances parce qu'ils peuvent être utilisés pour bloquer la machine.

Notez qu'il existe un site qui permet de construire des règles IPChains en fonction de critères de protection que l'on choisit dans des tables

http://www.linux-firewall-tools.com/linux/firewall/index.html

Mais il est possible d'aller encore plus loin dans le domaine de la protection. En effet, nous faisons ici de la protection "passive". Les ports sensibles sont verrouillés, nous pourrions encore ajouter quelques règles pour par exemple refuser les PINGS. Cependant, il est intéressant de placer en plus quelques systèmes qui vont épier le trafic et prévenir, voire réagir,  en cas d'activité suspecte  avec  les "loggers" et.les firewalls actifs.

IPChains sait déjà "logger" les événements qui satisfont aux critères des chaînes, mais il est peut-être plus intéressant d'utiliser des outils spécifiques.