Y a-t-il un sens à n'autoriser que les ports 80 et 443 aujourd'hui?
C'est devenu un tarif standard pour les organisations soucieuses de la sécurité de bloquer tout autre que 80 et 443. En conséquence, de plus en plus d'applications (autres que les navigateurs Web) apprennent également à utiliser ces ports pour leurs besoins.
Les programmes naturellement malveillants le font aussi, ce qui signifie que pour avoir une réelle sécurité, les pare-feu doivent réellement examiner le flux de données et les bloquer en fonction des données d'application au lieu de simplement des ports ...
Cela semble indiquer que le blocage basé sur le port était une approche à courte vue pour commencer, un peu comme la validation d'entrée uniquement sur le client ...
Dans ce cas, ne devrions-nous pas arrêter de bloquer les ports non standard et opter pour un filtrage plus fin en premier lieu ...? Ou existe-t-il d'autres raisons de conserver l'approche de la liste blanche des ports?
Le blocage de tous les ports sauf 80 et 443 peut faire partie d'une bonne stratégie de défense en profondeur. Si c'est votre seule stratégie, alors vous avez raison, elle sera défectueuse.
Une approche à plusieurs niveaux potentielle peut être
- Bloquer tous les ports du pare-feu externe moins 80/443
- Avoir une analyse en ligne des paquets IPS (ou dans le cadre de votre pare-feu)
- Désinfection des entrées d'applications Web avec un pare-feu d'applications Web
- Assainir l'entrée DB avec un pare-feu DB
- Enregistrez tout et alimentez-le dans un système de gestion des journaux (avec alertes)
- Sauvegardes sur tout (quelle que soit votre stratégie de disponibilité)
- Durcissez chaque système d'exploitation en fonction de la base de référence/des critères de référence que vous choisissez (par exemple, Org SOP, CIS/DISA STIGS, etc.)
Ce n'est qu'un exemple très simple. Une bonne stratégie de défense en profondeur comporte plusieurs couches qui, ensemble, construisent un système sécurisé.
Vous avez absolument raison. Il n'y a rien de magique à propos du port 80 ou du port 443. Il n'y a rien de intrinsèquement sûr à propos d'un port ou d'un autre, ou même d'un protocole ou d'un autre. Si vous bloquez tout sauf HTTP, tout le monde commencera simplement à utiliser HTTP. Les attaquants peuvent et se déplacent toujours plus vite que tout le reste. Ils ne sont pas limités par la maintenance de l'ancienne infrastructure.
En substance, les protocoles et les ports ne sont pas sécurisés ou non sécurisés. Les bloquer n'est qu'une autre forme de théâtre de la sécurité.
La liste blanche est généralement préférable à la liste noire. Si vous ouvrez uniquement les ports dont vous avez réellement besoin et si vous limitez ces ports dans la mesure du possible, vous avez réduit votre surface d'attaque et limité le trafic que vous devez surveiller.
Oui, 80 et 443 peuvent toujours être utilisés abusivement pour du trafic malveillant. Mais, vous élevez également la barre pour les attaques (au moins un peu) en les forçant à travers une fenêtre beaucoup plus petite, et une fenêtre sur laquelle vous pouvez plus facilement garder un œil.
Peu importe les numéros de port. Les applications qui écoutent ou se connectent sur n'importe quel port sont importantes. Utilisez la mise en réseau pour limiter les vecteurs d'attaque des applications.
Quelques suggestions:
- Les nœuds d'application doivent être accessibles sur plusieurs réseaux ayant des finalités et des profils de trafic différents: un réseau d'application et un réseau de gestion.
- Évitez les applications sur les ports <1024, par ex. utilisez 8080 ou un autre port aléatoire. NAT vers les ports d'application aux limites du réseau d'application (au niveau du LB).
- Utilisez iptables pour autoriser uniquement le trafic d'application (80, 443) à partir d'adresses IP d'équilibreur de charge spécifiques (si vous n'utilisez pas de LB de routage direct) ou vers des services internes (votre base de données).
- Limitez SSH (22) et tout autre trafic (journalisation) à un réseau de gestion.
- Si possible, séparez physiquement les réseaux.
- Ne comptez pas sur DNS pour la configuration du nœud d'application.
- Séparez les réseaux d'entreprise et de développement des réseaux de production.
- Surveillez les réseaux séparés pour le trafic non approuvé. Par exemple: le trafic SSH sur votre réseau d'applications indique un problème.