Et voilà encore un article sur la création d'un serveur sous GNU/Linux publié sur le site de Giroll. Au menu cette fois ci, comment manipuler le pare-feux intégré au noyau Linux grâce a la célèbre commande iptables. Merci a Bast qui a rendu cet article bien plus lisible (et corrigé pas mal de fautes), et à Tyzef qui relit chacun de mes articles pour y faire des corrections...

Vous pouvez voir l'article ici, n'hésitez pas a laisser vos questions / remarques / commentaires ...

Vous trouverez sur le site de Giroll à cet endroit mon nouvel article sur la configuration d'un serveur / routeur sous GNU/Linux. Cet article aborde les éléments théoriques qui nous permettrons de mettre en place un pare-feu, j'y aborde notamment les notions d'IP, de ports réseau, le protocole... Le tout agrémenté de schémas.

Dans le cadre de mon travail, je gère plusieurs salles informatique ouvertes au public. Ces salles sont évidemment reliées à Internet. Pour le bon fonctionnement de ces lieux, j'ai mis en place de petits serveurs GNU/Linux. Voici comme première approche ci le schéma de fonctionnements de ces diverses installations :

Le matériel

Je n'utilise pour ces serveurs que des machines de récupération : celles que l'on ne peux même plus affecter à autre chose : Pentium III 500, 64 voire 128 Mo de RAM, carte graphique TNT2 / Ati rage pro, un disque dur d'au moins 10 Go et deux cartes réseaux : l'une pour recevoir la connection Internet et l'autre pour la partager. Dans la mesure du possible, j'essaye d'y adjoindre un second disque dur (pour le répertoire /var/).

Les logiciels

J'utilise une Debian 4, parce que c'est la distribution que je connais le mieux (grâce à Ubuntu...). Je l'installe sans l'interface graphique : elle n'est pas utilise ici, on économise de la place et des ressources. Une fois installée, je n'ai plus qu'a rajouter les paquets qui m'intéresse grâce a la fameuse commande apt-get :

• dhcp3-serveur : un serveur dchp, il permet d'attribuer automatiquement des adresses IP au machines qui se connecte à notre réseau. C'est une fonctionnalité que l'on trouve maintenant dans tout les routeurs domestiques, mais ici, il est beaucoup plus complet comme par exemple l'attribution d'IP en fonction de l'adresse matérielle de la carte réseau du client.

• openssh-server : un serveur SSH (Secure SHell) il permet entre autre d'accéder a la machine et de l'administrer via le réseau (et Internet). De cette manière, je peux dans 80% des cas la dépanner depuis n'importe ou, du moment que j'ai accès à Internet. Vous trouverez plus d'information sur wikipédia.

• squid : Un serveur proxy, sa fonction est simple : aller chercher les pages internet à la place des machines clientes. Il va stocker dans son "cache" ces pages pour éventuellement les charger plus vite lorsqu'elle seront demandées une prochaine fois.

• squidGuard : un redirecteur pour squid. Il filtre tout ce qui passe par le proxy pour empêcher les clients d'accéder à certains contenus. Je l'utilise surtout pour bloquer les sites pornographiques, souvent très intrusifs sur les machines du parc (pubs osées au démarrage par exemple) et c'est quasiment obligatoire pour la protection des mineurs (public le plus présent dans ces salles).

La mise en place

J'utilise les mêmes fichiers de configurations fait une fois pour toute. Pour des question de sécurité, j'utilise l'identification par clé partagée pour l'accès ssh au serveur, évitant ainsi les attaques de type force brute et dictionnaire.

Pour protéger le serveur, activer le partage de connection internet, et obliger les machines du parc a utiliser le serveur proxy, j'utilise iptables (plus d'information sur wikipédia) pour configurer le pare feu intégré au noyau Linux. C'est sûrement la partie la plus délicate à configurer, elle nécessite quelques notions réseaux avancés. J'initialise le pare-feux grâce a des scripts bash au démarrage.

La mise à jour des bases de données de squidGuard se fait automatiquement grâce à un autre script lancé toute les semaines automatiquement grâce à cron : (voir wikipédia). Les base de données à jours peuvent se trouver sur le site de l'université de Toulouse.

Pour finir

Avec un peu d'expérience, la mise en place d'un tel serveur ne prend pas plus d'une demi-journée. Le plus ancien de mes serveurs fonctionne depuis 2 ans 24h/24 sans soucis majeurs. Avec quelques tutoriaux glanés ci et là, la configuration de celui-ci ne devrait pas poser de problème. Pour ceux qui le désirent, je peux bien entendu partager avec vous mes fichiers de configuration.

Quelques sites/tutoriaux

squid et suidGuard sur le site de l'université de Toulouse.
Le site de Christian Caleca : des tonnes d'explications sur le réseau : DHCP, Squid, SquidGuard ... Le meilleur site du genre.
Le site du collectif Giroll : Quelques tutoriaux réseaux de mon cru.
Le ssh par Coagul. (Groupe d'utilisateur de linux de la côte d'Or).

Proftpd est uns serveur FTP pour GNU/Linux que j'ai choisi d'installer sur mon petit serveur Debian. Ce serveur me permet de partager certains documents (photos, vidéos personnelles ...) via internet et au port via un réseau local wifi. Le serveur n'a pas directement accès à internet, il est placé derrière un routeur et fait parti de la zone démilitarisée^[1].

Ce type de configuration pose un problème majeur : pour ne pas engorger ma connection internet, je suis obligé de limiter le débit de données entrant et sortant de mon serveur FTP, limitation qui affectera aussi les machines dans le réseau local. Mais j'ai trouvé un moyen de satisfaire tout le monde grâce à une petite astuce dans mon fichier de configuration de proftpd.

<class inet>
From 192.168.1.1
</class>
...
TransferRate RETR,APPE,STOR 60 class inet
...

Petite explication de texte : nous déclarons une classe que l'on appelle inet, cette classe porte sur les informations venant du routeur (192.168.1.1). Pourquoi le routeur? Parce que tout ce qui vient d'internet aura comme source notre routeur vu de notre serveur. Nous définissons ensuite une close TransferRate (limite de notre bande passante) pour les actions RETR, APPE, STOR (Lire et Ecrire sur notre serveur) à 60Ko maximum pour notre classe inet. Le tour est joué...

Pour aller un peu plus loin : pour ne pas mettre à genoux notre serveur lors de transfert sur le réseau local, nous pouvons rajouter une close TransferRate avec comme classe !inet (qui signifie tout sauf inet). La configuration ressemblera alors à ceci :

<class inet>
From 192.168.1.1
</class>
...
TransferRate RETR,APPE,STOR 60 class inet
TransferRate RETR,APPE,STOR 1024 class !inet
...

Les transferts sur le réseau local depuis et vers notre serveur ne pourront alors excéder 1024 Ko/s alors que depuis Internet la limite sera de 60 Ko/s. Voilà maintenant nos limites de transfert réglées aux petits oignons...

Voici enfin la suite de mon précédent article sur le sh publié sur ma Giroll préférée. Cette fois ci, j'aborde les notions de condition, de boucle et j'explique comment lancer des programmes depuis ce fabuleux langage de script. Ces deux articles servirons de base pour le suivant : créer un pare-feu (firewall) personnalisé sur notre serveur Debian.

Pour voir l'article sur la Giroll, cliquez ici.

Après un petit tutoriel concernant la transformation d'un serveur Debian en passerelle, voici la première partie d'un tutoriel sur l'utilisation du langage de script sh. C'est pour l'instant juste une approche, au menu : définition, utilisation des variables et des paramètres. Dans la prochaine partie, nous aborderons les structures de contrôles (conditions, boucles ...) et l'utilisation du script pour lancer des programme externe.

Vous trouverez ce tutoriel sur ma GIROLL préférée à cette adresse.

Vous pouvez trouver sur le site du collectif Gironde Logiciel Libre (Giroll) mon second article dédié à la création d'un serveur réseau à l'aide de GNU/Linux. Cet article explique comment transformer son serveur en routeur. Vous le trouverez à cette adresse, n'hésitez pas à me dire ce que vous en pensez...