Pourquoi bloquer le trafic réseau sortant avec un pare-feu?
En termes de réseau domestique, existe-t-il une raison de configurer un pare-feu de routeur afin que tous les ports sortants soient bloqués, puis d'ouvrir des ports spécifiques pour des choses telles que HTTP, HTTPS, etc. Étant donné que chaque ordinateur du réseau est approuvé, la sécurité supplémentaire fournie par le blocage des ports sortants serait-elle à peu près négligeable?
Le blocage du trafic sortant est généralement avantageux pour limiter ce qu'un attaquant peut faire une fois qu'il a compromis un système sur votre réseau.
Ainsi, par exemple, s'ils ont réussi à obtenir des logiciels malveillants sur un système (via un e-mail infecté ou une page de navigateur), le logiciel malveillant pourrait essayer de "rappeler à la maison" à un système de commande et de contrôle sur Internet pour télécharger du code supplémentaire ou pour accepter des tâches d'un système de contrôle (par exemple l'envoi de spam)
Le blocage du trafic sortant peut aider à empêcher cela de se produire, donc ce n'est pas tant de vous empêcher d'être infecté que de le rendre moins mauvais quand cela se produit.
Cela pourrait être exagéré pour un réseau domestique, car il existe de nombreux programmes qui rendent les connexions sortantes et vous devez passer un peu de temps à configurer toutes les exceptions.
Issu d'un rôle de sécurité, en particulier si vous avez déjà été impliqué dans la réponse à un incident, l'idée du filtrage sortant semble un cours naturel dans un environnement de haute sécurité. Cependant, c'est une entreprise très vaste et complexe. Mentionnez les mots "filtrage de sortie" à un administrateur de pare-feu, de réseau ou de système et vous obtiendrez probablement cette réponse.
Donc, même si nous savons que les environnements de haute sécurité peuvent en avoir besoin et justifieraient un travail supplémentaire, il peut parfois être difficile d'obtenir l'adhésion. Particulièrement quand une unité dont le devoir principal est de maintenir la disponibilité est soudainement invitée à assumer une quantité potentiellement importante de maintenance supplémentaire pour accomplir quelque chose qui a une forte probabilité de réduire la disponibilité.
Dans ce cas, nous serions ravis de ne pas mentionner l'angle de conformité. Regardons le PCI-DSS v2.0 pendant un moment. La section 1 des exigences traite des systèmes et de la sécurité du réseau. Celui-ci est pertinent ici:
1.3.5
N'autorisez pas le trafic sortant non autorisé de l'environnement de données du titulaire de carte vers Internet.
Autant que nous aimons tous parler de la façon dont "la conformité est un point de départ" dans le monde réel, parfois la seule traction que nous pouvons obtenir est le but de remplir cette case à cocher ou de passer cet audit. Il pourrait être utile de consulter les documents de conformité relatifs à votre domaine ou service. Bien que le PCI-DSS soit exclusivement une exigence de l'industrie, acceptée par le droit des contrats, il s'agit d'un ensemble d'exigences assez spécifique que j'ai vu adopté comme norme de vérification contre d'autres endroits qui ont des exigences moins bien définies.
À moins que vous ne bloquiez tout le trafic sortant autre qu'une liste blanche de sites Web légitimes que vous visitez (et/ou utilisez un proxy qui fait la liste blanche et l'analyse de sécurité), il y a peu de sécurité supplémentaire à gagner en bloquant tous les ports sauf 80/443. Eh bien, le blocage du port 25 peut être utile pour empêcher votre réseau d'être utilisé pour envoyer du spam.
De nombreux botnets communiquent déjà via HTTP pour se connecter à leur réseau de commande/contrôle car ils savent que d'autres ports peuvent être bloqués (certains utilisent même DNS comme protocole de commande/contrôle). Donc, si vous laissez votre réseau se connecter à n'importe quel serveur HTTP, vous ne vous offrez pas beaucoup de protection supplémentaire contre l'adhésion à un botnet et vous rencontrerez continuellement des problèmes lorsque vous essayez d'exécuter des choses qui utilisent d'autres ports comme VPN, vidéoconférence, jeux en ligne, sites Web sur des ports non standard, FTP, etc. Et vous auriez vraiment besoin d'auditer régulièrement les journaux pour rechercher des signes d'infection.
Ne vaut probablement pas la peine sur un réseau domestique. Il vaut probablement mieux passer votre temps à essayer de prévenir les infections par des logiciels malveillants que d'atténuer les dommages une fois que vous avez été infecté.
Le blocage du trafic entrant peut uniquement empêcher le trafic non sollicité d'atteindre votre réseau interne. Cependant, si vous obtenez des logiciels malveillants sur une machine interne (via l'exécution d'un exécutable non fiable ou via un exploit), vous pouvez toujours être touché.
Le blocage du trafic sortant permet de limiter les dégâts, en empêchant le malware de se connecter à un serveur de commande et de contrôle ou d'exfiltrer des données. Bien que votre machine soit toujours compromise, cela pourrait vous éviter de vous faire voler vos données personnelles par un enregistreur de frappe.
Deux raisons:
- Dans le cas où des logiciels malveillants pénètrent dans votre réseau, le blocage du trafic sortant peut parfois contenir les dommages en empêchant le logiciel malveillant de contacter un serveur distant. Si vous pare-feu au niveau de la machine, vous pouvez également empêcher le malware de se propager davantage à travers votre réseau. Interdire le trafic sortant signifie également que votre machine devient moins intéressante dans le cadre d'un botnet.
- Un logiciel légitime doté de capacités de mise en réseau peut être vulnérable et peut être amené à configurer des connexions sortantes qui peuvent ensuite être utilisées pour compromettre davantage votre système. Considérons, par exemple, un serveur Web qui exécute une application avec une faille qui permet à un attaquant de la tromper en téléchargeant des fichiers sur Internet au lieu d'ouvrir des fichiers locaux (une telle faille est facile à produire et à ignorer, par exemple, en PHP) . Si vous l'avez correctement pare-feu, la demande échouera simplement, et déclenchera peut-être même une alarme quelque part.
Au-delà du contrôle des dommages après un compromis, vous pouvez également:
Contrôlez comment (et si) les utilisateurs et les processus du réseau utilisent Internet
Surveillez vos processus internes pour détecter les logiciels malveillants ("analyse de vulnérabilité passive")
Le blocage des requêtes DNS sortantes afin que le DNS ne puisse être acheminé que via votre serveur DNS préféré (serveur DNS d'entreprise, OpenDNS, Quad9, Google Public DNS, etc.) est assez courant sur un réseau qui a été quelque peu sécurisé.
US-CERT a un article informatif à ce sujet et répertorie les impacts de ne pas le faire:
À moins d'être gérés par des solutions techniques de périmètre, les systèmes et applications clients peuvent se connecter à des systèmes hors du contrôle administratif de l'entreprise pour la résolution DNS. Les systèmes d'entreprise internes ne devraient être autorisés qu'à initier des demandes et à recevoir des réponses des serveurs de noms de mise en cache DNS d'entreprise approuvés. Autoriser les systèmes et applications clients à se connecter directement à l'infrastructure DNS Internet présente des risques et des inefficacités pour l'organisation, notamment:
- Surveillance et journalisation du trafic DNS contournées par l'entreprise; ce type de surveillance est un outil important pour détecter les logiciels malveillants potentiels
activité réseau.- Capacités de filtrage de sécurité DNS d'entreprise contournées (gouffre/redirection ou trou noir/bloc); cela peut permettre aux clients d'accéder à des domaines malveillants qui seraient autrement bloqués.
- Interaction du client avec des serveurs DNS compromis ou malveillants; cela peut entraîner des réponses DNS inexactes pour le domaine demandé (par exemple,
le client est envoyé vers un site de phishing ou reçoit un code malveillant).- Protections perdues contre l'empoisonnement du cache DNS et les attaques par déni de service. Les effets atténuants d'une architecture DNS à plusieurs niveaux ou hiérarchique (par exemple, des serveurs DNS internes et externes séparés, un DNS fractionné, etc.) utilisés pour empêcher de telles attaques sont perdus.
- Vitesse de navigation Internet réduite car la mise en cache DNS d'entreprise ne serait pas utilisée.
"il y a peu de sécurité supplémentaire à gagner en bloquant tous les ports sauf 80/443."
sauf si vous exécutez un proxy afin de masquer votre IP, quel code d'un site Web (ou injecté dans un site Web) pourrait contourner en téléphonant à la maison sur un autre port, contournant ainsi votre proxy (qui sera normalement configuré uniquement pour rediriger le trafic sortant) trafic sur les ports habituellement utilisés par votre navigateur).
C'est si simple que quiconque utilise Tor devrait en être conscient, car il perce un trou à travers le masque fourni par Tor.
Solution: acheminez TOUS les ports via le proxy (Tor ne le recommande pas en raison d'une perte de performances) ou bloquez tous les ports sortants, à l'exception de ceux spécifiquement routés via votre proxy.
Cette pensée est motivée par toutes les fuites NSA et GCHQ au cours des derniers mois: ne le bloquez pas - redirigez tous les paquets vers votre propre hôte ou quelqu'un d'autre pour un examen plus approfondi. seule façon de les faire attraper.
Une meilleure approche pour un réseau domestique est un "pare-feu personnel" logiciel qui s'exécute sur chaque PC et invite l'utilisateur s'il souhaite autoriser un programme qui essaie d'établir une connexion sortante à le faire.
Ceci, bien qu'ennuyeux au début lorsqu'il vous demande tout alors qu'il essaie de comprendre ce qui devrait être autorisé, est plus facile à maintenir dans un environnement domestique qu'un pare-feu réseau faisant un blocage sortant qui n'a aucune idée de la différence entre Google Chrome faisant une demande de page Web et LulzBot2000 (oui, je l'ai inventé) faisant une demande Web pour les charges utiles de logiciels malveillants.