Est-il toujours préférable d'éviter d'utiliser les ports par défaut pour SQL Server?
Historiquement, il a été recommandé de ne pas utiliser les ports par défaut pour les connexions à SQL Server, dans le cadre des meilleures pratiques de sécurité. Sur un serveur avec une seule instance par défaut, les ports suivants seraient utilisés par défaut:
- Service SQL Server - Port 1433 (TCP)
- Service de navigateur SQL Server - Port 1434 (UDP)
- Connexion administrateur dédiée - Port 1434 (TCP)
QUESTIONS:
- Ce conseil est-il toujours pertinent?
- Faut-il changer TOUS les ports ci-dessus?
Historiquement, il a été recommandé de ne pas utiliser les ports par défaut pour les connexions à SQL Server, dans le cadre des meilleures pratiques de sécurité.
Ce qui était asinin alors et toujours asinine maintenant. La sécurité par sans doute l'obscurité n'est pas du tout la sécurité.
Ce conseil est-il toujours pertinent
À mon humble avis, il n'a jamais été pertinent. Il était nécessaire à certaines fins de conformité parce que les personnes qui rédigeaient ces conformités ne comprenaient pas ce qu'elles faisaient, encore une fois, à mon humble avis.
Faut-il changer TOUS les ports ci-dessus?
Je n'en changerais pas.
Même si la sécurité par l'obscurité n'est pas une sécurité réelle, je ne dirai pas qu'il n'y a aucun cas où cela aide.
Si un attaquant veut savoir où votre service écoute, il peut facilement le découvrir, mais en cas d'attaque automatisée stupide, vous pourriez avoir de la chance si vous changez de port.
La seule fois où je me souviens où cela a réellement aidé, c'est à l'époque de SQL Slammer où SQL Server 2000 était vulnérable et un ver se propageait en générant des IP aléatoires et en se connectant au port de navigateur SQL Server par défaut.
Si je me souviens bien, c'était un conseil officiel à l'époque de changer les ports jusqu'à ce que vous puissiez patcher votre serveur (soit parce qu'il n'y avait pas de patch disponible immédiatement ou parce que vous n'aviez pas de fenêtre)
Pour que ce ver entre dans votre réseau au moment où vous aviez besoin d'un SQL Server connecté à Internet plutôt que derrière un pare-feu, ce que vous ne devriez pas, mais de toute façon, un numéro de port non par défaut aurait pu aider dans ce cas spécifique.
Je suis cependant d'accord que si vous avez une sécurité adéquate en place, la complexité que vous ajoutez ne l'emporte probablement pas sur les chances de prévenir un incident.
Historiquement, il a été recommandé de ne pas utiliser les ports par défaut pour les connexions à SQL Server, dans le cadre des meilleures pratiques de sécurité
Non, ça ne l'était pas. Certaines personnes malavisées peuvent l'avoir présenté comme tel, mais je fais de la sécurité depuis plus de 20 ans et changer les ports par défaut a toujours été une sorte de "voici quelque chose que vous pouvez faire si vous le souhaitez, ce qui peut parfois dans des circonstances très spécifiques fournit un peu de sécurité supplémentaire contre certaines menaces très spécifiques ".
Ce conseil est-il toujours pertinent?
Dans des circonstances très spécifiques, en fonction de votre modèle de menace et de l'analyse des risques, il peut y avoir des cas où il s'agit de conseils judicieux. Dans la grande majorité des cas, non, ce n'est pas pertinent et cela n'a jamais été le cas.
OUI , c'est toujours utile.
La modification des ports par défaut n'a qu'un seul objectif réel: se défendre contre les analyses/attaques automatisées, si votre serveur de base de données est ouvert aux hôtes qui pourraient être compromis.
Bien que cela puisse ne pas sembler être un gros problème, rappelez-vous que:
- tout hôte peut être compromis (ou votre serveur de bases de données peut être exposé à Internet en général en raison d'une erreur)
- la plupart des attaques de nos jours sont des attaques automatisées , et beaucoup d'entre elles essaieront uniquement les ports par défaut (car viser des fruits bas est plus efficace).
Donc, oui, alors que cela ne vous aidera pas beaucoup si vous êtes sous une attaque ciblée , en utilisant des ports aléatoires (et/ou en le faisant écouter sur IPv6 aléatoire adresse uniquement) le rendra beaucoup moins visible, ce qui vous donnera au moins plus de temps pour mettre à niveau avant que l'analyse automatisée 0day exploit vous frappe (et pourrait même vous protéger complètement contre une telle analyse automatisée tout seul!)
De plus (cela aidera non seulement contre toutes les attaques automatisées contre, mais aussi contre certaines attaques ciblées aussi) lorsque les attaquants tentent de trouver votre port de base de données pour l'exploiter par des analyses de port par bruteforce, il peut être détecté et défendu (en mettant sur liste noire les plages d'adresses IP des attaquants) et alerter les administrateurs si un hôte interne a été détecté comme source de l'attaque)
Notez également que la modification du port par défaut pour le serveur et les clients (en particulier s'ils sont déployés automatiquement) est une tâche insignifiante, et la détection des analyses de bruteforce est également facile; vous devriez donc vraiment le faire (pas seulement pour les serveurs de base de données; mais pour tous les services où les frais généraux de sa configuration ne sont pas prohibitifs en raison de problèmes d'utilisation: comme changer le port par défaut pour le Web de 80 n'est pas recommandé, car certaines personnes (et certains bots) le gâcheront, et des pare-feu aléatoires à travers le monde pourraient ne pas permettre l'établissement de la connexion. Mais RDP est une excellente cible, par exemple pour le port non par défaut)
Je ne changerais pas le port, mais n'exposez jamais le service de base de données directement sur Internet. Uniquement via un tunnel sécurisé comme SSH. Changer le port de SSH peut être une bonne idée pour minimiser le trafic des scanners.