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.
"},{"id":"text-2","type":"text","heading":"","plain_text":"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.\nDissection d'une règle de pare-feu\nL'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:","html":"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.\nDissection d'une règle de pare-feu\nL'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:
"},{"id":"text-3","type":"text","heading":"","plain_text":"Adresse IP source\nPort source\nAdresse IP de destination\nLe port de destination\nProtocole","html":"Adresse IP source\nPort source\nAdresse IP de destination\nLe port de destination\nProtocole
"},{"id":"text-4","type":"text","heading":"","plain_text":"Pour une règle TCP telle que HTTP, la négociation en trois étapes suivante s'applique:","html":"Pour une règle TCP telle que HTTP, la négociation en trois étapes suivante s'applique:
"},{"id":"text-5","type":"text","heading":"","plain_text":"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.\nle 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.\nle la machine cliente reçoit le SYN-ACK paquet de la destination et renvoie un ACK final paquet.","html":"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.\nle 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.\nle la machine cliente reçoit le SYN-ACK paquet de la destination et renvoie un ACK final paquet.
"},{"id":"text-6","type":"text","heading":"","plain_text":"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.\nExemple de scénario\nPour 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:","html":"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.\nExemple de scénario\nPour 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:
"},{"id":"text-7","type":"text","heading":"","plain_text":"Autoriser à","html":"Autoriser à
"},{"id":"text-8","type":"text","heading":"","plain_text":"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.\nEn 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:","html":"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.\nEn 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:
"},{"id":"text-9","type":"text","heading":"","plain_text":"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.\nLes 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:","html":"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.\nLes 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:
"},{"id":"text-10","type":"text","heading":"","plain_text":"Externe aux ordinateurs serveurs gérés\nOrdinateurs serveurs gérés vers externe\nExterne à Externe\nOrdinateurs serveurs gérés vers ordinateurs serveurs gérés","html":"Externe aux ordinateurs serveurs gérés\nOrdinateurs serveurs gérés vers externe\nExterne à Externe\nOrdinateurs serveurs gérés vers ordinateurs serveurs gérés
"},{"id":"text-11","type":"text","heading":"","plain_text":"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.\nLorsque vous avez besoin de règles de pare-feu bidirectionnelles\nBien 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.\nPar 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\nCe pare-feu à règles bidirectionnelles, s'il est effectivement requis, ressemblerait à ceci:","html":"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.\nLorsque vous avez besoin de règles de pare-feu bidirectionnelles\nBien 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.\nPar 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\nCe pare-feu à règles bidirectionnelles, s'il est effectivement requis, ressemblerait à ceci:
"},{"id":"text-12","type":"text","heading":"","plain_text":"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.\nAprè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.","html":"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.\nAprè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.
"},{"id":"text-13","type":"text","heading":"","plain_text":"Conclusion\nComprendre 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.\nDes 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.\nSi 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.","html":"Conclusion\nComprendre 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.\nDes 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.\nSi 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.
"},{"id":"text-14","type":"text","heading":"","plain_text":"Click to rate this post!\n \n [Total: 0 Average: 0]","html":"Click to rate this post!\n \n [Total: 0 Average: 0]
"}],"sections":[{"id":"text-1","heading":"Text","content":"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."},{"id":"text-2","heading":"Text","content":"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.\nDissection d'une règle de pare-feu\nL'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:"},{"id":"text-3","heading":"Text","content":"Adresse IP source\nPort source\nAdresse IP de destination\nLe port de destination\nProtocole"},{"id":"text-4","heading":"Text","content":"Pour une règle TCP telle que HTTP, la négociation en trois étapes suivante s'applique:"},{"id":"text-5","heading":"Text","content":"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.\nle 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.\nle la machine cliente reçoit le SYN-ACK paquet de la destination et renvoie un ACK final paquet."},{"id":"text-6","heading":"Text","content":"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.\nExemple de scénario\nPour 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:"},{"id":"text-7","heading":"Text","content":"Autoriser à"},{"id":"text-8","heading":"Text","content":"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.\nEn 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:"},{"id":"text-9","heading":"Text","content":"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.\nLes 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:"},{"id":"text-10","heading":"Text","content":"Externe aux ordinateurs serveurs gérés\nOrdinateurs serveurs gérés vers externe\nExterne à Externe\nOrdinateurs serveurs gérés vers ordinateurs serveurs gérés"},{"id":"text-11","heading":"Text","content":"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.\nLorsque vous avez besoin de règles de pare-feu bidirectionnelles\nBien 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.\nPar 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\nCe pare-feu à règles bidirectionnelles, s'il est effectivement requis, ressemblerait à ceci:"},{"id":"text-12","heading":"Text","content":"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.\nAprè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."},{"id":"text-13","heading":"Text","content":"Conclusion\nComprendre 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.\nDes 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.\nSi 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."},{"id":"text-14","heading":"Text","content":"Click to rate this post!\n \n [Total: 0 Average: 0]"}],"media":{"primary_image":"https://tutos-gameserver.fr/wp-content/uploads/2020/05/1.png"},"relations":[{"rel":"canonical","href":"https://tutos-gameserver.fr/2020/05/22/les-tenants-et-aboutissants-des-regles-de-pare-feu-bidirectionnelles-serveur-dimpression/"},{"rel":"alternate","href":"https://tutos-gameserver.fr/2020/05/22/les-tenants-et-aboutissants-des-regles-de-pare-feu-bidirectionnelles-serveur-dimpression/llm","type":"text/html"},{"rel":"alternate","href":"https://tutos-gameserver.fr/2020/05/22/les-tenants-et-aboutissants-des-regles-de-pare-feu-bidirectionnelles-serveur-dimpression/llm.json","type":"application/json"},{"rel":"llm-manifest","href":"https://tutos-gameserver.fr/llm-endpoints-manifest.json","type":"application/json"}],"http_headers":{"X-LLM-Friendly":"1","X-LLM-Schema":"1.1.0","Content-Security-Policy":"default-src 'none'; img-src * data:; style-src 'unsafe-inline'"},"license":"CC BY-ND 4.0","attribution_required":true,"allow_cors":false}