Lorsque vous modifiez une configuration de pare-feu, il est important de prendre en compte les risques de sécurité potentiels pour éviter de futurs problèmes. La sécurité est un sujet complexe et peut varier d'un cas à l'autre, mais cet article décrit les meilleures pratiques pour configurer les règles de pare-feu de périmètre.
Bloquer par défaut
Bloquez tout le trafic par défaut et activez explicitement uniquement le trafic spécifique vers les services connus. Cette stratégie offre un bon contrôle du trafic et réduit la possibilité d'une violation en raison d'une mauvaise configuration du service.
Vous obtenez ce comportement en configurant la dernière règle dans une liste de contrôle d'accès pour refuser tout le trafic. Vous pouvez le faire explicitement ou implicitement, selon la plate-forme.
Autoriser un trafic spécifique
Les règles que vous utilisez pour définir l'accès au réseau doivent être aussi précises que possible. Cette stratégie est le principe du moindre privilège , et il force le contrôle du trafic réseau. Spécifiez autant de paramètres que possible dans les règles.
Un pare-feu de couche 4 utilise les paramètres suivants pour une règle d'accès :
- Adresse IP source (ou plage d'adresses IP)
- Adresse IP de destination (ou plage d'adresses IP)
- Port de destination (ou plage de ports)
- Protocole du trafic (TCP, ICMP ou UDP)
Spécifiez autant de paramètres que possible dans la règle utilisée pour définir l'accès au réseau. Il existe des scénarios limités où any est utilisé dans l'un de ces champs.
Spécifier les adresses IP sources
Si le service doit être accessible à tous sur Internet, alors tous l'adresse IP source est l'option correcte. Dans tous les autres cas, vous devez spécifier l'adresse source.
Il est acceptable d'autoriser toutes les adresses sources à accéder à votre serveur HTTP. Il n'est pas acceptable d'autoriser toutes les adresses source à accéder aux ports de gestion de votre serveur ou aux ports de base de données. Voici une liste des ports de gestion de serveur et des ports de base de données courants :
Ports de gestion du serveur :
- Linux®SSH :Port 22
- Windows® RDP :port 3389
Ports de la base de données :
- SQL® Server :Port 1433
- Oracle® :Port 1521
- MySQL® :Port 2206
Soyez précis sur qui peut atteindre ces ports. Lorsqu'il n'est pas pratique de définir des adresses IP source pour la gestion du réseau, vous pouvez envisager une autre solution comme un VPN d'accès à distance comme contrôle compensatoire pour autoriser l'accès requis et protéger votre réseau.
Spécifiez l'adresse IP de destination
L'adresse IP de destination est l'adresse IP du serveur qui exécute le service auquel vous souhaitez autoriser l'accès. Spécifiez toujours quel(s) serveur(s) sont accessibles. Configuration d'une valeur de destination de any pourrait entraîner une faille de sécurité ou la compromission du serveur d'un protocole inutilisé qui pourrait être accessible par défaut. Cependant, les adresses IP de destination avec une valeur de destination de any peut être utilisé s'il n'y a qu'une seule adresse IP attribuée au pare-feu. La valeur any peut également être utilisé si vous voulez à la fois public et servicenet accéder à votre configuration.
Spécifiez le port de destination
Le port de destination correspond au service accessible. La valeur de ce champ ne doit jamais être any . Le service qui s'exécute sur le serveur et auquel il faut accéder est défini, et seul ce port doit être autorisé. L'autorisation de tous les ports affecte la sécurité du serveur en autorisant les attaques par dictionnaire ainsi que les exploits de tout port et protocole configuré sur le serveur.
Évitez d'utiliser une gamme trop large de ports. Si des ports dynamiques sont utilisés, les pare-feu proposent parfois des politiques d'inspection pour les autoriser en toute sécurité.
Exemples de configurations dangereuses
Cette section décrit des exemples dangereux de règles de pare-feu, mais montre également quelques bonnes règles alternatives à suivre lors de la configuration des règles de pare-feu.
permit ip any any - Autorise tout le trafic de n'importe quelle source sur n'importe quel port vers n'importe quelle destination. C'est le pire type de règle de contrôle d'accès. Cela contredit à la fois les concepts de sécurité consistant à refuser le trafic par défaut et le principe du moindre privilège. Le port de destination doit toujours être spécifié et l'adresse IP de destination doit être spécifiée lorsque cela est possible. L'adresse IP source doit être spécifiée, sauf si l'application est conçue pour recevoir des clients d'Internet, comme un serveur Web. Une bonne règle serait permit tcp any WEB-SERVER1 http .
permit ip any any WEB-SERVER1 - Autorise tout le trafic de n'importe quelle source vers un serveur Web. Seuls des ports spécifiques doivent être autorisés ; dans le cas d'un serveur web, les ports 80 (HTTP) et 443 (HTTPS). Sinon, la gestion du serveur est vulnérable. Une bonne règle serait permit ip any WEB-SERVER1 http .
permit tcp any WEB-SERVER1 3389 - Permet l'accès RDP de n'importe quelle source au serveur Web. C'est une pratique dangereuse d'autoriser tout le monde à accéder à vos ports de gestion. Soyez précis sur qui peut accéder à la gestion du serveur. Une bonne règle serait permit tcp 12.34.56.78 3389 WEB-SERVER1 (où 12.34.56.78 est l'adresse IP de l'ordinateur de l'administrateur sur Internet).
permit tcp any DB-SERVER1 3306 - Permet l'accès MySQL à partir de n'importe quelle source à la base de données. Les serveurs de base de données ne doivent jamais être exposés à l'ensemble d'Internet. Si vous avez besoin d'exécuter des requêtes de base de données sur l'Internet public, spécifiez l'adresse IP source exacte. Une bonne règle serait permit tcp 23.45.67.89 DB-SERVER1 3306 (où 23.45.67.89 est l'adresse IP de l'hôte sur Internet qui a besoin d'accéder à la base de données). Une bonne pratique consisterait à autoriser le trafic de la base de données sur un VPN et non en texte clair sur l'Internet public.
Si vous avez besoin d'aide pour mettre en œuvre ces bonnes pratiques, contactez votre équipe d'assistance Rackspace.