March 24, 2003 at 4:21 am
Thanks everybody.
Great info and excellent TDS resource.
March 24, 2003 at 6:38 am
SQL Server shouldn't be responsoible for this. TDS is an upper layer protocol. You need to use tools like Netmon or some other packet sniffer to catch the source. Let's let SQL Server do what it is supposed to do, and use the other tools to do what they need to do. Use of a firewall or just simple packet filtering will do the trick.
March 24, 2003 at 7:02 am
On this point I'll respectfully disagree. Here's why:
If you're encrypting the data stream, either through SSL or IPSec, then a packet sniffer isn't going to be able to interrogate the packet and figure out that it's a logon failure message coming back from SQL Server. As a result, something has to be done on the SQL Server side.
You could narrow the range of IPs allowed to access a particular SQL Server, but the problem is that an attack can come from a legitimate IP. For instance, an internal intrusion attempt due to (a) a worm or some other malware or (b) an intentional attempt from a disgruntled employee.
So not having the ability to log IPs for failed logon attempts in SQL Server can be seen as a major hindrance. Consider it along the same lines as having detailed logs on a web server.
K. Brian Kelley
http://www.truthsolutions.com/
Author: Start to Finish Guide to SQL Server Performance Monitoring
http://www.netimpress.com/shop/product.asp?ProductID=NI-SQL1
K. Brian Kelley
@kbriankelley
March 26, 2003 at 5:49 am
Fully in agreement with bkelley - good points precisely expressed as usual.
In case it is of interest to anyone, I ended up using ethereal (www.ethereal.com) a free packet sniffer for windows. It does a good job of decrypting TDS packets without any need for configuration (although the definitions are close but not perfect for SQL Server login requests).
I found what I was looking for. In addition I also found several brute force attacks - all attempting logins for standard usernames with a clearly faked hostname of "XRay". These came from a variety of IPs suggesting a hacker tool or worm -- and yes I know these should be filtered by a firewall or IPSec etc. However it got me thinking ...
Do people think SQL Server should offer a finer granularity of security for IP connections, e.g.
--Restrict SQL Server logins by IP address (e.g. never allow "sa" except from IP x,y,z)
--Restrict volume of SQL Server login attempts by IP address (e.g. only allow x attempts per minute)
A good idea or just an extra layer of configuration that can go wrong with no real benefit?
March 26, 2003 at 6:12 am
quote:
Do people think SQL Server should offer a finer granularity of security for IP connections
I would say no, I don't think so. I want to choose whatever product I want for that purpose, of course SQL could have it as well but that would just be one more possible feature that could contain security holes. However, as Brian said earlier, I think that SQL should have a better way of logging and identifying these login attempts, with the specific IP-address where the connection attempt came from.
--
Chris Hedgate @ Apptus Technologies (http://www.apptus.se)
Viewing 5 posts - 16 through 19 (of 19 total)
You must be logged in to reply to this topic. Login to reply