Serveur d'impression

Les tenants et aboutissants des règles de pare-feu bidirectionnelles – Serveur d’impression

Par Titanfall , le 22 mai 2020 - 5 minutes de lecture

Lorsque je regarde les ensembles de règles de pare-feu maintenus par d'autres sociétés, je remarque souvent les mêmes erreurs courantes. Celui que je vois le plus souvent est potentiellement le pire. Je peux spéculer sur un certain nombre de raisons pour lesquelles ces règles sont réellement définies et mises en œuvre, mais tout revient à la même chose. La façon dont le trafic est évalué et traité par un pare-feu n'est pas toujours bien comprise. Le résultat est une règle qui ressemble à ceci.

L'idée étant que le client a besoin d'un moyen de se connecter au serveur Web et que le serveur Web a besoin d'un moyen de se reconnecter au client. Permettez-moi d'expliquer pourquoi cette règle est mauvaise et parfois inutile.

Dissection d'une règle de pare-feu

L'essence même d'un pare-feu est de limiter ou de restreindre le trafic indésirable, il le fait en évaluant des critères spécifiques. À sa base, une règle de pare-feu se compose de 5 objets:

  • Adresse IP source
  • Port source
  • Adresse IP de destination
  • Le port de destination
  • Protocole

Pour une règle TCP telle que HTTP, la négociation en trois étapes suivante s'applique:

  1. le la source ou le client est l'ordinateur initiateur la conversation avec un SYN paquet. Un port est alloué dynamiquement sur la machine source et la demande est envoyée à la destination sur le port de service statique prédéfini.
  2. le la destination ou le serveur est l'ordinateur qui reçoit la demande de conversation SYN sur le port de service statique spécifié. La machine de destination renvoie un SYN-ACK paquet.
  3. le la machine cliente reçoit le SYN-ACK paquet de la destination et renvoie un ACK final paquet.

Ceci termine la poignée de main à trois voies. À ce stade, vous disposez d'un socket TCP ou d'une paire de conversations. Pendant la durée de vie du socket, le numéro de port sur la source et la destination ne changera pas. Cette prise est désormais à double sens sentier ou canal à travers lequel le trafic se déplace entre le client et le serveur.

Exemple de scénario

Pour utiliser un exemple très simple, examinons la règle de pare-feu requise pour autoriser une machine source ou client à demander un site Web à un serveur Web ou à une destination:

Autoriser à

Cela permettrait au client d'engager la conversation et de recevoir les données. Il y a pas besoin d'une deuxième règle sortante pour permettre au serveur Web de parler au client.

En effet, il existe un prise existante cela peut être, et est utilisé. C'est une erreur raisonnable de supposer que vous avez besoin d'une règle pour autoriser le trafic vers le client. Les règles ressembleraient à ceci:

La règle entrante est correcte car elle permet au client d'initier la conversation bidirectionnelle. La règle sortante n'est pas du tout requise et ouvre réellement l'accès indésirable. Les ordinateurs du serveur géré peuvent désormais établir des connexions au réseau externe et surfer sur Internet, ce qui n'est ni prévu ni requis.

Les administrateurs inexpérimentés peuvent également simplement combiner les deux règles, ce qui donne le premier exemple en haut de cet article. Dans ce scénario, vous disposez en fait de l'accès suivant:

  • Externe aux ordinateurs serveurs gérés
  • Ordinateurs serveurs gérés vers externe
  • Externe à Externe
  • Ordinateurs serveurs gérés vers ordinateurs serveurs gérés

Ce n'est vraiment pas le résultat souhaité, et c'est pourquoi c'est une si mauvaise règle d'accès. Tout ce qui est requis est la bonne règle entrante pour initier et établir le socket de conversation.

Lorsque vous avez besoin de règles de pare-feu bidirectionnelles

Bien sûr, des règles de pare-feu bidirectionnelles peuvent être requises dans certaines situations lorsque l'un ou l'autre côté doit établir une connexion.

Par exemple, il peut être nécessaire que les ordinateurs du groupe Ordinateurs serveurs gérés entament des conversations entre eux pour communiquer des informations de pulsation ou d'équilibrage de charge. S'il n'y a pas de route interne pour ce trafic, comme des serveurs situés à l'intérieur et à l'extérieur du segment DMZ, une règle bidirectionnelle est nécessaire

Ce pare-feu à règles bidirectionnelles, s'il est effectivement requis, ressemblerait à ceci:

J'aime la pensée de ces règles bidirectionnelles comme règles symétriques, où les exigences concernant la source et la destination sont les mêmes.

Après avoir considéré tous les critères et appliqué la logique ci-dessus, les exigences peuvent être satisfaites avec ces deux règles simples.

Conclusion

Comprendre comment le trafic circule et est traité par un pare-feu est très important lors de la demande ou de l'implémentation de règles de pare-feu.

Des précautions supplémentaires doivent être prises lorsque la source et la destination ne sont pas des ordinateurs ou des adresses IP uniques, car les groupes d'ordinateurs ou les objets réseau peuvent modifier considérablement la portée de la règle.

Si vous n'êtes toujours pas sûr de l'impact d'une règle sur votre réseau, divisez-la en plusieurs règles et suivez leur utilisation (ou leur non-utilisation) avec des outils tels que TMG Reporter ou Webspy Vantage. Ils sont non seulement excellents pour les rapports, mais ils peuvent vraiment aider à renforcer les règles de sécurité en vous donnant une visibilité complète de l'activité des règles de pare-feu.

Click to rate this post!
[Total: 0 Average: 0]

Commentaires

Laisser un commentaire

Votre commentaire sera révisé par les administrateurs si besoin.