March 9, 2009 at 12:07 am
Comments posted to this topic are about the item Blocking Users by IP
K. Brian Kelley
@kbriankelley
March 9, 2009 at 6:28 am
March 9, 2009 at 6:40 am
Great article.
Question: Is it possible to use this to block repeated login attempts that fail (i.e., someone/app trying to login into my server over and over)? So for example, block the IP if there are 3+ login failures.
Thanks.
March 9, 2009 at 7:05 am
I think I found the answer... Use the article + the xp_readerrorlog system proc...
Cool!
March 9, 2009 at 7:11 am
Great article!
I used similar technique in ASP/MS SQL web environment about 5 years ago, but I saved some resources and authenticated user's IP in ASP code rater than in MS SQL. I did it pretty much the same way, by comparing user's IP with what stored in the table as allowable range(s) of user IPs. It seemed to be a good method for consortium sites where site licence rater then individual logins are used and maintained.
Thanks, Galina.
March 9, 2009 at 7:16 am
Hi,
Will it work on SQL Server Express Edition also?
Regards
RK
March 9, 2009 at 8:20 am
Nice trick.
Can you add some real life examples of where this was implemented? And the details of why it was absolutely necessary? And, were all other alternatives for handling security considered before implementing this solution?
March 9, 2009 at 8:42 am
Ken Shapley (3/9/2009)
Nice trick.Can you add some real life examples of where this was implemented? And the details of why it was absolutely necessary? And, were all other alternatives for handling security considered before implementing this solution?
A real world example was given in the article. If you see someone trying to connect as sa from a web server in the DMZ, that's usually a good sign (given good application design) that an attacker has compromised the web server and is launching an attack against the SQL Server. Now given that the web server is in the DMZ, it shouldn't be on the domain, which means you have to drop back to SQL Server logins. Now most folks configure their IDS/IPS to alert only. Meaning that attacks against SQL Server based logins would not be blocked by the IDS/IPS.
As to examples of where this kind of thing was implemented, if you search the forums, here, MSDN, and Stack Overflow (and on twitter, as I believe @BugBoi was implementing based on application name ~ tweets were around March 3).
K. Brian Kelley
@kbriankelley
March 9, 2009 at 8:55 am
Excellent job, Brian, and a great solution. Wish we had a good one for 2000, but having this handy would be nice for blocking people making attempts to crack security or overload the server.
March 9, 2009 at 11:59 am
Great article, Brian. Is the Client_Host ip information still available about a session later on, or would I need to store it from a Logon Trigger like yours if I needed that?
[font="Times New Roman"]-- RBarryYoung[/font], [font="Times New Roman"] (302)375-0451[/font] blog: MovingSQL.com, Twitter: @RBarryYoung[font="Arial Black"]
Proactive Performance Solutions, Inc. [/font][font="Verdana"] "Performance is our middle name."[/font]
March 9, 2009 at 12:21 pm
Good job, Brian. I will definitely use this.
- Paul
http://paulpaivasql.blogspot.com/
March 9, 2009 at 12:24 pm
RBarryYoung (3/9/2009)
Great article, Brian. Is the Client_Host ip information still available about a session later on, or would I need to store it from a Logon Trigger like yours if I needed that?
It's also available in sys.dm_exec_connections in the column client_net_address.
K. Brian Kelley
@kbriankelley
March 9, 2009 at 12:26 pm
Hey I ran this and my DB is blocked. Help me out my system giving myself error
March 9, 2009 at 12:35 pm
It should
March 9, 2009 at 12:49 pm
Any resolution???? I am not good in DB.. Plz help....
Viewing 15 posts - 1 through 15 (of 53 total)
You must be logged in to reply to this topic. Login to reply