Avertissement
Ce guide est reservé aux personnes ayant un bon niveau dans l'administration des serveurs dédiés sous Linux. La manipulation d'un firewall peut être dangereuse. En effet, vous pouvez bloquer votre serveur ce qui vous forcera à le redémarrer en HARD. Si vous vous trompez dans le script final et que vous le mettez en auto démarrage, vous n'aurez plus accés à votre machine ! Faites donc très attention et si vous ne vous sentez pas à l'aise avec ce guide, ne paramétrez pas votre firewall !

Un firewall c'est quoi ?
C'est un programme qui va bloquer certains ports de votre machine et en ouvrir d'autre. Imaginez votre maison : vous avez une porte à l'avant et une porte à l'arrière. Celle à l'arrière ne vous sert jamais, autant la condamner. Pourquoi ? Parce que c'est un risque potentiel d'intrusion pour un voleur. Avec le firewall c'est pareil, on va fermer tous les ports dont nous n'avons pas besoin.

Quels sont les ports dont vous vous servez ?
Attention !
Avant toute chose, il faut faire très attention à ce que vous allez faire. En effet, vous risquez de vous tromper de ports et de fermer les mauvais. Imaginez si vous fermez le port SSH ! Il faudra alors soit redemarrer via telnet, soit via webmin ou alors rebooter en hard :/.

Les ports ouverts par défaut sur les serveurs OVH sont :

Ces ports sont ceux ouverts par défaut mais vous avez peut-être des logiciels lancés qui en ouvrent d'autres. À vous de savoir lequels sont à garder ou non. Une fois votre choix effectué, passons à la mise en œuvre.

Iptables
Iptables est un firewall très performant, installé sur tous les serveurs OVH. Le fonctionnement va être le suivant : nous allons ouvrir certains ports et fermer tout le reste. Dans cet exemple, nous allons laisser que le port 22 (SSH) et 80 (HTTP). Ce n'est qu'un exemple, c'est à vous de l'adapter par rapport à vos besoins.


Voilà, iptables est mis à jour, on peut poursuivre.

On liste les régles existantes :

On voit trois rubriques : Input, Forward et Output.
Nous allons nous occupper que de la rubrique Input pour le moment (pour le trafic entrant).

On authorise les ports 22 et 80 :

-A INPUT : on place notre régle en entrée du firewall.
-i eth0 : ici c'est l'interface ethernet qui nous intéresse.
-p tcp : le protocole traîté est le TCP (on ne traîte que celui-là pour le moment).
--dport 22 : la règle va être appliquée sur le port SSH (n° 22).
-j ACCEPT : on accepte ce trafic.

On reliste tout :


La rubrique Input se remplit, c'est bon signe ;).
On voit que la politique par défaut est de tout accepter => Chain INPUT (policy ACCEPT). Nous voulons bloquer tout le trafic qu'on n'aura pas au préalable autorisé. On va donc ajouter une règle qui va bloquer les autres ports. Mais il se pose alors un problème : lorsqu'une connexion va être faite depuis notre serveur vers le serveur kernel.org pour télécharger le nouveau noyau (ce n'est qu'un exemple), il va établir une connexion vers le site et va attendre sa réponse. La demande de connexion va bien partir mais comment va-t-elle revenir étant donné qu'on a tout bloqué ? Heureusement, iptables est puissant et peux aussi trier les paquets par rapport à leur état. On va donc ajouter une règle :

Il ne reste plus qu'à bloquer le reste (attention, c'est là ou le firewall va vraiment faire effet, verifiez donc d'avoir bien rentré vos règles sinon vous allez bloquer votre serveur !) :

On a en fait deux choix ou niveau de cette règle. Soit on droppe les paquets, c'est-à-dire que si un paquet arrive et qu'il n'est pas accepté on l'efface. Le client attendra de son côté une réponse en vain, jusqu'au timeout. La deuxième solution est de rejeter les paquets (REJECT au lieu de DROP). Si un paquet non solicité arrive, on renvoie au client une erreur et il n'attend plus car il a une réponse négative. Rejeter les paquets est plus propre mais les jeter est plus securisé. En effet, immaginons quelqu'un qui vous envoie des paquets à répétition sur un mauvais port, votre serveur ne les traîtera pas, alors qu'avec la regle reject, il prendra le temps de répondre.
À vous de voir ;)

Pour mettre à zéro votre firewall, tapez :

Cette commande supprimera toutes les règles de la rubrique INPUT.

Si vous souhaitez ajouter une régle entre la première et la deuxième, tapez ceci :


Pour supprimer la règle n°3 tapez ceci :


Pour bloquer totalement une IP :


Le firewall est maintenant en action. Essayez de scanner votre serveur, vous ne verez que les ports 22 et 80 d'ouverts. Ne vous étonnez pas si le scan est très lent, c'est à cause de la régle DROP.

IP à exclure... et à autoriser ;)

Pour un Serveur dedie :

Si vous souhaitez bloquer le protocole ICMP (les requêtes ping), vous devez laisser au moins ping.ovh.net, proxy.p19.ovh.net, proxy.rbx.ovh.net, proxy.ovh.net et proxy.rbx2.ovh.net vous pinguer. Cela permet aux équipes d'OVH de verifier le bon état de votre serveur.
Vous devez de plus laisser passer l'IP obtenue de la façon suivante :
L'IP de votre serveur est de la forme aaa.bbb.ccc.ddd
Vous devez laisser passer : aaa.bbb.ccc.250
Ex 213.186.57.143 doit laisser passer 213.186.57.250 pour le serveur SLA et 213.186.57.251 pour le serveur mrtg afin de pouvoir bénéficier de RTM.

Si vous êtes sur un serveur HG, laissez passer de plus l'IP aaa.bbb.ccc.249 (règle temporaire).

Si vous bloquez toutes les requêtes ping, même celles d'OVH, nous ne surveillerons plus le bon état de marche de votre serveur et s'il tombe nous n'en serons pas avertis. Pour autoriser le ping depuis nos serveurs, entrez les règles suivantes :


Au niveau de SSH, si vous souhaitez restreindre l'accés seulement depuis votre IP, il vous est conseillé de laisser aussi cache.ovh.net. En effet, en cas de problème sur votre machine, nous pourrons intervenir dessus et vous dépanner. Si vous fermez le port 22 pour les techniciens d'OVH, nous ne pourrons vous aider si votre machine est bloquée.

Pour autoriser le SSH depuis nos serveurs, entrez la règle suivante :

Si vous avez un filer RAID, ne pas oublier d'autoriser les connexions NFS. Pour cela, nous pouvons être large en autorisant tout ce qui vient du réseau interne 192.168.0.0/16 :

Si vous avez une configuration en Cluster, il faut également autoriser le port 79 pour que OCO puisse communiquer avec le répartiteur de charge.


Si votre serveur se trouve à Roubaix 3, il est nécessaire que vous récupériez votre serveur de monitoring comme pour un RPS :

Vous trouverez alors un serveur ayant un nom du type sla-rbx3-2.ovh.net que vous devez ajouter aux exceptions de votre firewall. Le tcpdump doit être fait sur l'ip fixe :



Pour un Serveur RPS :

L'interface monitoré par nos services est la eth0 (ou dummy0) les régles de firewall s'appliqueront sur celle-ci.

Si vous bloquez toutes les requêtes ping, même celles d'OVH, nous ne surveillerons plus le bon état de marche de votre serveur et s'il tombe nous n'en serons pas avertis. Pour autoriser le ping depuis nos serveurs, entrez les règles suivantes :



Pour récupérer la liste complète des serveurs de monitoring de votre rps, utilisez cette commande :



Ajoutez ensuite les ips ou les noms trouvés comme ci-dessus :



Il faudra egalement autoriser votre filer, pour le retrouver utiliser la commande :


L'IP de votre filer est donc : 91.121.191.16
La regle a ajouter sera :




Exemple de configuration complète
Voici un exemple de script complet pour protéger votre serveur via iptables. Il est assez permissif dans le sens où la plupart des services présents sur votre machine sont accessibles, mais il peut servir de base pour votre propre configuration :

Dans ces règles, il faut bien sûr remplacer xx.xx.xx.xx par l'adresse IP de la machine dont vous vous servez pour accéder à votre serveur en FTP et SSH.

Automatiser le firewall
Une fois votre firewall parfaitement configuré, il ne vous reste plus qu'à créer un script qui se lancera à chaque démarrage de votre serveur. Voici un exemple à placer dans un fichier nommé par exemple "firewall" dans le répertoire /etc/init.d/ :


Donnez-lui les droits 700 et tapez "/etc/init.d/firewall start" pour le démarrer et "/etc/init.d/firewall stop" pour l'arrêter. Pour le lancer automatiquement au démarrage :


Vérifiez avant de mettre le script à chaque démarrage du serveur qu'il soit bon sinon votre serveur sera définitivement bloqué ! La communication entre le service RTM et votre serveur nécessite également que vous autorisez les connexions entrant sortant sur les ports UDP 6100 a 6200.