Discussion :

[gilles_906]

Bonjour

Est il possible sous SQL Server de bloquer les IP qui essayent (3 fois par exemple) un mot de passe et se trompe.

Vous aurez compris que j'ai des Ko de pages de log qui essayent de se connecter sur mon serveur.
Pour l'instant ils n'y arrive pas, m'enfin on ne sais jamais.

Je sais qu'il y a la solution de les bloquer au niveau du firewall, mais cela va m'obliger a lire les logs tous les jours pour extraire le paquets de hackers qui essaie, puis entrer a la main les ip dans le firewall.

Merci d'avance

[darkelend]

Avec un trigger sur la connection (http://msdn.microsoft.com/en-us/library/bb326598.aspx), tu dois pouvoir tester l'adresse IP de la connection avec par exemple une table de blacklist.
Sinon es tu obligé d'exposer ta base de données vers l'exterieur ?

[gilles_906]

Merci de ta réponse, mais j'espérais plutot qu'il existe une fonction native dans sql serveur.

Tans pis je vais essayer de la coder.

Oui je suis obligé de l'exposer sur l'extérieur.

[sevyc64]

Une des solutions serait de ne pas laisser le serveur SQL accessible depuis internet.

[michelatoutfox]

Bonjour,

j'ai retrouvé ce lien dans mes archives: http://www.sqlservercentral.com/arti...ecurity/66151/. C'est un article de Brian Kelly, paru sur SQLserverCentral, dont le titre est "Blocking Users by IP"

[gilles_906]

sevyc64
c'est gentil d'essayer de m'aider
Comme je l'ai dit juste au dessus, je suis obligé de le laisser exposer sur l'extérieur.

J'ai trouvé ce code sur le net mais il plante sur l'instruction select.

11/27/2012 18:30:04,spid55,Inconnu,Erreur*: 229<c/> Gravité*: 14<c/> État*: 5.
11/27/2012 18:30:04,spid55,Inconnu,L'autorisation SELECT a été refusée sur l'objet 'IPBLock'<c/> base de données 'master'<c/> schéma 'dbo'.

Pour la table

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

CREATE TABLE master.dbo.IPBLock (ipaddress VARCHAR(15))

Pour le trigger

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
CREATE TRIGGER block_ipaddress
ON ALL SERVER
FOR LOGON
AS
BEGIN
            DECLARE @capturedip NVARCHAR(15);
            SET @capturedip = (SELECT EVENTDATA().value('(/EVENT_INSTANCE/ClientHost)[1]', 'NVARCHAR(15)'));
            IF EXISTS(SELECT ipaddress FROM master.dbo.IPBLock WHERE ipaddress = @capturedip)
            BEGIN
                        Print 'Your IP Address is blocked, Contact Administrator'
                        ROLLBACK
            END
            ELSE
            BEGIN
                        DECLARE @IPRange VARCHAR(15)
                        SELECT @IPRange= SUBSTRING(@capturedip,1,LEN(@capturedip)-CHARINDEX('.',REVERSE(@capturedip)))+'.*'
                        IF EXISTS(SELECT ipaddress FROM master.dbo.IPBLock WHERE ipaddress = @IPRange)
                        BEGIN
                            Print 'Your IP Address Range is blocked, Contact Administrator'
                            ROLLBACK
                        END
            END
END
GO

Quelqu'un aurait il une idée d'ou provient l'erreur?
En fait tout le monde est refusé maintenant, c'est plus sécuritaire, mais moins fonctionnel

[gilles_906]

Merci de ton lien michelatoutfox

c'est un peu basé sur le meme principe que le code que j'ai trouvé, sauf que lui met une table d'autorisation d'acces.

Je ne peux pas faire ca, car je dois pouvoir me connecter a la base avec mon téléphone portable qui change d'Ip souvent

[mikedavem]

Bonsoir,

Je crois que tu ne prends pas le problème par le bon bout. Pour un hacker il est très facile de changer d'ip.

Quelle est la surface d'attaque de ton serveur SQL ? Est-il visible depuis internet ? Est-ce que les connexions se font sur le port par défaut ? Est-ce que tu peux nous en dire plus sur ton environnement ?

Vous aurez compris que j'ai des Ko de pages de log qui essayent de se connecter sur mon serveur.
Pour l'instant ils n'y arrive pas, m'enfin on ne sais jamais.

Si tu ne récupères que les tentatives en échec (par défaut) tu ne peux pas être certain qu'un intrus ne soit pas entré. En effet, si ce dernier a trouvé le mot de passe tu n'auras plus les événements liés aux tentatives de ce genre dans le journal SQL ...

++

[gilles_906]

Merci mikedavem de te pencher sur mon soucis

Quelle est la surface d'attaque de ton serveur SQL ?

Qu'appelles tu la surface d'attaque?

Est-il visible depuis internet ?

Oui car j'ai besoin d'y acceder depuis l'extérieur avec un portable qui change d'ip a chaque connexion.

Est-ce que les connexions se font sur le port par défaut ?

Oui
Changer le port ne va pas (a mon avis résoudre le probleme) car j'ai aussi un serveur NAS qui passe son temps a blacklister les ip qui essayent de se connecter (je blacklist sur 3 essais raté sur une duré de 15mn)

Pour te donner une idée aujourd'hui j'ai un Hongrois qui a essayé pendant 1 heure a raison de 4 essai seconde de se connecter.
Cela veut dire qu'il a mis un robot pour essayer une liste de mot de passe sur le compte "sa"

Que veux tu savoir sur mon environnement?
Pour l'instant 1 pc avec sql server
Un Nas avec un web serveur qui contient les fichiers php qui font des actions sur sql serveur.

A terme tout devrait etre sur le NAS sqlserver et le serveur web.

Ce que j'aimerai faire

Une table d' IP autorisé
Une Table d'IP bloqué

Dans un Trigger
Si IP est dans la table IP bloqué alors acces interdit
Si l'IP est dans la table Autorisé alors autant d'essai que l'on veut
Si erreur de mot de passe alors ajout dans la table IP bloqué

Toutes les IP variable (IP des portables) ne se trompe pas de mot de passe car il est en dur dans le prog

[mikedavem]

Qu'appelles tu la surface d'attaque?

En d'autres termes quels sont les points d'entrée de ton serveur ? Ouverture depuis internet ? Serveur derrière un firewall ou autre ou directement exposé ?

Changer le port ne va pas (a mon avis résoudre le probleme) car j'ai aussi un serveur NAS qui passe son temps a blacklister les ip qui essayent de se connecter (je blacklist sur 3 essais raté sur une duré de 15mn)

Tu as raison cela ne va pas éliminer des tentatives d'intrusion mais cela va te permettre d'en éliminer un certain nombre.

Pour te donner une idée aujourd'hui j'ai un Hongrois qui a essayé pendant 1 heure a raison de 4 essai seconde de se connecter.
Cela veut dire qu'il a mis un robot pour essayer une liste de mot de passe sur le compte "sa"

Je pense qu'en changeant le port d'écoute tu pourrais minimiser les personnes utilisant des robots qui tentent la connexion sur le port 1433. Bien entendu il faudra tester et tirer les conclusions après analyse des logs à postériori.

Toutes les IP variable (IP des portables) ne se trompe pas de mot de passe car il est en dur dans le prog

Dans l'absolu pas forcément même si les chances que quelqu'un tente de regarder dans l'application les informations d'identification sont minces :-)

Ce que j'aimerai faire

Une table d' IP autorisé
Une Table d'IP bloqué

Dans un Trigger
Si IP est dans la table IP bloqué alors acces interdit
Si l'IP est dans la table Autorisé alors autant d'essai que l'on veut
Si erreur de mot de passe alors ajout dans la table IP bloqué

Pourquoi pas mais je pense que tu risques de te retrouver avec un certain nombre d'entrées dans ta table. Il faudra faire attention aux performances dans le temps. Les connexions risquent d'être le goulet d'étranglement de ton serveur.

Je ne peux que te conseiller de passer sur des éléments de sécurité comme un VPN ou autre.

++

[gilles_906]

J'ai un firewall avant le serveur.

Je pense qu'en changeant le port d'écoute tu pourrais minimiser les personnes utilisant des robots qui tentent la connexion sur le port 1433. Bien entendu il faudra tester et tirer les conclusions après analyse des logs à postériori.

Oui et non, s'ils sniff les ports ouvert ils vont le trouver. D'un autre coté, je suis d'accord avec toi qu'ils ne savent pas ce qu'il y a derrière, donc, ca devrait limiter les attaques.

Oui la table risque de grossir vite par contre si le mec se fait bloquer au deuxieme essai il ne va pas essayer 1 heure, s'il est pas trop c.. il va voir qu'il est blacklisté et va arreter (donc me libérer les connexions)
Rien ne m’empêche de vider la table tous les mois s'il elle devient trop grosse.
ce genre de hacker ne reviens pas le mois suivant s'il n'a pas réussi a entrer, d'autant qu'il n'aura qu'un seul essai de mot de pass avant de retourner dans la blackliste.


Par contre peux tu me donner l'instruction qui permet de récuperer le résultat de la tentative de connexion.
Parce que pour l'instant le script du trigger travaille en amont de la connexion, et il me faut alimenter la table IPbloqué sur un echec de connexion.

Ca fait 2 heure que je cherche et je n'ai rien trouvé.

Merci

[sevyc64]

par contre si le mec se fait bloquer au deuxieme essai il ne va pas essayer 1 heure, s'il est pas trop c.. il va voir qu'il est blacklisté et va arreter (donc me libérer les connexions)
Rien ne m’empêche de vider la table tous les mois s'il elle devient trop grosse.
ce genre de hacker ne reviens pas le mois suivant s'il n'a pas réussi a entrer, d'autant qu'il n'aura qu'un seul essai de mot de pass avant de retourner dans la blackliste.

Là tu rêve.

D'abords c'est pas un mec, mais une armée de robots logiciels, et ils n'abandonne pas comme ça.
J'ai subit de telles attaques sur un serveur FTP dans une ancienne boite. Le(s) robot(s) changeai(en)t d'ip 3 fois par seconde, donc impossible à blacklister à la main, et de toute façon ça servait à rien puisqu'une ip blacklistée était immédiatement remplacée. Notre seule solution : Arrêter le serveur pendant quelques heures avant qu'il ne s'écroule tout seul.
Mais même après 2 jours d’arrêt complet, il ne fallait généralement pas plus de 3h après la remise en ligne pour se reprendre des attaques.

Faut pas croire que derrière tes attaques tu as un type qui tape chaque mot de passe. En réalité tu as une armé de pc zombies répartis dans le monde entier, infectés par de quelconques virus sous le contrôle d'un serveur central. C'est eux qui font les attaques automatiquement. Par contre si une attaque est fructueuse, là, oui tu as un type, ou un robot plus évolué qui reprend la main pour voir ce qu'il y a à l’intérieur.

[gilles_906]

Oui c'est vrai, d'ailleurs 4 tentatives par seconde, ca fait beaucoup pour un type derrière son pc
Mais en regardant mes log ils essayent pendant 1 heure, puis c'est une autre ip un peu plus tard.
J'ai bien envie d'essayer comme ca on verra a l'usage, ca leur fait un barrage de plus.

Changer le port du serveur en fera aussi un autre.


Pour l'instruction qui me retourne si la connexion a échouer (car mauvais mot de passe) tu l'as connais ou pas?

[gilles_906]

Je crois que j'ai fais une grosse boulette et que je vais avoir besoin d'aide.

Aprés nos discutions j'ai changé mon fusil d'épaule et j'ai décidé de n'autoriser que certaine ip.

j'ai donc fais ce code

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
CREATE TRIGGER [block_ipaddress]
ON ALL SERVER
FOR LOGON
AS
BEGIN
            DECLARE @capturedip NVARCHAR(15);
            SET @capturedip = (SELECT EVENTDATA().value('(/EVENT_INSTANCE/ClientHost)[1]', 'NVARCHAR(15)'));
			IF NOT EXISTS(select ipadresse FROM master.dbo.IPOK WHERE ipadresse = @capturedip)
 
			ROLLBACK
END

Avant j'ai mis mon ip dans la table master.dbo.IPOK

Je crois que mon erreur est d'avoir oublié le begin et le end autour du rollback, parce que maintenant je ne peux plus me connecter a ma base.
Quelqu'un peu me confirmer l'erreur?

Quelqu'un aurait il une solution a mon probleme? autre que de réinstaller sql server et perdre la base.

Pour info:
l'utilisateur sa est désactivé

Merci

EDIT: c'est bon j'ai pu le droper avec sqlcmd

EDIT2: pour info mon ip c'est <local machine> j'ai cherché un moment avant de la trouver

[darkelend]

Tu as une sauvegarde de la base ?

[gilles_906]

Bonjour
Oui mais c'est pas tant les données car pour l'instant je suis toujours entrain de programmer les script et elle n'est pas opérationnel.
C'était plutot pour les procedures, fonctions, trigger et la structure de toutes les tables.
Mais comme je l'ai dit dans EDIT au dessus tout est rentré dans l'ordre maintenant.