Comment protéger SQL Server contre les pirates

J'ai un problème et je n'ai pas pu comprendre comment le gérer. J'ai un serveur SQL sur un serveur Windows 2008 R2. Ce SQL Server 2005 est utilisé pour recevoir des abonnements à des bases de données d'un autre SQL Server situé ailleurs sur Internet. J'ai le port du serveur SQL ouvert via le pare-feu, mais dans la portée, j'ai entré l'IP de l'autre SQL Server. Ce faisant, j'espérais que les demandes de connexion via ce port n'atteindraient pas SQL Server à moins que les demandes proviennent de l'autre SQL Server (dont l'IP est répertoriée dans la portée de la règle de pare-feu). Mais, quand je vois le journal, il y a des centaines d'entrées "login failed user sa" (et elles arrivent chaque seconde qui passe). Il semble qu'un pirate essaie par force brute de deviner le mot de passe de l'utilisateur. Mais la question est, pourquoi Windows laisse ces requêtes atteindre le serveur SQL même si elles ne proviennent pas de l'adresse IP répertoriée dans la portée du pare-feu? Quelle est la bonne façon de protéger ce SQL Server. Aucune autre IP que l'IP de l'autre SQL Server n'a besoin de se connecter à ce serveur SQL.

EDIT - Plus d'informations:

J'ai exécuté telnet sur le port du serveur SQL à partir de différentes machines. Telnet échoue sauf lorsqu'il est exécuté à partir de la machine spécifiquement mentionnée dans la portée du pare-feu. Il semble donc que le pare-feu bloque correctement le port du serveur SQL. Mais alors pourquoi je vois ces demandes de connexion échouées à l'utilisateur "sa" de différentes adresses IP dans le journal SQL Server? Est-il possible que le pirate pénètre dans la machine via le port 80 et essaie en quelque sorte de se connecter au serveur SQL? Les ports 80 et 443 sont ouverts à tous. Tous les autres ports sont fermés à l'exception du port du serveur SQL (et qui n'est ouvert que pour une adresse IP spécifique). Il n'y a rien en cours d'exécution sur le serveur Web au port 80 qui peut conduire un visiteur vers le serveur SQL. En fait, il n'y a qu'un seul fichier index.html (HTML pur sans connexion SQL) sur le serveur Web. Il s'agit simplement d'un serveur de test en cours de configuration pour une utilisation future. Tester uniquement les données dans SQL Server.

ÉDITER:

J'ai activé le suivi du pare-feu pour inclure à la fois les connexions d'abandon et de réussite. Il retrace désormais tout. Ensuite, je vais dans le journal SQL Server où je vois ces tentatives de connexion échouées à partir de différentes adresses IP en Chine. Mais il n'y a aucune entrée pour ces adresses IP dans le journal du pare-feu. Comment est-ce possible? Peuvent-ils accéder au serveur SQL en contournant complètement le pare-feu? Si vous supposez qu'un port de pare-feu était ouvert par lequel ils pouvaient entrer, le journal du pare-feu devrait afficher une entrée pour cette adresse IP. Je suis complètement perdu.

sql-server security

— Allen King
source

Que diriez-vous d'utiliser Logon Trigger ? En outre, SQL Server ne doit pas être exposé à Internet (public). En outre, vous pouvez utiliser les règles du programme dans le pare-feu Windows pour limiter la plage d'adresses IP.

— Kin Shah

Oui, je le pourrais, mais au fond, il ne s'agit pas vraiment de SQL Server. J'essaie de savoir pourquoi le pare-feu Windows ne fait pas ce qu'il est censé faire, c'est-à-dire qu'il ne laisse pas passer ces demandes car elles ne proviennent pas de la seule adresse IP autorisée.

Oui, il semble que votre pare-feu Windows soit mal configuré. Peut-être que vous avez une autre règle plus générale qui autorise le port 1433 (ou tout autorise), ou peut-être que le pare-feu Windows est désactivé sur la carte réseau Internet. C'est difficile à dire sans voir la configuration. Mais c'est vraiment plus une question pour ServerFault comme Max le dit. Voulez-vous dire Windows 2008 R2, btw? 'RC' est Release Candidate, un logiciel de pré-version pour les tests.

— James L

On dirait que SF sera la troisième destination pour cette question! .

— Martin Smith

Utilisez-vous vraiment un ancien système d'exploitation candidat à la sortie ?! Réparez cela en premier.

— Michael Hampton,

Réponses:

On dirait que votre pare-feu n'est pas configuré correctement. C'est le premier pas.

Normalement, je ne soutirerais pas un livre que j'ai écrit, mais dans ce cas, je ferai une exception. Cela s'appelle Sécuriser SQL Server et cela vous donnera un bon départ.

— mrdenny
source

Eh bien, votre livre correspond parfaitement à cette question :-)

— mfinni

Cool! A-t-il des conseils normatifs sur l'utilisation de certificats au lieu de l'authentification locale / Windows pour les serveurs accessibles sur Internet? ;-)

— Greg Askew

Voir mes modifications. Le pare-feu semble fonctionner correctement. C'est une autre astuce que ces pirates chinois jouent pour accéder au serveur SQL.

— Allen King

Si quelqu'un se connecte au port SQL à partir d'une adresse IP publique, le pare-feu n'est pas configuré correctement. S'ils proviennent d'une adresse IP interne, vous avez un autre type de problème. SQL par lui-même ne prend pas en charge les certificats. Vous devez le faire via les mappages AD et de certificat.

— mrdenny

Revenons en effet au dessin du pare-feu. Je voudrais retirer le serveur SQL d'Internet jusqu'à ce que votre situation de pare-feu soit résolue. De cette façon, vous serez en mesure d'interdire IP des plages entières d'adresses IP avec une relative facilité.

— Techie Joe

Simplement dit - vous ne le faites pas. Je n'utiliserais pas de pare-feu, etc. - un serveur SQL n'a pas le droit d'être sur Internet. TRÈS TRÈS peu d'exceptions.

Pour la réplication, configurez un VPN approprié.

— TomTom
source

Je suis un peu confus. Si le serveur de base de données n'est pas sur Internet, comment un serveur principal d'application Web atteindra-t-il le serveur de base de données?

— Allen King

Via le réseau interne. Configuration de base. L'application Web se trouve dans les deux réseaux.

— TomTom

Outre la configuration correcte du pare-feu, voici quelques recommandations générales pour protéger SQL Server des attaques par force brute:

Désactivez le compte «sa». La connaissance du nom de connexion exact facilitera les attaques
```
ALTER LOGIN sa DISABLE
```

Une autre option consiste à renommer le compte «sa» en un nom moins évident

ALTER LOGIN sa WITH NAME = SimonXZY

Utilisez l'authentification Windows au lieu de l'authentification en mode mixte. L'authentification Windows applique la stratégie de mot de passe Windows et verrouille la connexion en cas d'échec de tentatives de connexion successives
L'audit des connexions a échoué. La façon la plus simple de procéder consiste à définir l'option Audit de connexion dans les propriétés du serveur, onglet Sécurité sur Échecs de connexion uniquement ou Échecs et succès des connexions. Cela ne vous aidera pas à vous protéger contre les attaques par force brute, mais vous aidera à être conscient des attaques

Plus de recommandations utiles ici: Prévenir une force brutale ou une attaque par dictionnaire: Comment éloigner les brutes de votre butin

— Milena Petrovic
source