La modification du port SQL Server est-elle vraiment beaucoup plus sûre?

Le port par défaut de SQL Server est 1433. Notre administrateur m'a dit que le port devait changer "pour des raisons de sécurité".

Est-il vraiment beaucoup plus sûr de changer de port? Si le serveur est derrière un pare-feu et qu'il autorise uniquement des connexions à celui-ci à partir d'une certaine plage d'adresses IP, n'est-ce pas suffisant?

Il aide à lutter contre les analyses de port courantes qui peuvent être lancées via des sites Web d'analyse de port. Mais cela n'aidera pas un attaquant engagé. C'est juste une autre couche, mais n'ajoute pas grand-chose au-dessus du pare-feu, comme vous l'avez mentionné.

Si vos serveurs SQL sont directement connectés à Internet (ce qu'ils ne devraient pas être), il peut vous offrir une certaine protection car la plupart des scripts d'attaque génériques utilisent uniquement les numéros de port par défaut.

Si vos serveurs SQL ne sont pas accessibles directement depuis Internet, cela est assez inutile. Tout pare-feu devra autoriser la connectivité au port distant. Dès que j'exécute le logiciel client sur la machine, je peux voir quel port le SQL Server utilise via la commande NET STAT. À ce stade, vous m'avez ralenti exactement 2-3 secondes.

Il cassera les applications qui attendent le port 1433.
Certaines applications peuvent être configurées pour gérer cela, mais cela doit être déployé.

Je le laisserais juste. S'ils "piratent" votre instance par défaut sur le port 1433, vous êtes déjà bollixé.

Vous pouvez spécifier le port pour les instances nommées, mais le port 1434 doit être ouvert pour résoudre l'instance au port ...

Les pirates analysent fréquemment les adresses IP pour les ports couramment utilisés, il n'est donc pas rare d'utiliser un port différent pour "voler sous le radar". C'est juste pour éviter la détection, à part qu'il n'y a pas de sécurité supplémentaire en utilisant un port différent.

Si seulement une plage IP limitée peut accéder au port, alors vous êtes déjà "sous le radar", donc je ne vois pas de bonne raison d'utiliser un port différent.

En fait, oui. Pour utiliser un autre exemple, l'administrateur du laboratoire Linux de mon université a changé le port SSH de 22 en une valeur obscure. Il a rapporté que le réseau était passé d'environ 10 000 pings / attaques par jour à environ 1 ou 2 par mois. Certes, si vous ne souffrez pas déjà de ce type d'attaque, cela ne vaut peut-être pas la peine dans la plupart des cas. Pourtant, en passant à un port alternatif discret, vous empêchez les attaques à large sonde et ainsi de suite.

Je pense que c'est un problème en deux parties.

1) Le logiciel de numérisation de port commun peut d'abord essayer les ports communs, mais rien ne le empêche spécifiquement d'essayer tous les ports, et vous devez pouvoir supposer qu'il sera en mesure de prendre les empreintes digitales du protocole lorsqu'il trouvera un port ouvert .

2) Lorsque le scan de port le plus agressif se produit, vous devez pouvoir le détecter et faire quelque chose avec cette connaissance (comme fail2ban, etc.)

Votre administrateur propose (1), demandez quelles idées il a concernant (2).

La sécurité par l'obscurité n'est pas du tout une sécurité.

Edit: là encore, certains disent que ça l'est ! Personnellement, je continuerai à adopter mon point de départ.

Changer le port les forcera à faire un scan. Lorsque vous utilisez un outil de sécurité tel que Snort, avec des taps réseau ou SPAN, alors quelque chose comme une analyse de port de votre serveur devient évident. Quelqu'un se connectant légitimement au serveur SQL sur le port par défaut n'est pas si évident.

La meilleure approche, j'en conviens, n'est pas la sécurité par l'obscurité. Cependant, la modification du port par défaut sur toutes les applications, lorsque cela est possible, fait partie d'une stratégie plus globale et plus profonde qui inclut les activités de l'équipe rouge, les équipes de surveillance de la sécurité du réseau et toutes les instruments appropriés, installés, mûris et compris par ceux qui l'utilisent.

Lorsque vous avez toutes ces choses, un intrus dans votre système se démarque comme un pouce endolori. L'essentiel - si quelqu'un pense qu'il peut améliorer la sécurité de ses systèmes en cochant un tas d'éléments sur une liste, il a tort. S'ils ne peuvent pas expliquer pourquoi ils ont besoin que le port soit changé, sans aucun doute, ils n'appartiennent pas au rôle de quelqu'un qui vous dit de changer de port.

Lorsqu'une application se connecte à MS SQL sur TCPIP, la première partie de la conversation a lieu le 1433 avec l'instance sans nom par défaut, notamment la diffusion de tous les numéros de port sur lesquels les instances nommées communiquent. Tous les pare-feu doivent être configurés pour a) laisser passer les plages IP appropriées, B) les numéros de port fixes que toutes les instances nommées peuvent utiliser. Ceux-ci doivent être configurés dans le gestionnaire de configuration SQL comme fixes. Vous pouvez communiquer avec n'importe quelle instance en utilisant (adresse IP 192.168.22.55): (numéro de port 12345) dans la chaîne de connexion. Si le service de navigateur SQL n'est pas activé, 1433 ne fournira pas la conversation initiale. Si vous utilisez l'authentification NT, il y a peu à gagner. Si vous utilisez l'authenetication SQL, il y a une petite somme a gagner.