Quelles menaces de sécurité le compte SA et les autres noms de compte connus posent-ils pour la sécurité?

Un nom de compte connu tel que sa constitue-t-il une menace pour la sécurité de la base de données? Lorsque vous utilisez l'authentification Windows sur SQL Server, impose-t-il la même stratégie de mot de passe (si elle a été définie pour dire le verrouillage du compte après 5 fois)?

Un nom de compte connu tel que sa constitue-t-il une menace pour la sécurité de la base de données?

Un compte d'utilisateur "dieu" avec un nom connu est généralement considéré comme une idée pire qu'un utilisateur dieu avec un nom moins connu. Cela rend les attaques par force brute un peu plus faciles car l'attaquant n'a qu'à deviner le mot de passe et non le nom d'utilisateur et le mot de passe.

De toute façon, avoir un utilisateur divin peut être dangereux. Il est généralement préférable d'avoir des utilisateurs spécifiques avec des droits spécifiques pour ce qu'ils doivent faire. Ce type de sécurité basée sur les privilèges est plus facile à mettre en œuvre à partir de zéro qu'il ne le sera ultérieurement dans votre environnement.

La désactivation de sa et l'octroi à des utilisateurs spécifiques de droits d'administrateur spécifiques selon les besoins dans SQL Server est essentiellement la même recommandation que la désactivation rootet la distribution des droits d'administrateur selon les besoins via sudosous Linux et similaire. Vous pouvez toujours réactiver saune fois directement connecté à la machine avec les privilèges adéquats en cas de problème et vous perdez tous les droits dont vos utilisateurs ont besoin pour fonctionner (et résoudre le problème) de la même manière que vous pouvez concevoir un accès root à un Linux si vous avez un accès physique à la boîte - la désactivation du compte n'est donc pas une solution miracle (mais une fois qu'un attaquant a un accès physique à votre machine ou un accès administratif complet via RDC ou SSH, tous les paris sont désactivés de toute façon).

Lorsque vous utilisez l'authentification Windows sur SQL Server, impose-t-il la même stratégie de mot de passe (si elle a été définie pour dire le verrouillage du compte après 5 fois)?

Lorsque vous utilisez l'authentification intégrée de Windows, le serveur SQL n'a aucun contrôle sur les verrouillages de compte et autres - il mappe simplement un utilisateur Windows à un utilisateur SQL et demande au système d'exploitation de se porter garant du fait que l'utilisateur a fourni les informations d'identification appropriées. Pour les utilisateurs humains interactifs, cela signifie que tout verrouillage se produira lorsque l'utilisateur tentera de s'authentifier auprès de Windows, et non lorsqu'il se connectera à SQL Server.

Ce n'est pas une mauvaise idée de faire en sorte que l'utilisateur administrateur par défaut (admin / root / postgres / sa / etc) n'existe pas réellement dans votre système. Vous pouvez toujours créer un compte privilégié sous un nom différent.

Si rien d'autre, les gens qui essaient d'exploiter votre système n'ont pas aussi facilement de temps que s'ils travaillent à l'aveugle (par exemple, injection sql sans avoir un shell interactif ni être en mesure de voir la sortie directe de leurs commandes)

En ce qui concerne les verrouillages de compte - si quelqu'un a réussi à aller assez loin pour même pouvoir tenter de se connecter à votre machine, sauf si vous autorisez spécifiquement la connexion directe des utilisateurs, vous avez déjà perdu la bataille. Personnellement, je ne suis pas en faveur des lock-out pour la plupart, car cela donne à quelqu'un la possibilité de créer un déni de service s'il parvient à obtenir le nom de l'un de vos utilisateurs. (et les faire verrouiller le super utilisateur? pas amusant).

Je recommanderais de regarder les benchmarks CIS ... ils ne les ont pas pour chaque base de données, mais ils ont des recommandations pour Oracle, MS SQL, DB2 et MySQL. Si vous exécutez autre chose, cela vaut toujours la peine de regarder le genre général de choses qu'ils recommandent.

Je n'ai vu personne d'autre le mentionner, je vais donc l'ajouter. Avec SQL Server 2005+ si votre serveur fait partie d'un domaine et que le domaine a une stratégie de mot de passe, vous pouvez activer la stratégie de mot de passe à appliquer sur les connexions SQL. Cela inclut les exigences de complexité du mot de passe et la possibilité de forcer les changements de mot de passe lors de la connexion.

Notez que cela peut parfois provoquer des problèmes avec certains programmes d'installation de logiciels qui n'ont pas été mis à jour pour fonctionner avec SQL 2005+ et créer des connexions SQL avec des mots de passe non sécurisés.

Il existe deux modes d'authentification utilisés dans SQL Server: l'authentification Windows et le mode mixte (active à la fois l'authentification Windows et l'authentification SQL Server)

Le premier mode est moins vulnérable aux attaques par force brute, car l'attaquant est susceptible de se heurter à un verrouillage de connexion (la fonctionnalité de stratégie de verrouillage de compte) après un nombre fini de tentatives d'attaque. Chaque environnement de production, si vous utilisez le mode d'authentification Windows, doit utiliser la fonctionnalité de stratégie de verrouillage, car elle rend les attaques par force brute impossibles

En ce qui concerne la vulnérabilité aux attaques par force brute de l'authentification SQL Server, la situation n'est pas aussi favorable. L'authentification SQL Server ne comporte aucune fonctionnalité permettant de détecter le moment où le système subit une attaque par force brute. De plus, SQL Server est très réactif lorsqu'il s'agit de valider les informations d'authentification SQL Server. Il peut facilement gérer les tentatives de connexion répétées, agressives et à force brute sans performances globales négatives qui pourraient indiquer de telles attaques. Cela signifie que l'authentification SQL Server est une cible parfaite pour le craquage de mot de passe via des attaques par force brute

De plus, les méthodes de force brute évoluent avec chaque nouvelle méthode de cryptage et de complexité des mots de passe. Par exemple, les attaquants qui utilisent des tables arc-en-ciel (les tables précalculées pour inverser les valeurs de hachage cryptographiques pour chaque combinaison de caractères possible) peuvent facilement et rapidement casser n'importe quel mot de passe haché

Afin de protéger votre SQL Server contre les attaques par force brute, vous devez prendre en compte les éléments suivants:

• N'utilisez pas le mode d'authentification SQL Server - forcez l'attaquant à frapper le verrouillage de connexion via l'authentification Windows
• Si vous devez utiliser le mode d'authentification SQL Server, désactivez ou supprimez la connexion SA - de cette façon, l'attaquant doit deviner et associer le nom d'utilisateur et le mot de passe

Le compte sa, lorsqu'il est activé, peut faire n'importe quoi sur le serveur SQL. Si un attaquant venait à accéder à ce compte, il pourrait faire tout ce qu'il voulait sur l'instance SQL Server (et peut-être le système d'exploitation hôte).

Les SA (et autres noms de comptes bien connus) sont des points bien connus que les pirates peuvent attaquer. Certains de ceux d'Oracle étaient mal documentés et donc les mots de passe par défaut n'étaient pas toujours modifiés. Une fois que vous avez le contrôle du compte SA dans SQL Server, vous contrôlez le serveur sur lequel il s'exécute et pouvez exécuter n'importe quel code ou installer tout ce que vous souhaitez. Dans mes jours de cowboy, je me souviens ne pas avoir été autorisé (il fallait des documents que je n'allais pas remplir) pour installer un contrôle ActiveX sur un serveur Web qui hébergeait également SQL Server - j'ai donc utilisé xp_cmdshell pour copier et installer le contrôle .